Kabul edilen isteğin sonucu görünür olmalı

Portaldaki başarı mesajı, kullanıcının güvendiği durumu doğrulamalıdır. Hazır rapor bekleyen kişi, alınabilir bir rapora ihtiyaç duyar. Oluşturma talebinin kabul edilmesi bunun ara adımıdır. Bu ayrım, ürünün kullanıcıya vereceği yanıtla ilgili bir karardır.

MDN, HTTP 202 kodunu henüz tamamlanmamış bir işlemin kabulü olarak açıklar. İş daha sonra başarısız olabilir. Microsoft bu tür asenkron akışlar için ayrı durum sorgulaması gösterir. İlk yanıtın HTTP kodu, portalın sonrasında ne göstereceği sorusunu kapatmaz.

Aynı kabul, iki arayüz

Kurgusal portalımızda J-73 rapor işi kabul edilir. Şablon başlangıçta mevcuttur ancak işlenmeden önce kaldırılır. Aşağıdaki karşılaştırma yapılmış bir kullanıcı testini değil, iki olası arayüzü anlatır.

İki arayüz de aynı kabul yanıtını almış olabilir. Buna rağmen farklı bilgi verirler. A’da teknik kabul, karşılanmamış bir iş beklentisini gizleyebilir. B, sonucu belli olana kadar işi görünür tutar.

Başarılı durum sorgusu iş hatası gösterebilir

Örnek API’miz durum kaynağının başarılı okunması için HTTP 200 ile şu içeriği döndürür:

{"jobId":"J-73","status":"failed","error":{"code":"template-not-found"}}

Sorgu çalışmıştır; rapor üretimi başarısızdır. Alan adları ve yanıt biçimi bize ait örnek kurallardır, bütün API’ler için zorunluluk değildir. Yalnız başarılı HTTP çağrılarını sayan bir değerlendirme bu işi gözden kaçırabilir. Kabul edilen istekler, tamamlanan raporlar ve başarısız işler farklı soruları yanıtlar.

Durum sorgusuna erişilemiyorsa işin güncel durumu bilinmez. Portal bundan raporun hazır olduğu veya işin kesin başarısız olduğu sonucunu çıkarmamalıdır. Yeni bir tıklama da mevcut işle ilişkilendirilmeli; belirsizlik ek işler oluşturarak büyütülmemelidir.

Kabul ne zaman yeterli sonuçtur?

Yalnız işi teslim alma işlevi, kalıcı kayıtla kararlaştırılan görevini tamamlayabilir. Bu durumda kabul olduğunu açıkça belirten onay uygundur. Benzer biçimde, senkron olarak tamamen biten bir işe sırf ilke olsun diye ek sorgu döngüsü gerekmez.

Rapor portalının amacı ise farklıdır: Kullanıcı dosyayı almak ister. Entegrasyon değerlendirmesi bu sonuca ve izlenebilir bir hata yoluna kadar uzanmalıdır. Hızlı ilk yanıt ayrı bir özelliktir; raporun kullanılabilir olduğunu kanıtlamaz.

Kaynaklar

• MDN: 202 Accepted

• Microsoft: Asynchronous Request-Reply pattern