REST и URI-кеширование

Question

Насколько я понимаю, используя управляемый гипертекстом веб-сервис RESTful, клиент не должен ничего знать о макете URI сервера, за исключением пары известных точек входа. Это должно позволить серверу контролировать собственное пространство URI и уменьшить связь с клиентом.

Когда клиент службы отправляет успешный запрос на создание нового ресурса, служба отвечает 201 CREATED и выдает URI, по которому можно получить доступ к новому ресурсу, в поле заголовка Location.

Следует ли разрешить клиенту хранить этот URI для обеспечения прямого доступа к ресурсу в будущем и, если да, то как долго? Если клиент кэширует URI, похоже, что это создает ситуацию, в которой каждый раз, когда сервер меняет свой макет URI, ему нужно будет обеспечить постоянное перенаправление при обращении к старым URI. В противном случае клиент ломается. Через несколько лет эта система перенаправлений может выйти из-под контроля.

Эта ситуация, по-видимому, не предоставила бы серверу намного больший контроль над его пространством URI, чем гибридный подход REST-RPC с использованием шаблонов URI.

Существует много информации о кэшировании представлений, но как насчет кэширования URI в гипертекстовых системах RESTful?

Answer 1

Помните, как сказал Тим Бернерс-Ли: «крутые URL не меняются». Как только сервер передает URI клиенту, теперь задача сервера состоит в том, чтобы поддерживать URI в будущем, например, отправляя ответ Moved-Permanently в случае, если URI изменился и кто-то запросил старый.

Это именно то, что побуждает многих создавать непрозрачные URI, например, на основе идентификаторов базы данных или временных меток, а не использовать какое-либо удобочитаемое свойство ресурса в URI. Все, что люди понимают, они захотят изменить.

Answer 2

Да, клиенту должно быть разрешено хранить URI. Столько, сколько захочет. Как упоминал Лики, умный клиент может использовать ответ Moved-Permanently для обновления своих закладок.

Если подумать, у нас самая лучшая ситуация. Вы можете изменить URL-адреса на сервере, одновременно выбирая поддержку старых клиентов, пока мы выбираем, и интеллектуальные клиенты могут автоматически обновлять себя до новых URL-адресов.

То, как долго вы решите продолжать поддерживать эти старые URL-адреса, действительно является решением, которое необходимо принять на основе существующих клиентов и легкости, с которой их можно поддерживать.

Для меня это огромное улучшение по сравнению с проблемами управления версиями в стиле RPC.

Answer 3

Я знаю, что это старый вопрос, но я думаю, что есть ответы, которые я вижу здесь, и которые не были рассмотрены.

Помните, что вы не получаете ресурс с сервера, но вы получаете ПРЕДСТАВЛЕНИЕ ресурса. Сам ресурс может изменить свой первичный идентификатор, или изменить его, или что-то еще, но представление, которое было возвращено клиенту при создании ресурса, может (или не может) быть действительным независимо; все дело в ситуации.

В качестве примера рассмотрим систему загрузки модерируемого контента; пользователь может иметь возможность загружать контент для рассмотрения модераторами, что в конечном итоге может привести к тому, что контент будет представлен более широкой аудитории / рынку. При начальной загрузке сервер может ответить URI, который указывает (скажем) «users / {userid} / uploaded / {contentid}» для этого представления этого контента. В какой-то момент модераторы могут принять решение о продвижении контента на «первую страницу»; это представление контента затем может быть доступно по URI "content / {contentid}"; это не должно помешать исходному загрузчику получить доступ к своим данным в «users / {userid} / uploaded / {contentid}»; ничто не говорит о том, что должен быть постоянный редирект, и на самом деле, есть все основания не быть; если пользователь решит, что он хочет удалить контент, он должен иметь возможность выполнить УДАЛЕНИЕ контента; вероятно, гораздо предпочтительнее, чтобы пользователи делали УДАЛЕНИЯ к представлениям контента из своих «загруженных» мест. Однако если условия сайта указывают на то, что права пользователя на загруженный контент аннулированы (не редкость), может иметь смысл эффективно продвигать процесс модерации, удаляя контент из собственной области пользователя, вызывая «постоянное перемещение».

Это действительно полностью зависит от конкретной ситуации; срок действия кэшированного URI полностью зависит от политик сервера. По крайней мере, я думаю, что запрос к недействительному URI (который, возможно, был ранее действителен) должен вызывать ответ (в соответствии с HATEOAS), который может позволить клиенту «заново открыть» ресурс (представление), который он искал ; по крайней мере, ссылка на точку входа.

Answer 4

Поскольку одним из принципов REST является то, что ресурсы являются адресуемыми, для клиента вполне приемлемо отслеживать адрес (URI) для данного ресурса.Ресурсные URI должны быть одной из «хорошо известных точек входа», на которые вы ссылались.