REST 404 против 400. Какой из них использовать?

Я считаю, что это должен быть статус 404, поскольку запрос был действительным, однако customerID не был найден.

Я бы сказал, что в этом случае вы должны вернуть 404 Not Found.

Чтобы уточнить тему, моя интерпретация спецификаций в этом случае выглядит следующим образом:

400 Bad Request следует использовать в тех случаях, когда запрос был успешно получен приложением, и приложение определило, что с запросом что-то не так: либо конечная точка не существует, либо формат или природа параметров/переменных запроса были неправильными/ каким-то образом искажен, что делает запрос недействительным.

Это было бы в примере @Trevor Conn, где customerID в запросе имеет недопустимый формат (слишком длинный, слишком короткий, недопустимые символы и т. д.), и поиск или действие просто невозможно выполнить из-за ошибки.

Серия ответов 200 (как также упоминалось @Trevor Conn) указывает на успешную обработку запроса в отношении действительного объекта или субъекта.

204 No Content следует использовать в тех случаях, когда субъект был найден или действие было выполнено, а истинный и действительный вывод или результат запроса — Ничего.

Насколько я понимаю, это делает несколько вещей:

1. Это устраняет двусмысленность относительно истинного содержания ответа. Где 200 указывает на успех, но в противном случае пустой ответ может указывать на некоторую форму транспорта или сбой ответа. Вы прямо говорите клиенту: мы успешно нашли и/или сделали что-то, и истинный ответ — ничего.
2. Кроме того, хотя я сам не использую этот код, я считаю, что текущая поддержка браузера не позволяет заменять содержимое клиента. IE: если вы щелкнете по URL-адресу, который попал в конечную точку, которая вернула 204 No Content, это укажет браузеру, что запрос был успешным, но на самом деле никуда не перейдет (и окно просмотра, и текущий URI останутся без изменений).

В вашем случае 404 Not Found будет правильным ответом на запрос к действительной конечной точке с правильно отформатированным customerID, который не разрешается клиенту.

Небольшое погружение в кроличью нору...

Вы также можете отследить, какие действительные customerID были удалены/архивированы, и ответить 410 Gone, если они когда-то существовали, или 451 Unavailable For Legal Reasons, если клиент был удален по юридическому запросу.

Также следует отметить, что если вы работаете на языке ООП, вы можете находиться в экосистеме, где вы рассматриваете конечные точки/действия как методы.

Если вы действительно идете по кроличьей норе кодов ответов HTTP, стоит отметить, что использование 400 Bad Request в этом случае обрабатывает отсутствующие методы. Это отличается от 405 Method Not Allowed тем, что метод в Method Not Allowed относится к методу HTTP (GET/POST/PUT/DELETE). 405 следует использовать и использовать только в тех случаях, когда клиент пытается использовать один из этих методов против конечной точки, которая не поддерживает этот метод.

Примером этого может быть использование:

DELETE http://www.example.com/customers/{customerId}/orders

Где правильное использование:

DELETE http://www.example.com/customers/{customerId}/orders/{orderID}

И далее по кроличьей норе: «Не разрешено» строго относится к тому, реализован ли метод, и если у пользователя нет разрешений для выполнения другого реализованного HTTP-метода, правильным ответом будет 403 Forbidden или 401 Unauthorized, если разрешения клиента могут не может быть определено, потому что клиент еще не аутентифицирован вообще.

Еще Кроличья нора...

501 Not Implemented — это серверный индикатор сбоя HTTP-метода (в том смысле, что сам сервер, будь то Nginx, Apache или любой другой) на базовом уровне не поддерживает метод HTTP-запроса.

IE:

EXPELLIARMUS http://www.example.com/customers/{customerId}

205 Reset Content похож на 204 тем, что указывает на успех запроса, а также на действительно пустой ответ, за исключением того, что он указывает клиенту сбросить представление документа на месте (где 204 вообще не вызывает никаких действий).

Есть несколько разных способов сделать это.

Если вы проверяете тип {customerId} и обнаруживаете, что он полностью фальшивый, то 400 - Bad Request имеет смысл.

Однако, если {customerId} имеет допустимый формат и тип, но просто не существует, я бы предложил 204 - Нет содержимого. На мой взгляд, такой случай не является надлежащим образом 404, так как действие было обнаружено.

Если предположить, что пользователь предоставил допустимый путь, даже если идентификатор клиента 123456 не существует, тогда вызов выполнен успешно и не вернул никаких данных. Поэтому 204 Нет контента.

Статусы в диапазоне 200 также считаются статусами «успешно», поэтому вы можете убедиться, что ваш вызов действительно успешен для правильно отформатированного {customerId}. Однако определение того, является ли этот идентификатор действительным, вероятно, является обязанностью другой службы.