Несколько идей, связанных с REST, конфликтуют в моей голове, когда я пытаюсь реализовать их.
У меня есть серверная система API REST-ful с бизнес-логикой и веб-приложение с пользовательским интерфейсом. Из различных ресурсов о REST (в частности, REST на практике: гипермедиа и системная архитектура ) я знаю, что я не должен предоставлять необработанные идентификаторы своих сущностей, а скорее возвращать гиперссылки с rel="self".
Рассмотрим пример. REST 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должен иметь некоторый идентификатор объекта, поскольку веб-приложение должно иметь возможность обращаться к объекту при открытии целевой страницы. - В упомянутой книге сказано, что веб-приложение не должно анализировать / создавать URL-адреса REST.
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-адреса.
- Предоставьте необработанные идентификаторы в REST API вместе со ссылками, используйте их для создания URL-адресов веб-приложений, а затем используйте идентификаторы на сервере веб-приложений для поиска необходимых ресурсов в API. Это лучше, но повлияет на производительность сервера веб-приложений, поскольку веб-приложению придется проходить навигацию службы REST, выдавая цепочку запросов get-by-id некоторой формы для обработки любого запроса из браузера. Для несколько вложенного ресурса это может быть дорогостоящим.
- Сохраните все
selfURL-адреса, возвращаемые API, в постоянном (DB?) Сопоставлении на сервере веб-приложений. Создайте для них несколько идентификаторов, используйте их для создания URL-адресов страниц веб-приложения и получения URL-адресов ресурсов службы REST. Т.е. я хранюhttp://my.rest.api/pet/678URL где-то с новым ключом, скажем3, и генерирую URL веб-страницы какhttp://my.web.app/pet/3. Это похоже на реализацию HTTP-кэша. Я не знаю почему, но мне это кажется странным.
Или все это означает, что RESTful API не могут служить бэкэндами для веб-приложений?