HTTP durum kodları bir sunucudaki iş mantığı hatalarını temsil etmek için kullanılmalı mıdır?

Ben bir istemci (bir tarayıcıda JS) bir sunucu ile konuşmak için bazı API tasarımı ile kavşak biraz. Geçerli bir güvenlik kilidi nedeniyle bir eylemin başarısız olduğunu göstermek için HTTP 409 Çakışması'nı kullanıyoruz. Satefy kilidi, geliştiricilerin müşterilerimizin üretim sistemlerinde yanlışlıkla değişiklik yapmasını önler. Belirli bir API çağrısının neden başarısız olduğunu belirtmek için istemcide 409'ları biraz daha zarif bir şekilde ele almakla görevlendirildim.

Benim çözümüm, 409 nedeniyle bir şey başarısız olduğunda istemcide bir bildirim gösterecek AJAX çağrılarımızdan herhangi birinin hata işleyicilerini sarmaktı - bu iyi ve aynı mekanizmayı kullanan diğer 4XX ve 5XX hatalarının yanında iyi çalışıyor.

Rota işleyicilerimizden birinin bir iş mantığı hatasıyla karşılaştığında 409'larla yanıt verdiği bir sorun ortaya çıktı - AJAX paketleyicim güvenlik kilidinin açık olduğunu bildirirken, müşterinin mevcut arıza işleyicisi sorunun gövdeye bağlı olduğunu (düşündüğünü) bildiriyor yanıt. Basit bir çözüm, işleyicinin yanıtını veya güvenlik kilidini temsil etmek için kullandığımız durum kodunu değiştirmek olacaktır.

Bu da beni kavşağa getiriyor: HTTP durum kodları iş mantığı hatalarını temsil etmek için bile kullanılmalı mı? Bu soru , karşılaştığım aynı sorunu ele alıyor, ancak fazla çekişmedi. Bağlantılı cevapta önerildiği gibi, iş mantığı içinde hatayı temsil etmek için uygun bir gövdeli HTTP 200 OK kullanmaya doğru eğildim.

Burada güçlü bir fikri olan var mı? Biri beni başarısızlığı temsil etmenin yanlış yolu olduğuna ikna edebilir mi?

Kasey ana noktayı kapsıyor.

Herhangi bir web API'sinde anahtar fikir: Alanınızı bir belge deposu gibi görünecek şekilde uyarlıyorsunuz. GET / PUT / POST / DELETE vb. Belge deposuyla etkileşimde bulunmanın tüm yollarıdır.

Dolayısıyla , hangi kodların kullanılacağını düşünmenin bir yolu, bir belge deposundaki benzer işlemin ne olduğunu ve bu hatanın o analogda nasıl görüneceğini anlamaktır.

2xx tamamen uygun değil

2xx (Başarılı) durum kodu sınıfı, istemcinin isteğinin başarıyla alındığını, anlaşıldığını ve kabul edildiğini gösterir.

5xx de uygun değil

Durum kodu 5xx (Sunucu Hatası) sınıfı, sunucunun hatalı olduğunu bildiğini gösterir

Bu durumda, sunucu hata yapmadı; şu anda o kaynağı bu şekilde değiştirmeniz gerekmediğinin farkındadır.

İş mantığı hataları (iş değişmezinin şu anda önerilen düzenlemeye izin vermediği anlamına gelir) muhtemelen 409'dur.

409 (Çakışma) durum kodu, hedef kaynağın geçerli durumu ile bir çakışma nedeniyle isteğin tamamlanamayacağını gösterir. Bu kod, kullanıcının çakışmayı çözebileceği ve isteği yeniden gönderebileceği durumlarda kullanılır. Sunucu, bir kullanıcının çakışmanın kaynağını tanıması için yeterli bilgi içeren bir yük oluşturmalıdır.

Bu son biti not edin - 409 yanıtının yükü, neyin yanlış gittiğine dair tüketiciye bilgi aktarmalı ve ideal olarak tüketiciyi çatışmanın çözümüne yardımcı olabilecek kaynaklara yönlendiren hiper ortam denetimlerini içermelidir.

Benim çözümüm, 409 nedeniyle bir şey başarısız olduğunda istemcide bir bildirim gösterecek AJAX çağrılarımızdan herhangi birinin hata işleyicilerini sarmaktı - bu iyi ve aynı mekanizmayı kullanan diğer 4XX ve 5XX hatalarının yanında iyi çalışıyor.

Ve bunu sorun olarak göstereceğim; istemcideki uygulamanız, durum kodunun sorunu tanımlamak için yeterli olduğunu varsaymıştır. Bunun yerine, müşteri kodunuz yükü gözden geçirmeli ve orada bulunan bilgilere göre hareket etmelidir.

Sonuçta, bir belge deposu bunu nasıl yapacaktı

409  Conflict

your proposed change has been declined because ${REASON}.  
The following resolution protocols are available: ${LINKS[@]})

A ile aynı yaklaşım 400 Bad Requestda kabul edilebilir; bu da kabaca "çevirir" İsteğinizle ilgili bir sorun oluştu. Hangi durum kodunun en uygun olduğunu anlamaya zahmet edemeyiz, işte buradasınız. Ayrıntılar için yüke bakın. "

422 kullanırdım. Giriş geçerli olduğundan 400 kullanmak için doğru hata kodu değil

WebDAV spesifikasyonu bu öneriyi içerir

422 (İşlenemeyen Varlık) durum kodu, sunucunun istek varlığının içerik türünü anladığı (bu nedenle 415 (Desteklenmeyen Medya Türü) durum kodu uygun değildir) ve istek varlığının sözdiziminin doğru olduğu (dolayısıyla 400 (Hatalı İstek) anlamına gelir. ) durum kodu uygun değil), ancak içerdiği talimatları işleyemedi. Örneğin, bir XML istek gövdesi iyi biçimlendirilmiş (yani sözdizimsel olarak doğru), ancak anlamsal olarak hatalı XML talimatları içeriyorsa bu hata koşulu oluşabilir.

Bunun bir eşleşme olduğuna inanmıyorum ( 400alternatif olarak şüphe duyduğumu kabul etmeme rağmen ). Benim yorumum şudur: 422"yanlış varlığı gönderdiniz"; 409"varlığı yanlış zamanda gönderdiniz".

Başka bir deyişle, 422istek iletisinin 409kaynağın geçerli durumu ile çakıştığını belirten, istek olarak ayrı ayrı ele alınan istek iletisiyle ilgili bir sorunu belirtir.

Ben Nadal'ın 422 tartışmasını dikkate almak yararlı olabilir.

Deneyimlerime göre, HTTP hata kodları iş hatalarını temsil etmek için yetersizdir. Bununla birlikte, hata sınıflarını temsil etmek için faydalıdırlar.

Bu nedenle, tavsiyem hata kategorileri için HTTP hata kodlarını kullanmak, ancak iş mantığı hataları için belirli bir hata seçmek (ör. 409 Çakışma ... 200 Tamam burada yanıltıcı olacaktır) ve yanıtta belirli iş hatasını gösteren verileri dahil etmek olacaktır . Bazı tarayıcılar özel durum metnini yok saydığından, durum metninin değil yanıt içeriğinin bir parçası olduğundan emin olun. Kullanmak istediğim dilde, mesajları temsil etmek için uygun Birlik Türleri var. Ancak hata durumları için dize sabitleri de tanımlayabilirsiniz.

Örnekler

// error with text response
409 Conflict "safety_lock_engaged"
409 Conflict "customer_not_eligible_for_selected_discount"
// warning with JSON response
202 Accepted { "backorderedProductIds": [ 37, 476 ] }

Genel olarak, belirli iş mantığı hatalarını temsil etmek için HTTP durum kodlarını kullanmaktan kaçınırım . Bunun nedeni, zaten dünya çapındaki standart tarafından tanımlanan anlamsal bir anlama sahip olmalarıdır. Diğer sistemler, yeni geliştiriciler ve benzeri standart sapması ile karıştırılacaktır.

Son zamanlarda yapılan benzer araştırmalarda bulduğum şey, 400 Bad Requestdoğrulama hataları ve benzeri durumlarda genellikle kabul edilmesiydi . Bu şekilde, tüm iş mantığı hataları için bir durum kodu kullanırsınız .

Bu arada, 409bir kaynağı siz düzenlerken değiştiğinde ve tekrar kaydetmeye çalıştığınızda kullanılmalıdır.

"Kötü İstek" i kullanabilir ve ihlal edilen iş kuralının kimliğini ve yanıtı daha açık bir şekilde ayrıntıları ekleyebilirsiniz.