REST: Должен ли я перенаправлять URL-адрес версии объекта?

В настоящее время я работаю над службой REST. Эта служба имеет объект, который имеет разные версии, похожие на статьи в Википедии.

Теперь мне интересно, что я должен вернуть, если для

GET /article/4711

Должен ли я использовать (временное) перенаправление на текущую версию, например

GET /article/4711/version/7

Или мне нужно вернуть текущую версию напрямую? Использование перенаправления значительно упростило бы кеширование HTTP (используя Last-Modified), но имеет недостатки, которые имеет перенаправление (дополнительный запрос, "сложнее" реализовать). Поэтому я не уверен, что это хорошая практика.

Любые предложения, рекомендации или опыт для обмена?

(btw: когда-либо пытался найти "REST Version"? Все, что вы получаете, это версия API, а не сущности. Поэтому, пожалуйста, несите меня, если это дубликат.)

ОТВЕТЫ

Ответ 1

Если вы рассматриваете версии как сущности (которые по внешнему виду вы делаете), это то, что я предлагаю:

GET /article/4711

возвращает список всех версий (и ссылок на них). Что делает объект /article/4711 контейнером.

GET /article/4711/latest

возвращает содержимое последней версии. Возможно, вы захотите рассмотреть /version/latest, чтобы войти в строку ниже.

GET /article/4711/version/7

возвращает определенную версию статьи.

Ответ 2

Зависит от вашего предполагаемого поведения для GET /article/4711. Если он предназначен всегда для указания последней версии, то он должен возвращать последнюю версию напрямую. Перенаправление в определенную версию кажется проблематичным, поскольку вы полагаетесь на библиотеку пользователя/клиента, чтобы не посещать этот конкретный URL в будущем. Чтобы перевести на HTML-термины, пользователь может пометить URL-адрес version/7 и быть удивленным, что теперь они обращаются к более старой версии, а не к обновленной версии, изначально введенной в адресную строку.

Ответ 3

Возможно, вы захотите посмотреть http://tools.ietf.org/html/draft-brown-versioning-link-relations.

Используя отношения ссылок CMIS и заголовок HTTP Link, вы можете сделать /article/ 4711 последним и предоставить ссылку на версии, например. Ссылка: </article/4711/versions > ; rel= version-history

Ответ 4

Версия статьи и гипертекст

Если вы действительно обеспокоены созданием интерфейса RESTful, вам следует подумать о том, как это сделать в стиле HATEOS.

На мой взгляд, это будет означать возврат достаточной информации, которую пользователь сможет перемещать по списку изменений вашей организации. Если вы прочтете это от Роя...

"Интерфейс не нужно открывать. Он определен прямо в гипертексте. Представление сообщает клиенту, как составить все переходы в следующее состояние приложения"

... вы почувствуете, как ваш GET /article/4711 должен вернуть достаточную информацию в

  • Получить последнюю версию статьи

  • Получить следующую/предыдущую версию

Вы узнаете, что лучше всего подходит для вашей модели, но как указатель, который вы можете использовать с помощью тегов

  <link rel="older"
        type="text/html"
        href="http://www.yourdomain.com/article/4711?version=6"/>

...

Ответ 5

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

GET /article/4711

Вы также можете:

GET /article/4711/current

Возвращает текущую версию напрямую.