Должен ли данный URI в архитектуре RESTful всегда возвращать один и тот же ответ?

Question

Это своего рода дополнительный вопрос к этому .

Итак, имеет ли уникальный ответ для любого заданного URI основной клиент архитектуры RESTful? Много дискуссий здесь направлено в этом направлении, но я нигде не видел это как «жесткое и быстрое» правило.

Я понимаю его значение (для кэширования, сканирования, передачи ссылок и т. Д.), Но я также вижу, что такие вещи, как API-интерфейс Twitter, нарушают его (запрос на http://api.twitter.com/1/statuses/friends_timeline.xml будет зависеть от заданного имени пользователя), и я Понимать, что бывают случаи, когда это может быть необходимо, не говоря уже о том, что ресурс с хронологической страницей также будет меняться при добавлении новых элементов.

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

Answer 1

Не тот же ответ, но представление (которое зависит от заголовка connect и условного запроса) того же ресурса . В архитектуре отдыха URI идентифицируют один и только один ресурс (но ресурс может иметь несколько URI). Представление разных ресурсов в зависимости от авторизованного пользователя (HTTP-аутентификация, куки-файлы, ...) - плохая практика, поскольку один и тот же URI представляет отдельный ресурс для каждого пользователя, как в примере Twitter. Я не могу позволить вам просмотреть мою временную шкалу и дать вам URI, поскольку это тот же самый URI для вашей временной шкалы. Пользователь должен быть закодирован в URI, а доступ ограничен механизмом авторизации. Чтобы одна точка доступа представляла разные ресурсы в зависимости от аутентифицированного пользователя, используйте перенаправление (например, 303 См. Другое, 302 Найдено, ...)

Answer 2

Некоторые заголовки запроса изменяют то, что возвращается (оставаясь при этом RESTful):

1. Очевидно, что заголовки кеша будут использоваться для определения, будет ли возвращено значение 304 или 200
2. Заголовок Accept можно использовать для определения формата ответа (HTML против XML против JSON)
3. Заголовок Authorized может по крайней мере определить, возвращены ли 401, 403 или 200.
4. Кроме того, ресурсы могут меняться со временем.

Реальный вопрос заключается в том, можно ли использовать заголовок Authorized (который определяет пользователя) для изменения содержимого ответа. Я не видел никаких официальных заявлений по этому поводу, но подозреваю, что многие люди предпочитают, чтобы пользователь указывал URL-адрес и заголовок Authorized, используемый для проверки доступа. Я подозреваю, что в любом случае все еще ОТДЫХ.

Answer 3

Ничто в REST не говорит того же ответа - но вы должны быть готовы обрабатывать такие вещи, как заголовки запроса "If Modified Since", КОГДА ОНИ СМЫСЛИ;)

У Tritter API есть и другие проблемы, очевидно, как в: это дизайнерское решение. Например, если вы позволите изолировать временные линии друзей, имело бы смысл поместить временную шкалу ниже элемента имени друга - они, очевидно, отказались от этого;)

Это сводится к проектным решениям. Посмотрите на OData (например, http://odata.netflix.com/Catalog/) - здесь она заставляет snse возвращать одни и те же данные для каждого URL за заданное время (кэширование), поскольку это полностью общедоступный каталог. Для других сценариев это может не иметь смысла.