в данном случае - его не существует

когда нет метода

ты спрашиваешь у неспециалиста)

я не программирую API

я не спрашиваю)

я контролирую выполнение задачи как менеджер

я пытаюсь обьяснить, что возвращать 404 не всегда уместно

http коды уместны для транспортного уровня

код ответа должен соответствовать тому, что там случилось, то есть кодов ответа у нас много, а не 3 штуки, мы смотрим таблицу и подбираем наиболее близкий

в случае, если такой метод не найден - имеет смысл отдавать 404ую, так как его нету

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

а вот в случае GET /api/v1/cars/{id}, когда не существует машины - не уместно отдавать 404ую

потому что такой метод существует

жёсткого стандарта тут нет, нельзя сказать "ты неправильно сделал, потому что вернул ХХХ код, а не УУУ", но разумно стараться подбирать наиболее близкие коды ответа, если они достаточно распространены

когда создаётся документ - код ответа должен быть 201, а не 200, потому что а.) он больше подходит б.) он распространён

так же неуместно возвращать 400 bad request, потому что синтакс запроса правильный

уместно возвращать 200 OK (роут и синтакс правильный)

и в теле

{ "status": "error", "code": xxx, "message": "car not found" }

так же неуместно возвращать 400 bad request, потому что синтакс запроса правильный

синтаксис чего? метода же нет

/api/v1/cars/{id} есть

но нет машины по такому айди

имеет смысл отдавать 200 OK

и ошибку в теле

/api/v1/car/{id} нету

поэтому имеет смысл отдавать 404, потому что нет метода

понимаешь разницу?)

http - транспортный уровень, он не должен отвечать за логику твоего приложения

за это должны отвечать твои внутренние коды ошибок

а так да.. единого стандарта в REST нет, поэтому и много говно APIшек))

в данном случае запрос /api/v1/car123 должен вернуть или 400 или 405

почему 400 то?)

/api/v1/car/123 в данном случае (если 123 нет ) то 404

до синтакса не доходит

/api/v1/car123 - 404

Not found - не найдено

/api/v1/car/123 - 200

и в теле написать, что нету такой машины

лан, хватит флудить, посмотри слэк)

400 это некая общая ошибка, плохой запрос), все другие 4xx её уточняют

так запрос не плохой)

такого запроса просто не существует)

400 не общая ошибка

400 Bad Request - The request could not be understood by the server due to malformed syntax.

при желании 400ой ошибкой можно заменить любую другую 4хх

Запрос не может быть понят сервером из-за неправильного синтаксиса.

но это будет криво и поверхностно

аналогично с 500, ею можно заменить все 5хх

ошибки 4хх - это ошибки клиента, который неправильно отправил запрос, ошибки 5хх - это ошибки сервера, который не знает, что ему делать, а запрос правильный

давай проектом заниматься, хватит флудить, глянь слэк))

/api/v1/car/123 - 200

if 200 <= response.status < 300 довольно частая проверка, впиливать туда еще и логику обработки джсона в теле не всегда хочеться

Тигран, ты написал ошибку, я тебя поправил) первый начал))

это не ошибка, это разные подходы)

при желании 400ой ошибкой можно заменить любую другую 4хх

нет 401, 403, 404, 405 нельзя заменять на 400

стандарта нет

http - транспортный уровень, он не должен отвечать за логику твоего приложения

Я запутался, почему http - транспортный уровень, если http протокол относиться к прикладному уровню TCP/IP?

мне нравится внутренний стандарт white-house

нет 401, 403, 404, 405 нельзя заменять на 400

ты можешь сослаться на rfc, который бы это запрещал?

если очень-очень-очень поверхностно делать, то у нас всего 3 состояния "всё ок", "клиент сделал ошибку" и "сервер сделал ошибку"

200, 400, 500

Я запутался, почему http - транспортный уровень, если http протокол относиться к прикладному уровню TCP/IP?

ошибься, извиняюсь) но суть не меняется

вот, я как раз сторонник 200, 400, 500

если мой балансировщик что то отдает - пусть

я как раз и хочу сказать, что такой подход (поверхностный) довольно плохой, и если есть возможность указать более точно ошибку - её стоит указать

логику приложения я делаю с помощью этих трех

а не 200-400-500

ты все не укажешь с помощью Http кодов

ERROR: S client not available

поэтому когда там не 200, а 201, лучше написать 201, если этот код лучше подходит

тебе в любом случае понадобятся внутренние коды

зачем ориентироваться и на то и на другое?

да, внутренние коды нужны, это вопрос про опрятность кода

можно не следовать PEP 8, всё будет работать

но мы же следуем?

у пейпала несколько сотен кодов ошибок

многие ты бы не смог впихнуть под определенный http код

конечно, берём самый близкий

а если их несколько?

и под то подходит и под другое

ну, обычно всегда есть тот, который ближе, если нет - можно регламентировать это

ну вот тот же пример с cars и car

ты можешь сослаться на rfc, который бы это запрещал?

тот, в котором описаны изначально коды. там указано для 400 "не может обработать", а дальше коды для "смог обработать, но что-то пошло не так"

на практике у каждой компании свой RESTful API с их собственными кодами ответа, единого стандарта тут нет

ты то предложил 400, то 404, то 405

да

поэтому и говорю, мне ближе white-house rest api standart

тот, в котором описаны изначально коды. там указано для 400 "не может обработать", а дальше коды для "смог обработать, но что-то пошло не так"

ну, все 4хх - это ошибки клиента, они именно так сгруппированы

именно поэтому 4

тот, в котором описаны изначально коды. там указано для 400 "не может обработать", а дальше коды для "смог обработать, но что-то пошло не так"

и на клиентской стороне по коду больше 400 (для 4хх) может произойти авторешение проблемы с повторным перезапросом

на прикладном уровне я возвращаю: 200 - с запросом все ок 400 - чувак, у тебя там что то не так 500 - сорян, у нас что то не так

лично я вообще не сторонник такого API, мне нравится JSON RPC

?

там вот нет этих холиваров

про коды

программирование вообще какая-то холиварная отрасль. А мы - алхимики

Ох скок понаписали интересного (

Я не хочу перечитывать это все , много тут ( Может напишите небольшой вывод?)

Use three simple, common response codes indicating (1) success, (2) failure due to client-side problem, (3) failure due to server-side problem: 200 - OK 400 - Bad Request 500 - Internal Server Error

https://github.com/WhiteHouse/api-standards

Оспаривали этот подход