Кілька концепцій, пов'язаних з REST, конфліктують в моїй голові, коли я намагаюся його реалізувати.
У мене є REST-повна система API, що підтримує бізнес-логіку, та веб-додаток, що забезпечує інтерфейс користувача. З різних ресурсів про REST (зокрема, REST в практиці: гіпермедіа та архітектура систем ) я знаю, що я не повинен виставляти необроблені ідентифікатори моїх сутностей, а швидше повертати гіперпосилання за допомогою rel="self".
Розглянемо приклад. АРІЙТЕ api має ресурс, який повертає людину:
<Person>
<Links>
<Link rel="self" href="http://my.rest.api/api/person/1234"/>
</Links>
<Pets>
<Link rel="pet" href="http://my.rest.api/api/pet/678"/>
</Pets>
</Person>
Проблема виникає з веб-додатком. Припустимо, він повертає сторінку, що містить гіперпосилання на браузери:
<body class="person">
<p>
<a href="http://my.web.app/pet/???????" />
</p>
</body>
Що я повинен помістити в hrefатрибут? Як я можу зберігати URL-адресу сутності API у веб-програмі, щоб мати змогу отримати об'єкт, коли користувач відкриває цільову сторінку?
Вимоги здаються суперечливими:
- Гіперпосилання
hrefмає призвести до веб-програми, оскільки це система, що розміщує інтерфейс користувача hrefПовинні мати ідентифікатор об'єкта , так як веб - додаток повинен мати можливість звернутися до суті , коли відкриється цільова сторінка- Веб-додаток не повинен аналізувати / створювати REST URL-адреси, оскільки це не є REST-ful, йдеться у згаданій книзі
URI повинні бути непрозорими для споживачів. Тільки емітент URI знає, як його інтерпретувати та відображати на ресурсі.
Отже, я не можу просто взяти 1234URL-адресу відповіді API, тому що як RESTful клієнт я повинен ставитися до нього так, ніби це щось подібне http://my.rest.api/api/AGRIDd~ryPQZ^$RjEL0j. З іншого боку, я повинен надати певну URL-адресу, яка веде до мого веб-додатку, і цього достатньо, щоб програма якось відновила початкову URL-адресу API та використовувала цю URL-адресу для доступу до ресурсів API.
Найпростіший спосіб - це, мабуть, лише використання URL-адрес API як їх рядкових ідентифікаторів. Але такі URL-адреси веб-сторінок http://my.web.app/person/http%3A%2F%2Fmy.rest.api%2Fapi%2Fperson%2F1234некрасиві.
Все це здається досить простим для настільного додатку або односторінкової програми javascript. Оскільки вони живуть постійно, вони можуть просто зберігати URL-адреси в пам’яті разом із об’єктами служби протягом усього життя програми та використовувати їх у разі необхідності.
За допомогою веб-програми я можу уявити кілька підходів, але все здається дивним:
- Замініть хост у URL-адресах API і збережіть лише результат. Величезний мінус полягає в тому, що він вимагає від веб-програми обробляти будь-яку URL-адресу, що створюється API, що означає жахливе з'єднання. Більше того, це знову не RESTful, оскільки мій веб-додаток починає інтерпретувати URL-адреси.
- Розкрийте необроблені ідентифікатори в API REST разом із посиланнями, використовуйте їх для створення URL-адрес веб-додатків, а потім використовуйте ідентифікатори на сервері веб-додатків, щоб знайти потрібні ресурси в API. Це краще, але це вплине на ефективність роботи сервера веб-додатків, оскільки веб-додатку доведеться пройти навігаційну службу REST, видаючи ланцюжок запитів на отримання ідентифікації певної форми для обробки будь-якого запиту браузера. Для дещо вкладеного ресурсу це може бути дорогим.
- Зберігати всі
selfURL-адреси, повернені api, у постійному (DB?) Зіставленні на сервері веб-додатків. Створіть для них деякі ідентифікатори, використовуйте ідентифікатори для створення URL-адрес сторінки веб-додатків та отримання URL-адрес ресурсів служби REST. Тобто я зберігаюhttp://my.rest.api/pet/678URL-адресу десь за допомогою нового ключа, скажімо3, і генерую URL-адресу веб-сторінки якhttp://my.web.app/pet/3. Це схоже на якусь реалізацію кеша HTTP. Не знаю чому, але мені це здається дивним.
Або все це означає, що API RESTful не можуть служити основою для веб-додатків?