HTTP 202 Kabul Edildi (HTTP / 1.1)
HTTP 202 Accepted
Durum arıyorsun . RFC 2616'ya bakınız :
İstek işleme alındı, ancak işleme tamamlanmadı.
HTTP 102 İşleme (WebDAV)
RFC 2518 kullanmanızı önerir HTTP 102 Processing
:
102 (İşleme) durum kodu, müşteriye sunucunun tüm isteği kabul ettiğini, ancak henüz tamamlamadığını bildirmek için kullanılan geçici bir cevaptır.
ama bir ihtar var:
Sunucu, istek tamamlandıktan sonra son bir yanıt göndermelidir.
Son cümleyi nasıl yorumlayacağımdan emin değilim. Sunucu, işlem sırasında herhangi bir şey göndermekten kaçınmalı ve yalnızca tamamlandıktan sonra yanıt vermeli mi? Ya da sadece zorlar sona yalnızca işlem sonlandırıldığında yanıtı? İlerlemeyi bildirmek istiyorsanız bu yararlı olabilir. HTTP 102 gönderin ve yanıtı baytla (veya satır satır) temizleyin.
Örneğin, uzun ama doğrusal bir işlem için, her karakterden sonra sifon çekerek yüz nokta gönderebilirsiniz. İstemci tarafı (bir JavaScript uygulaması gibi) tam olarak 100 karakter beklemesi gerektiğini biliyorsa, kullanıcıya göstermek için bir ilerleme çubuğu ile eşleşebilir.
Başka bir örnek, doğrusal olmayan birkaç basamaktan oluşan bir işlemle ilgilidir. Her adımdan sonra, sonunda kullanıcıya gösterilecek olan bir günlük mesajını aktarabilirsiniz, böylece son kullanıcı işlemin nasıl gittiğini bilebilir.
Aşamalı yıkama ile ilgili sorunlar
Bu tekniğin yararları varken, bunu tavsiye etmemeyi unutmayın . Bunun sebeplerinden biri, bağlantının açık kalmaya zorlamasıdır; bu hizmet kullanılabilirliği açısından zarar verebilir ve iyi ölçeklenemez.
Daha iyi bir yaklaşım, HTTP 202 Accepted
işlemin bitip bitmediğini (örneğin , sürece kadar /process/result
HTTP 404 Bulunamadı veya HTTP 409 Uyuşmazlığı ile yanıt verecek olan belirli bir URI'yi çağırarak) kullanarak yanıt vermek ve kullanıcının size daha sonra geri dönmesini sağlamaktır. bittiğinde ve sonuç hazırdır) veya müşteriyi örneğin bir mesaj kuyruğu servisi ( örneğin ) veya WebSockets üzerinden geri arayabiliyorsanız, işlem tamamlandığında kullanıcıyı bilgilendirin .
Pratik örnek
Videoları dönüştüren bir web hizmeti hayal edin. Giriş noktası:
POST /video/convert
HTTP isteğinden bir video dosyası alır ve onunla birlikte biraz sihir yapar. Büyünün CPU-yoğun olduğunu hayal edelim, bu nedenle isteğin aktarılması sırasında gerçek zamanlı olarak yapılamaz. Bu, bir kez dosya transfer edildiğinde, sunucunun bir HTTP 202 Accepted
JSON içeriği ile cevap vereceği anlamına gelir, “Evet, videonuzu aldım ve üzerinde çalışıyorum; Gelecekte bir yerde hazır olacak ve ID 123 aracılığıyla erişilebilir olacak. ”
Müşterinin işlem bittiğinde bildirilmesi gereken bir mesaj kuyruğuna abone olma olasılığı vardır. İşlem tamamlandığında, müşteri işlenen videoyu aşağıdakilere giderek indirebilir:
GET /video/download/123
hangi bir yol açar HTTP 200
.
Müşteri bildirimi almadan önce bu URI'yi sorgularsa ne olur? Eh, sunucu ile cevap verecektir HTTP 404
, aslında, video henüz yok. Şu anda hazırlanabilir. Asla talep edilmeyebilir. Geçmişte bir süre olabilir ve daha sonra kaldırılabilir. Tek önemli olan elde edilen videonun mevcut olmaması.
Şimdi, müşteri yalnızca son videoya değil, ilerlemeye de önem veriyorsa (mesaj sırası hizmeti ya da benzeri bir mekanizma yoksa bu daha da önemli olurdu)?
Bu durumda, başka bir bitiş noktası kullanabilirsiniz:
GET /video/status/123
buna benzer bir cevap ortaya çıkacaktır:
HTTP 200
{
"id": 123,
"status": "queued",
"priority": 2,
"progress-percent": 0,
"submitted-utc-time": "2016-04-19T13:59:22"
}
İsteği tekrar tekrar yapmak, şu tarihe kadar olan ilerlemeyi gösterecektir:
HTTP 200
{
"id": 123,
"status": "done",
"progress-percent": 100,
"submitted-utc-time": "2016-04-19T13:59:22"
}
Bu üç tür istek arasında bir fark yaratmak çok önemlidir:
POST /video/convert
bir görevi sıraya koyar. Sadece bir kez çağrılmalıdır: tekrar çağırmak ek bir görevi sıraya koyar.
GET /video/download/123
operasyonun sonucuyla ilgilidir : kaynak videodur. İşlem - fiili sonucu talepten önce ve talebe bağımsız olarak hazırlamak için davlumbazın altında gerçekleşen olay bu değil. Bir veya birkaç kez çağrılabilir.
GET /video/status/123
başlı başına işleme ile ilgilidir . Hiçbir şeyi sıraya sokmaz. Elde edilen videoyu umursamıyor. Kaynak işleme kendisidir. Bir veya birkaç kez çağrılabilir.