У меня есть набор ресурсов, чьи представления лениво создаются. Вычисление для построения этих представлений может занять от нескольких миллисекунд до нескольких часов, в зависимости от нагрузки на сервер, конкретного ресурса и фазы луны.
Первый запрос GET, полученный для ресурса, запускает вычисления на сервере. Если вычисление завершается в течение нескольких секунд, вычисленное представление возвращается. В противном случае возвращается код состояния 202 «Принят», и клиент должен опрашивать ресурс, пока не будет доступно окончательное представление.
Причина такого поведения заключается в следующем: если результат доступен в течение нескольких секунд, его необходимо получить как можно скорее; в противном случае, когда он станет доступным, не важно.
Из-за ограниченного объема памяти и огромного объема запросов ни NIO, ни длительный опрос не являются опцией ( т.е. . Я не могу держать почти достаточно открытых соединений, и даже не могу даже удовлетворить все запросы в памяти; по прошествии нескольких секунд я сохраняю лишние запросы). Аналогично, ограничения клиента таковы, что они не могут обрабатывать обратный вызов завершения. Наконец, обратите внимание, что я не заинтересован в создании «фабричного» ресурса, к которому следует POST, так как дополнительные обходы означают, что мы терпим неудачу в кусочно-реальном ограничении в реальном времени больше, чем хотелось бы (более того, это дополнительная сложность; кроме того, это ресурс, который будет извлечь выгоду из кеширования).
Я полагаю, что существует некоторая полемика по поводу возврата кода состояния «Принятый» 202 в ответ на запрос GET, поскольку я никогда не видел его на практике, а его наиболее интуитивное использование - в ответ на небезопасные методы, но я Я никогда не находил ничего особенно обескураживающего. Кроме того, я не сохраняю безопасность и идемпотентность?
Итак, что люди думают об этом подходе?
РЕДАКТИРОВАТЬ : Я должен упомянуть, что это для так называемого бизнес-веб-API, а не для браузеров.