Какой HTTP-код лучше всего подходит, когда конечная точка «заполнена»?
Если у вас есть конечная точка, к которой может быть открыто только ограниченное количество подключений (например, видеозвонок или очередь для сайта продажи билетов), что лучше всего HTTP Code сигнализировать клиенту, что конечная точка «заполнена», и они не можешь присоединиться?
Я рассмотрел следующее, но мне это не очень нравится:
423 Locked- Обычно это означает, что какой-то другой клиент временно запросил бабки на ресурсе. Кажется, это наименее плохо подходит для того, что я делаю.429 Too Many Requests- Обычно это означает, что клиент отправил слишком много, а не то, что в целом их слишком много.409 Conflict— Обычно это касается конфликтов слияния на ресурсе.400 Bad Request— Самый общий запасной вариант для необработанных запросов, но здесь он не совсем корректен. Запрос был в порядке, просто было слишком поздно.
Есть ли лучшие варианты, которые я упустил?
Ответы 2
Перестаньте искать правильный код состояния HTTP.
HTTP — это протокол передачи. Вместе со своим уродливым собратом (REST) он пытается притвориться, что он также является протоколом связи приложений, но у него это ужасно не получается, поэтому перестаньте пытаться использовать его так, как если бы он был таковым.
Что касается протокола передачи, то доставка запроса может иметь только два возможных исхода: либо запрос был успешно доставлен, либо нет.
После того, как запрос был успешно доставлен, обработка запроса может завершиться ошибкой из-за множества причин, специфичных для приложения, но эти причины не являются делом HTTP (или делом REST), о котором нужно что-либо знать. Тот факт, что эти протоколы были непродуманными, не означает, что их глупость должна распространяться в вечности.
Таким образом, в вашем случае результатом должен быть HTTP 200 Success, потому что запрос был успешно доставлен, а затем в полезной нагрузке ответа должна быть некоторая информация об ошибке для конкретного приложения (в каком-то формате для конкретного приложения), сообщающая пользователю, что некоторые предел был достигнут или какие-либо другие причины, которые у вас есть.
(Кэширующие прокси-серверы немного усложняют ситуацию, потому что им нужно знать, носит ли сбой временный или временный характер, но в вашем случае это не имеет значения, потому что вы все равно не возвращаете сбой, поэтому запрос может быть повторен.)
@LeandroBardelli Я только что назвал RFC2616 непродуманным, глупым и жалким провалом, поэтому неудивительно, что мой ответ не дает ожидаемого им результата. Но да ладно.
Я знаю, что вы правы в нескольких пунктах, и я верю в нечто подобное, поэтому я не проголосовал за вас
Поскольку 4xx зарезервированы для устранения неполадок на стороне клиента, вам следует использовать 5xx, потому что ваши критерии фильтрации (или проблема) находятся на стороне сервера.
Большинство серверов используют 503 Service Unavailable, когда они слишком заняты. В документации об этом указано, что используется для: temporary overloading
Исчерпывающую документацию о коде состояния см.: RFC 2616
Из РФЦ:
10.5.4 503 Служба недоступна
Сервер в настоящее время не может обработать запрос из-за
temporary overloadingили обслуживание сервера. Смысл
в том, что это временное состояние, которое облегчится после
некоторая задержка. Если известно, продолжительность задержки МОЖЕТ быть указана в
Заголовок Retry-After. Если Retry-After не указан, клиент ДОЛЖЕН
обрабатывать ответ так же, как и для ответа 500.Примечание. Наличие кода состояния 503 не означает, что сервер должен использовать его при перегрузке. Некоторые серверы могут пожелать просто отказаться от соединения.
Я не проголосовал за вас, но я понимаю, почему кто-то это делает, поскольку 200 - это неправильный код, поскольку ожидаемый результат в статье 10.2.1 RFC2616 не достигается. В этом случае ответ не в порядке, только для связи, а не для всего сообщения. т.е., если вы спросите меня о чем-то, а я отвечу вам «Я слишком занят, чтобы ответить вам прямо сейчас», это не нормально.