Предположим, что / person / 1 возвращает человека с идентификатором 1 из БД. Если человек не существует, я должен вернуть статус 404? Как я должен различать, если конечная точка не существует на сервере или ресурс не существует?
Для клиента не имеет значения, существовал ли ресурс или конечная точка. Все, что говорит сервер, - это то, что для данного URI нет доступного представления.
Как уже упоминалось в inf3rno, клиент обычно обслуживает все URI, которые клиент будет нуждаться сервером непосредственно в ответе. Посредством закладки или включения ссылок в некоторый внешний ресурс определенные ссылки могут со временем стать недействительными, и поэтому ответ 404 Not Found просто сообщает клиенту, что для данного URI нет доступных представлений.
Клиент, как правило, также не интересуется внутренними компонентами API, а просто отправляет или получает данные, с которыми он может работать.
Еще одно заблуждение многих пользователей, к сожалению, заключается в том, что они уже предполагают, что определенные ресурсы возвращают определенные типы . Такие типы могут привести к сбоям на стороне клиента, если ожидаемый формат представления когда-либо изменится. В дополнение к этому сама структура URI, включая любые параметры пути, матрицы и запроса, не должна использоваться для вывода какой-либо логической структуры API, его открытых конечных точек или логической структуры ресурсов для других ресурсов этого API. URI в целом является указателем на ресурс. Ресурс может иметь десятки ссылок, указывающих на него. Вы можете рассматривать URI как ключ кеша для возвращаемых представлений, которые при последовательных вызовах далее обслуживаются кешем, а не самим сервером. На самом деле это одно из ограничений, налагаемых REST и широко используемых в Интернете.
Теперь давайте предположим, что у меня есть конечная точка POST для вставки пользователей. Что если эта конечная точка проверяет, правильно ли сформировано электронное письмо, и я возвращаю 400? Как мне узнать, был ли запрос сформирован неправильно и не был направлен на какие-либо сервлеты или он действительно достиг сервлета, который решил, что электронная почта неправильно сформирована?
RFC 7231 определяет POST как универсальный инструмент, который следует использовать, если другие методы не подходят для выполняемой задачи. В нем четко указано, что полезная нагрузка, предоставляемая этим методом, будет processed according to the resource's own specific semantics. Так что, если вам нужно проверить адрес электронной почты пользователя перед его сохранением или перед началом расчета, фонового процесса или чего-то еще, хорошо, сделайте это :) Даже PUT , который часто заменяет текущее представление с указанным в запросе не только разрешено, но и поощряется к выполнению проверок относительно любых ограничений, которые сервер имеет для целевого ресурса, и поэтому он должен отклонять полезные нагрузки, которые не соответствуют его ожиданиям.
Суть здесь в том, что сервер должен всегда предоставлять клиенту как можно больше информации, чтобы позволить клиенту определить, что делать дальше. Подумайте о веб-приложении, к которому вы обращаетесь через браузер. Если вы получите 400 Bad Request, браузер обычно скажет, что серверу не понравилось в вашем запросе, то есть неполный синтаксис или пропущенное значение обязательного поля. То же самое относится и к API-интерфейсам REST, поскольку они в основном являются обобщением модели взаимодействия, используемой в Интернете. То же самое относится и к сети и к REST:)
Таким образом, каждый код состояния HTTP имеет свою семантику и должен помочь клиенту определить, что клиент должен делать дальше. A 400 Bad Request т.е. означает, что сервер либо не может, либо не будет обрабатывать запрос из-за чего-то, что сервер считает ошибкой на основе клиента, и клиент должен исправить эту ошибку и повторно отправить запрос .
A 405 Method Not Allowed, с другой стороны, указывает, что клиент использовал метод HTTP, не поддерживаемый целевой конечной точкой. Ответ об ошибке указывает не только клиенту, но и какие методы разрешены на целевой конечной точке в заголовке ответа Alllow.
Каждый из кодов состояния HTTP, указанных в RFC 7231 , имеет свою семантику и, вероятно, желательно хотя бы просмотреть их. Вы также можете просмотреть все доступные коды состояния по адресу IANA , в котором приведены ссылки на спецификации, описывающие эти коды состояния.
Является ли хорошей практикой всегда возвращать ответ 200 OK от всех моих сервлетов, указывающий, что приложение выполнило свою работу, независимо от результата, и записывать статус в поле состояния json или это излишнее и антирасширенное действие? рисунок
Как и с кодами ошибок, также коды успеха (в диапазоне 200) имеют свою семантику. Если в результате обработки запроса создается новый ресурс (через PUT или POST), клиент должен получить уведомление с ответом о состоянии 201 Created о том, что дополнительно содержит заголовок HTTP Location, содержащий URI, нацеленный на вновь созданный ресурс. созданный ресурс.
Если серверу может потребоваться некоторое время для вычисления ответа, вероятно, целесообразно вернуть ответ 202 Accepted, чтобы проинформировать клиента об ожидающем запросе. Позже клиент может опрашивать запрос либо после некоторого порогового периода, либо после получения уведомления от сервера через механизмы обратного вызова, такие как уведомление по электронной почте или аналогичные вещи. Из-за ограничений немецкого законодательства, то есть немецкие компании должны вести архивы своих сообщений, которыми обмениваются через EDI. Мы, как поставщик EDI, предлагаем нашим клиентам выполнить архив своих обмененных сообщений посредством запуска одной из наших конечных точек HTTP. В зависимости от количества сообщений, которыми обменивается эта компания, и выбранного периода времени, для которого должен быть создан архив, этот процесс может занять некоторое время (несколько часов, чтобы быть более конкретным), и вместо того, чтобы позволить клиенту ждать этот период, мы просто верните 202 Accepted и запустите процесс архивирования в конце. В зависимости от конфигурации они либо опрашивают готовый архив, либо получают информацию об окончательном результате, либо напрямую отправляют архив по электронной почте, если размер файла не слишком велик.
204 No Content также весьма полезно, если клиент выполняет обновление ресурса. Поскольку PUT обычно определяется как замена текущего представления на представленное в полезной нагрузке, после получения ответа 204 No Content клиент знает, что сервер применил обновление, и текущее представление действительно выглядит как запрошенное клиентом. Таким образом, серверу не нужно дополнительно информировать клиента о том, как выглядит текущее представление, поскольку клиент уже знает, как оно должно выглядеть. Однако в случае, если серверу пришлось преобразовать полезную нагрузку в другое представление, которое может привести к другому результату, вероятно, полезно сообщить клиенту о новом состоянии ресурса в ответе 200 OK, включая представление результат процесса обновления.
Возвращение 200 OK для сбоя, включающего полезную нагрузку JSON с полями, указывающими на ошибку, безусловно, является плохим способом продолжения. Он не только дает клиентам неверную подсказку, но и посредники могут также кэшировать ответ и возвращать его другим клиентам, запрашивающим то же самое, даже если сбой может иметь временный характер (сбой БД и т. П.). В дополнение к этому такая полезная нагрузка JSON, вероятно, использует нестандартизированный формат и, таким образом, требует внеполосных знаний для фактической обработки сообщения. В то время как мы, люди, вполне способны понять, что происходит, компьютеры сами по себе еще не настолько умны.
Надеюсь, вы видите, что HTTP предлагает много семантики о том, когда, какой метод или код ответа использовать.Они существуют по какой-то причине и поэтому также должны использоваться, если обстоятельства правильные.