Неправильно ли возвращать 202 «Принято» в ответ на HTTP GET?

У меня есть набор ресурсов, представления которых создаются лениво. Вычисления для построения этих представлений могут занять от нескольких миллисекунд до нескольких часов, в зависимости от загрузки сервера, конкретного ресурса и фазы луны.

Первый запрос GET, полученный для ресурса, запускает вычисление на сервере. Если вычисление завершается в течение нескольких секунд, возвращается вычисленное представление. В противном случае возвращается код состояния 202 «Принято», и клиент должен опрашивать ресурс, пока не станет доступно окончательное представление.

Причина такого поведения следующая: если результат доступен в течение нескольких секунд, его необходимо получить как можно скорее; в противном случае не важно, когда он станет доступен.

Из-за ограниченной памяти и огромного количества запросов ни NIO, ни длинный опрос не являются вариантом ( т.е. я не могу поддерживать почти достаточное количество открытых подключений, и даже не могу вместить все запросы в память; один раз «несколько секунд») прошли, настаиваю на лишние запросы). Точно так же ограничения клиентов таковы, что они не могут вместо этого обрабатывать обратный вызов завершения. Наконец, обратите внимание, что я не заинтересован в создании "фабричного" ресурса, на который отправляется один POST, поскольку дополнительные циклы передачи означают, что мы нарушаем кусочное ограничение в реальном времени больше, чем требуется (кроме того, это дополнительная сложность; кроме того, это ресурс, который выгода от кеширования).

Я предполагаю, что есть некоторые разногласия по поводу возврата кода состояния 202 «Принято» в ответ на запрос GET, поскольку я никогда не видел этого на практике, и его наиболее интуитивно понятное использование - это ответ на небезопасные методы, но я никогда не нашел что-нибудь, что конкретно его обескураживало. Более того, разве я не сохраняю и безопасность, и идемпотентность?

Итак, что люди думают об этом подходе?

EDIT : я должен упомянуть, что это для так называемого бизнес-веб-API, а не для браузеров.

Если это для четко определенного и документированного API, 202звучит как раз для того, что происходит.

Если это для общедоступного Интернета, я бы слишком беспокоился о совместимости клиентов. Я видел так много if (status == 200)жестко запрограммированных .... В этом случае я бы вернул 200.

Кроме того, RFC не указывает, что использование 202 для запроса GET является неправильным, но делает четкие различия в других описаниях кода (например, 200).

Запрос принят в обработку, но обработка не завершена.

Мы сделали это для недавнего приложения, клиент (пользовательское приложение, а не браузер) отправил запрос POST, и сервер вернул бы 202 с URI для отправляемого «задания» - клиент будет использовать этот URI для опроса для результат - похоже, это хорошо сочетается с тем, что было сделано.

В любом случае самое важное - это документировать, как работает ваш сервис / API, и что означает ответ 202.

Насколько я помню, GET должен возвращать ресурс без изменения сервера. Возможно, активность будет регистрироваться или что у вас, но запрос должен быть повторно запущен с тем же результатом.

С другой стороны, POST - это запрос на изменение состояния чего-либо на сервере. Вставить запись, удалить запись, запустить задание, что-то в этом роде. 202 подходит для POST, который вернулся, но не завершен, но на самом деле это не запрос GET.

Все это очень пуритански и плохо практикуется в дикой природе, поэтому вы, вероятно, в безопасности, вернув 202. GET должен вернуть 200. POST может вернуть 200, если он завершен, или 202, если он не выполнен.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

В случае ресурса, который должен иметь представление объекта, который четко указан идентификатором (в отличие от ресурса «фабрики», как описано в вопросе), я рекомендую использовать метод GET и в ситуация, когда объект / представление недоступен из-за ленивого создания или любой другой временной ситуации, используйте код ответа 503 Service Unavailable, который более подходит и был фактически разработан для ситуаций, подобных этой.

Причины этого можно найти в RFC для самого HTTP (пожалуйста, проверьте описание кода ответа 503), а также на многих других ресурсах.

Сравните с кодом статуса HTTP для временно недоступных страниц . Хотя этот вопрос касается другого варианта использования, на самом деле он относится к той же функции HTTP.