Соответствует ли HATEOAS? GET тот же адрес с разными результатами

Question

Соответствует ли HATEOAS ресурсам через GET /resources, когда этот вызов каждый раз возвращает другой ресурс?

Например, чтобы распределить ресурсы по клиентам, в соответствии с некоторым внутренним алгоритмом, то есть я не хочу, чтобы каждый клиент получал всегда один и тот же ресурс (допустим, я закодировал сервер «фраза дня» и распределял их случайным образом) :

Первый вызов: GET/ресурсы

200 OK 
{ 
    "_links" : { "self" : "/resources/1" }, 
    "data" : "foo" 
} 

Второй вызов: GET/ресурсы

200 OK 
{ 
    "_links" : { "self" : "/resources/2" }, 
    "data" : "bar" 
} 

Или лучше, чтобы обеспечить GET /resources/chooser, который возвращает объект links конкретному ресурсу и совершает второй звонок?

Answer 1

HATEOAS - это ссылки на следующие ссылки. Поэтому, пока вы не раскрываете эти операции (за исключением получения корня API) в качестве ссылок с метаданными (например, «self» в вашем примере), он выполняет ограничение HATEOAS. Стандартов URI нет, просто предложения. Например, проще маршрутизировать вызовы для названных ресурсов. Обратите внимание, что для клиента REST структура URI не имеет значения, поскольку она проверяет метаданные ссылок, чтобы решить, хочет ли она следовать по ссылке.

В вашем текущем примере /resources должен иметь собственные описательные метаданные, например rel=chooser или что-то в этом роде. Таким образом, клиент будет знать, о чем идет речь. Я думаю, что ваша структура URI нарушает стандарт URI, потому что путь описывает иерархическую часть URI, но в текущем случае нет иерархии между /resources и /resources/1, /resources/2 URI. Поэтому, если вы хотите создать и псевдоним или с вашим выбором слов «chooser», гораздо лучше использовать /resources/chooser или /resources?chooser=true.

Answer 2

Чтобы ответить на ваш прямой вопрос, предполагается, что/resource является точкой входа вашего приложения или у вас есть ресурс root, который ссылается на/resource, он, безусловно, удовлетворяет ограничению HATEOAS.

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

Я всегда был в замешательстве относительно идемпотентности GET. Вы можете искать с помощью GET, и если они что-то обновят, то такое же GET может изменить результат. Конечно, это что-то другое, меняющее состояние ... но я помню, что читаю, что они изменят рейтинги на основе кликов по результатам. Это тоже ПОЛУЧИТЬ ... так ??

Если бы это был мой API, и было бы не очень важно сделать запрос POST только, я, вероятно, поеду с POST 406 a GET. Если мне действительно нужно ПОЛУЧИТЬ, я бы слишком беспокоился об этом.