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

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

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

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

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

Я предполагаю, что существует некоторая разногласия по поводу возврата кода статуса "Принятый" 202 в ответ на запрос GET, поскольку я никогда не видел его на практике, и его наиболее интуитивное использование в ответ на небезопасные методы, но я "Я никогда не находил ничего, что специально обескураживало его. Кроме того, я не сохраняю как безопасность, так и идемпотентность?

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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