REST Соглашение об именах Api?

Question

У меня есть простой вопрос, на который я не могу найти ответ.

Мой коллега в настоящее время создает REST Api для приложения, и у нас есть вызов, который просто проверяет некоторую информацию и возвращает либо true, либоложный.Однако мы не знаем, как вызвать этот тип запроса, так как он не извлекает какие-либо ресурсы и ничего не вставляет, он просто проверяет некоторую информацию, переданную в запрос.Насколько я понимаю, GET должен извлечь ресурс, который этот вызов не делает

Answer 1

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

Технически, он извлекает ресурс;см. Fielding

Ключевая абстракция информации в REST - это ресурс.Любая информация, которая может быть названа, может быть ресурсом: документ или изображение, временная служба (например, «сегодняшняя погода в Лос-Анджелесе»), коллекция других ресурсов, не виртуальный объект (например, человек) и т. Д.,Другими словами, любая концепция, которая может быть целью гипертекстовой ссылки автора, должна вписываться в определение ресурса.

Ресурс, в этом случае, может не загружать объект в вашу модель данных, но это нормально.Не все ресурсы должны.

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

Но нет ничего плохого в наличии ресурсаэто «результат функции».

В некоторых API вы увидите предикаты (функции, которые возвращают истину / ложь), реализованные как ресурсы, которые существуют только (точнее, имеют только «представления»), еслиоценка верна.

GET /predicate?true

204 No Content

GET /predicate?false

404 Not Found

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

Answer 2

Что я понимаю, так это то, что ресурс в этом случае является либо истинным, либо ложным.При вызове API вы будете ожидать ответа «истина» или «ложь» на основе информации, обрабатываемой сервером API (статус всегда будет 200).Таким образом, метод GET все еще подходит для этого случая.Если вас не интересует тело ответа, и вам нужны такие данные, как код ответа и данные заголовка, используйте HEAD.

Answer 3

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

Итак, давайте возьмем произвольный пример.Вы моделируете сообщения в блоге и хотите знать, установлено ли для какого-либо сообщения в блоге "черновик".

Статусом "черновика" может быть собственный ресурс, например:

/posts/hello-world/is-draft

Выполнение запроса GET на ресурсе is-draft может привести к:

{
   "is-draft": true
}

Таким образом, чтобы смоделировать произвольные вещи как ресурсы, лучший способ подумать об этом - посмотреть на результат операции как на«представление» и «то, что вы хотите знать» как URI.

Answer 4

Трудно сказать по уровню детализации, которую вы задали для своего вопроса.Но если вам нужно проверить, существует ли ресурс, вы можете использовать HEAD.Он идентичен GET, но не возвращает представление в полезной нагрузке ответа: он возвращает только код состояния и заголовки ответа.

Рассмотрим следующий запрос HEAD запрос:

HEAD /postal-codes/10001 HTTP/1.1
Host: example.org
Content-Type: application/json

Он должен вернуть 200 для ресурса, который существует:

HTTP/1.1 200 OK
Content-Type: application/json

И 404 для ресурса, который не существует:

HTTP/1.1 404 Not Found
Content-Type: application/json

---

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

Например, рассмотрим следующий запрос и ответы:

POST /postal-codes/validation HTTP/1.1
Host: example.org
Content-Type: application/json

{ "postal-code": "10001" }

HTTP/1.1 200 OK
Content-Type: application/json

{ "postal-code": "10001", "status": "valid" }

HTTP/1.1 200 OK
Content-Type: application/json

{ "postal-code": "10001", "status": "invalid" }