Могу ли я использовать пользовательские причины для кода состояния 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 игнорируют текст сообщения.
