Айтигребец - канал душного сеньора помидора.
Ссылочки, мысли и прочая IT-годнота. Технологии, статьи, интервью etc. Расширяем кругозор и гребём тугеза.
17 лет фуллстека, сейчас мастли бэк. 10 лет .NET, 7 лет Node.js
Связь : @ytrihT
Post #198
614
Audio
В последнем выпуске #радиот затронули холиварненькую тему 404-ого статуса REST API.
Вот есть у вас к примеру
Первый лагерь уповает на то, что REST является самодостаточным и в его природе миксать http коды и коды бизнес-логики.
Второй лагерь же явно против, т.к. вообще-т 404-ый код говорит нам, что resource not found. И в данном примере не понятно - это ресурс not found или book not found? Как реагировать? Потому что во втором случае это by design, а в первом, возможно - критическая ошибка (допустим route криво запилили).
Буквально год-полтора назад мы поднимали эту тему в команде и я был приверженец именно второго лагеря.
В целом, фронту всё равно, там оба варианта - ошибка. Однако, я считаю, что чем детальнее ошибка, тем лучше фронт сможет её обработать. И если в случае resource not found - нужно бить тревогу и показывать плашечку, что что-то КРИТИЧНО пошло не так, то в первом - это может быть вполне себе user-friendly попапчик с сообщением о том, что такой книги нет.
Я всё же против миксать http коды и коды внутренней логики. Но у больших дядь можно встретить оба варианта реализации, однако чаще всего я всё же видел 200-ый ответ вида
Однако я могу понять и первый лагерь. В случае, если ваш клиент не браузер к примеру, 404-ый статус тоже вполне себе подойдёт для обработки ответа. За все 14 лет я ни разу не видел чистой реализации REST API в проектах, везде был mixed подход. А это, имхо, намекает.
Хоть отрывок из подкаста и длится 37 минут - я очень советую вам послушать, комментарии весьма интересные.
А какую http таблетку выбираешь ты? Голосуйте эмоджами 😂
😁 - лагерь 404
🤩 - лагерь 200 +payload
Вот есть у вас к примеру
/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
- 😁 25
- 🤩 24
- 🤔 3
- 👍 2
- 🌚 1
