Dev Easy Notes

За всё время существования HTTP есть один спор, который, к моему удивлению, не прекращается до сих пор. В протоколе есть коды ошибок, которые возвращает сервер:

👉 200-е — всё ок,
👉 300-е — редиректы,
👉 400-е — косяк клиента,
👉 500-е — косяк сервера.

Спор всегда идёт о 400-х ошибках. Вот, например, у нас есть ресурс users/{id}. Если мы попытаемся обратиться по id, которого нет, что должен вернуть сервер: 404 или 400 со специальным описанием, что ресурс не найден?

На моей первой работе архитектор говорил, что 404 нужно возвращать только если мы обратились к endpoint-у, которого не существует, например, к persons/{id}, а не к users/{id}. Я с ним что тогда был не согласен, то и сейчас.

Меня вот что поражает. Группа очень умных людей разработала протокол, в котором учли всё, что можно. Чётко описали, какой код когда использовать. Написано широкую на широкую, ебанные волки, но нет — давайте спорить о фигне, которую уже давно решили.

Потому что если подумать, то обращение по несуществующему id и к неправильному endpoint-у — это одно и то же. В обоих случаях вы обращаетесь по неверному идентификатору, и в обоих случаях нужно возвращать 404.

Другой, самый ублюдский подход — это всегда возвращать 200, а ошибку описывать в теле ответа. Таких ребят я не в коем случае не виню, все таки писать код с лишними хромасомами тяжело. Наверное, есть мнение, что при ошибке нельзя вернуть тело, в котором можно описать, что за ошибка, поэтому будем использовать 200 хз.

Короче, не усложняйте там, где не нужно. Все библиотеки для работы с HTTP по умолчанию умеют обрабатывать коды ошибок — если они указаны как ожидается, а не когда мы возвращаем 500 если немного ошиблись в полях при запросе.

www.tgoop.com/dev_easy_notes/420

2.3K viewsedited  May 17 at 06:11

За всё время существования HTTP есть один спор, который, к моему удивлению, не прекращается до сих пор. В протоколе есть коды ошибок, которые возвращает сервер:

👉 200-е — всё ок,
👉 300-е — редиректы,
👉 400-е — косяк клиента,
👉 500-е — косяк сервера.

Спор всегда идёт о 400-х ошибках. Вот, например, у нас есть ресурс users/{id}. Если мы попытаемся обратиться по id, которого нет, что должен вернуть сервер: 404 или 400 со специальным описанием, что ресурс не найден?

На моей первой работе архитектор говорил, что 404 нужно возвращать только если мы обратились к endpoint-у, которого не существует, например, к persons/{id}, а не к users/{id}. Я с ним что тогда был не согласен, то и сейчас.

Меня вот что поражает. Группа очень умных людей разработала протокол, в котором учли всё, что можно. Чётко описали, какой код когда использовать. Написано широкую на широкую, ебанные волки, но нет — давайте спорить о фигне, которую уже давно решили.

Потому что если подумать, то обращение по несуществующему id и к неправильному endpoint-у — это одно и то же. В обоих случаях вы обращаетесь по неверному идентификатору, и в обоих случаях нужно возвращать 404.

Другой, самый ублюдский подход — это всегда возвращать 200, а ошибку описывать в теле ответа. Таких ребят я не в коем случае не виню, все таки писать код с лишними хромасомами тяжело. Наверное, есть мнение, что при ошибке нельзя вернуть тело, в котором можно описать, что за ошибка, поэтому будем использовать 200 хз.

Короче, не усложняйте там, где не нужно. Все библиотеки для работы с HTTP по умолчанию умеют обрабатывать коды ошибок — если они указаны как ожидается, а не когда мы возвращаем 500 если немного ошиблись в полях при запросе.

BY Dev Easy Notes