Должен ли этот вызов GET вернуть 204 или 200 с телом?

Question

Скажем, у нас есть API отдыха, который объединяет данные о Человеке из других сервисов. Один из сервисных маршрутов Агрегатора - GET /person/(person id)/driverinfo, который сообщает нам, является ли человек лицензированным водителем или нет, идентификатор лицензии, срок действия лицензии и количество нарушений правил дорожного движения. Эти данные могут быть получены Агрегатором из одной или нескольких других служб. Этот API-интерфейс будет использоваться веб-страницей для отображения «информации о водителе» о человеке. Он также будет проверен с помощью автоматизации.

В настоящее время API не дает 204 никакого ответа на контент для лиц, которые никогда не имели водительских прав. Это потому, что один из лежащих в основе apis дает 204 для этого сценария. Итак, было решено, что Агрегатор должен сделать то же самое.

Но я считаю, что это не очень хороший ответ. Вместо этого мы должны вернуть 200 с соответствующими значениями для полей. Например, licensed = false, licenseId = N.A. и т. Д., Когда базовый API дает 204. Т.е. Агрегатор должен генерировать эти поля и их значения.

Какой подход, по вашему мнению, лучше и почему?

Answer 1

204 означает что-то конкретное в HTTP; он говорит, что сервер нашел представление запрошенного ресурса, и это представление имеет длину 0 байтов.

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

В частности, в контексте HTTP сами заголовки уже имеют значительную длину (по сравнению с нулем), поэтому я не ожидал бы, что будут особенно веские причины производительности для сжатия сигнала до нулевой длины. Например, если бы мы обычно передавали application / json , я бы ожидал, что отправка пустого объекта или массива будет намного более экономически эффективной, чем вообще ничего не отправлять.