Вот есть у вас к примеру
/api/v1/books/1 - возвращает книгу с ID:1. Всё отлично, отдаём 200-ый код с книгой в body. Что делать с /api/v1/books/100, когда книга не найдена? И вот тут соль вопроса. Один лагерь топит за 404, второй - за 200 с payload : null. Первый лагерь уповает на то, что REST является самодостаточным и в его природе миксать http коды и коды бизнес-логики.
Второй лагерь же явно против, т.к. вообще-т 404-ый код говорит нам, что resource not found. И в данном примере не понятно - это ресурс not found или book not found? Как реагировать? Потому что во втором случае это by design, а в первом, возможно - критическая ошибка (допустим route криво запилили).
Буквально год-полтора назад мы поднимали эту тему в команде и я был приверженец именно второго лагеря.
В целом, фронту всё равно, там оба варианта - ошибка. Однако, я считаю, что чем детальнее ошибка, тем лучше фронт сможет её обработать. И если в случае resource not found - нужно бить тревогу и показывать плашечку, что что-то КРИТИЧНО пошло не так, то в первом - это может быть вполне себе user-friendly попапчик с сообщением о том, что такой книги нет.
Я всё же против миксать http коды и коды внутренней логики. Но у больших дядь можно встретить оба варианта реализации, однако чаще всего я всё же видел 200-ый ответ вида
{
payload : null
}
т.е. http тут является всё же уровнем транспорта.Однако я могу понять и первый лагерь. В случае, если ваш клиент не браузер к примеру, 404-ый статус тоже вполне себе подойдёт для обработки ответа. За все 14 лет я ни разу не видел чистой реализации REST API в проектах, везде был mixed подход. А это, имхо, намекает.
Хоть отрывок из подкаста и длится 37 минут - я очень советую вам послушать, комментарии весьма интересные.
А какую http таблетку выбираешь ты? Голосуйте эмоджами 😂
😁 - лагерь 404
🤩 - лагерь 200 +payload