Неправильно ли возвращать 202 "принято" в ответ на HTTP GET?
У меня есть набор ресурсов, представления которых лениво создаются. Вычисление для построения этих представлений может занять от нескольких миллисекунд до нескольких часов, в зависимости от нагрузки на сервер, конкретного ресурса и фазы Луны.
первый запрос GET, полученный для ресурса, запускает вычисление на сервере. Если вычисление выполняется в течение нескольких секунд, вычисленное представление возвращается. В противном случае статус 202 " принято код возвращается, и клиент должен опросить ресурс, пока не будет доступно окончательное представление.
причина такого поведения заключается в следующем: если результат доступен в течение нескольких секунд, он должен быть получен как можно скорее; в противном случае, когда он становится доступным не важно.
из-за ограниченной памяти и огромного объема запросов ни NIO, ни длинный опрос не являются опцией (т. е. Я не могу держать достаточно открытые соединения, ни даже могу ли я даже поместить все запросы в память; как только" несколько секунд " прошли, я сохраняю избыточные запросы). Аналогично, ограничения клиента таковы, что они не могут обрабатывать обратный вызов завершения. Наконец, обратите внимание, что я не заинтересован в создании" фабричного " ресурса, который публикуется, поскольку дополнительные циклы означают, что мы не выполняем кусочное ограничение в реальном времени больше, чем требуется (кроме того, это дополнительная сложность; кроме того, это ресурс, который выиграет от кэширование.)
Я предполагаю, что есть некоторые разногласия по поводу возврата 202 "принятого" кода состояния в ответ на запрос GET, поскольку я никогда не видел его на практике, и его наиболее интуитивное использование-это ответ на небезопасные методы, но я никогда не находил ничего специально обескураживающего его. Кроме того, разве я не сохраняю безопасность и идемпотентность?
Итак, что же люди думают об этом подходе?
EDIT: я должен упомянуть, что это для a так называемый business web API-не для браузеров.
3 ответа:
Если это для четко определенного и документированного API,
202звуки ровно правильно для того, что происходит.Если это для общественного интернета, я бы слишком беспокоился о совместимости клиентов. Я видел так много
if (status == 200)жестко.... В таком случае, я бы вернул a200.и RFC не указывает, что использование 202 для запроса GET является неправильным, в то время как он делает четкие различия в других описаниях кода (например, 200).
запрос принят для обработки, но обработка не была завершена.
мы сделали это для недавнего приложения, клиент (пользовательское приложение, а не браузер) отправил запрос, и сервер вернет 202 с URI в публикуемую "работу" - клиент будет использовать этот URI для опроса результата - это, похоже, хорошо согласуется с тем, что было сделано.
самое главное здесь в любом случае документировать, как работает ваш сервис/API, и что означает ответ 202.
из того, что я могу вспомнить - GET должен возвращать ресурс без изменения сервера. Возможно, активность будет зарегистрирована или что у вас есть, но запрос должен быть перезапущен с тем же результатом.
POST с другой стороны-это запрос на изменение состояния чего-то на сервере. Вставьте запись, удалите запись, запустите задание, что-то в этом роде. 202 было бы уместно для сообщения, которое вернулось, но не закончено, но не совсем запрос GET.
Это все очень пуританские и не очень хорошо практикуются в дикой природе, так что вы, вероятно, в безопасности, вернувшись 202. GET должен вернуть 200. Сообщение может вернуть 200, если он закончил или 202, если это не сделано.