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

Question

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

GET /author/Adams/works/HHGTTG

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

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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