Могу ли я использовать пользовательские причины для кода состояния HTTP для дифференциации ошибок для REST API

Я хочу различать отдельные типы ошибок "Not Found". Для примера дается следующий запрос:

GET /author/Adams/works/HHGTTG

Либо автор может быть "не найден", либо работа не может быть "не найдена", и я хочу провести различие между ними.

статус: 404 - автор не найден - статус: 404 - работа не найдена

Согласно спецификации, причина фразы может быть изменена. http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html

6.1.1 Код состояния и причина фразы

... Приведенные здесь фразы причины - это только рекомендации - они МОГУТ быть заменены локальными эквивалентами, не влияя на протокол...

Можно ли также использовать две уникальные фразы для одного и того же кода статуса?

И это звуковой подход или есть лучшее соглашение для указания более гранулированных ошибок?

В конечном счете, я хочу иметь клиентскую библиотеку, которая может генерировать исключение AuthorNotFound или WorkNotFound вместо общего исключения AuthorOrWorkNotFound.

ОТВЕТЫ

Ответ 1

При использовании вашего "затененного" не найденного подхода вы можете использовать 404 с телом ответа:

  • использовать статус 404 с текстовыми данными ( "автор не найден", "работа не найдена" ). Чтобы быть более гибким для языка, вы можете использовать метки (например, error.author.notFound)
  • используйте более структурированные и гораздо более легкие для анализа "подкоды" (например, 10 означает, что автор не найден, 11 пользователей не найдены).

Тем не менее я НЕ рекомендую вышеупомянутые субкоды, они добавляют много сложностей и усилий по обслуживанию для единого интерфейса HTTP. Структура вашей библиотеки api-client по-разному. Позвольте сначала называть /author/adams/work/11. Если он возвращает 404, тогда вызовите /author/adams/ рядом, чтобы узнать, был ли это недостающий автор, который вызвал 404. Затем вы можете бросить соответствующие исключения NotFound.

Другой альтернативой является создание конечного api-клиентского приложения по-разному. Сначала нужно вызвать /author/adams, тогда если бы не 404 продолжалось бы /author/adams/work. Таким образом, естественно, что само приложение идет по пути. Но это, конечно, работает только в том случае, если поток вашей страницы внутри интерфейса адаптируется к этой последовательности вызовов.

Ответ 2

У вас может быть тело ответа HTTP, содержащее сообщение, которое вы можете анализировать с любой дополнительной информацией.

Сообщение о статусе HTTP в коде состояния (в ответе) может быть любым, что вы хотите, и оно не будет влиять на клиентов. Обычно клиенты HTTP игнорируют текст сообщения.