Что будет хорошим HTTP-ответом, чтобы показать существование сущности?

Question

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

GET    /order/:order-ref   

Я мог бывозвратите полезную нагрузку JSON следующим образом:

{
  true
}

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

Answer 1

Это кажется тяжелым.

Как и CodeCaster указал , это неверный JSON, и я не вижу, как это можетсчитаться тяжелым .

Я думал просто вернуть HTTP-статус, чтобы указать то же самое.

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

HEAD /orders/1 HTTP/1.1
Host: example.org

Цитирование RFC 7231 , документ, определяющий семантику и содержание протокола HTTP / 1.1:

4.3.2. HEAD

Метод HEAD идентичен GET за исключением того, что сервер НЕ ДОЛЖЕН отправлять тело сообщения в ответе (т. Е. Ответ заканчивается в конце раздела заголовка). [...]

Какой HTTP-статус правильный в этом случае?

Если ресурс существует, вернуть 200. В противном случае верните 404.

HTTP/1.1 200 OK
Date: Tue, 8 Oct 2019 13:39:14 GMT

HTTP/1.1 404 Not Found
Date: Tue, 8 Oct 2019 13:39:14 GMT

Answer 2

, но кажется тяжелым

Помимо того, что это недопустимый JSON, действительно ли 4 байта (если вы возвращаете true) или 18 ({ "exists": true }) действительно так "тяжелы"?

А что, если клиент захочет просмотреть фактические данные заказа, ему нужен еще один вызов?

А какая часть точно "тяжелая", возвращающая пару байтов по уже открытому соединению, или подключающаяся к вашей базе данных и ищущая, чтобы определить, существует ли фактический заказ?

Но выможет вернуть пустой 200 OK или 204 No Content, если вы действительно хотите сбрить несколько байтов. Но я бы рекомендовал против этого, см. Выше.

Answer 3

это кажется тяжелым

Это тяжело - вы пытаетесь обозначить один бит (вкл / выкл), и для этого вы перетаскиваете весь заголовок HTTP вместе свы. В зависимости от того, какие инструменты вы используете, вы можете урезать коллекцию заголовков, но вы будете ощущать большой вес.

Какой статус HTTP правильный в этом случае?

Там действительно нет хорошего ответа. В некоторых случаях вы увидите, что 204 означает, что что-то существует, а 404 - что нет. Это не правильно делать;компоненты общего назначения не интерпретируют строку состояния таким образом. Но если вы управляете клиентом или если вы можете передавать свою семантику за пределы группы, это, вероятно, не будет слишком болезненным.

Github Starring API работает таким образом.

GET /user/starred/:owner/:repo

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

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