Verilerin POST'una karşı 400'e karşı 422 yanıtı

Üzerinde çalıştığım bir "REST benzeri" API ile farklı senaryolarda geri dönmek için doğru durum kodunu anlamaya çalışıyorum. Diyelim ki JSON biçiminde POST'ing satın alımlarına izin veren bir bitiş noktam var. Şöyle görünüyor:

{
    "account_number": 45645511,
    "upc": "00490000486",
    "price": 1.00,
    "tax": 0.08
}

Müşteri bana "sales_tax" (beklenen "vergi" yerine) gönderirse ne yapmalıyım. Şu anda 400'ü iade ediyorum. Ama kendimi bu konuda sorgulamaya başladım. Gerçekten bir 422 iade? Yani, JSON (desteklenen) ve geçerli JSON, sadece gerekli alanların tümünü içermiyor.

400 Hatalı İstek artık kullanım durumunuz için en iyi HTTP / 1.1 durum kodu gibi görünmektedir.

Sorunuz sırasında (ve orijinal cevabım), RFC 7231 bir şey değildi; bu noktada itiraz ettim 400 Bad Requestçünkü RFC 2616 (benimkini vurgulayarak):

İstek, hatalı biçimlendirilmiş sözdizimi nedeniyle sunucu tarafından anlaşılamadı .

ve açıkladığınız istek sözdizimsel olarak geçerli olan JSON sözdizimsel olarak geçerli HTTP ile kaplıdır ve bu nedenle sunucunun isteğin sözdizimiyle ilgili bir sorunu yoktur .

Ancak Lee Saferite'nin yorumlarda belirttiği gibi , RFC 2616'yı geçersiz kılan RFC 7231, bu kısıtlamayı içermez :

400 (Hatalı İstek) durum kodu, sunucunun, istemci hatası olarak algılanan bir şey (örneğin, hatalı biçimlendirilmiş istek sözdizimi, geçersiz istek iletisi çerçeveleme veya aldatıcı istek yönlendirmesi) nedeniyle isteği işleyemeyeceğini veya işlemeyeceğini gösterir.

Bununla birlikte, bu yeniden ifade etmeden önce (veya şu anda sadece önerilen bir standart olan RFC 7231 hakkında tartışmak istiyorsanız), kullanım durumunuz için yanlış bir HTTP durum kodu 422 Unprocessable Entitygibi görünmemektedir , çünkü RFC 4918'e girişin dediği gibi:

HTTP / 1.1 tarafından sağlanan durum kodları, WebDAV yöntemlerinin karşılaştığı çoğu hata koşulunu tanımlamak için yeterli olsa da, mevcut kategorilere düzgün bir şekilde girmeyen bazı hatalar vardır. Bu belirtim WebDAV yöntemleri için geliştirilen ek durum kodlarını tanımlar (Bölüm 11)

Ve açıklaması422 :

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.

(Sözdizimine yapılan referansa dikkat edin; 7231'in 4918'in de kısmen eskimiş olduğundan şüpheleniyorum)

Bu tam olarak sizin durumunuza benziyor, ancak herhangi bir şüphe olması durumunda şöyle devam ediyor:

Ö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.

("XML" yerine "JSON" yazın ve durumunuzun bu olduğunu kabul edebileceğimizi düşünüyorum)

Şimdi, bazıları RFC 4918'in "Web Dağıtılmış Yazma ve Sürüm Oluşturma (WebDAV) için HTTP Uzantıları" hakkında olduğunu ve (muhtemelen) WebDAV ile ilgili hiçbir şey yapmadığınızı itiraz edecektir, bu yüzden ondan bir şeyler kullanmamalısınız.

Orijinal standartta açıkça durumu kapsamamakta olan bir hata kodu kullanma ve durumun tam olarak açıklandığı bir uzantıdan biri arasındaki seçim göz önüne alındığında, ikincisini seçerim.

Ayrıca, RFC 4918 Bölüm 21.4 , 422'nin bulunabileceği IANA Köprü Metni Aktarım Protokolü (HTTP) Durum Kodu Kayıt Defterine atıfta bulunur.

Bir HTTP istemcisinin veya sunucusunun, doğru bir şekilde yaptıkları sürece, bu kayıt defterindeki herhangi bir durum kodunu kullanmasının tamamen makul olduğunu öneriyorum.

Ancak HTTP / 1.1'den itibaren, RFC 7231'in çekişi vardır, bu yüzden sadece kullanın 400 Bad Request!

400 Hatalı İstek , kullanım durumunuz için uygun HTTP durum kodudur. Kod HTTP / 0.9-1.1 RFC tarafından tanımlanır.

İstek, hatalı biçimlendirilmiş sözdizimi nedeniyle sunucu tarafından anlaşılamadı. İstemci, değişiklik yapmadan isteği tekrarlamamalıdır.

http://tools.ietf.org/html/rfc2616#section-10.4.1

422 İşlenemeyen Varlık RFC 4918 - WebDav tarafından tanımlanır. 400 ile karşılaştırıldığında küçük bir fark olduğunu unutmayın, aşağıdaki alıntı metne bakın.

Bu hata koşulu, bir XML istek gövdesi iyi biçimlendirilmiş (yani sözdizimsel olarak doğru), ancak anlamsal olarak hatalı XML talimatları içeriyorsa oluşabilir.

Tek tip arabirimi korumak için 422'yi yalnızca XML yanıtlarında kullanmalısınız ve ayrıca Webdav uzantısı tarafından tanımlanan tüm durum kodlarını desteklemelisiniz, sadece 422'yi değil.

http://tools.ietf.org/html/rfc4918#page-78

Ayrıca Mark Nottingham'ın durum kodları hakkındaki yazısına bakın:

uygulamanızın her bir bölümünü HTTP durum kodlarıyla "derinden" eşlemeye çalışmak bir hatadır; çoğu durumda amaçlamak istediğiniz ayrıntı düzeyi çok daha kaba olur. Şüphe duyduğunuzda, daha iyi bir uyum olmadığında genel durum kodları 200 OK, 400 Bad Request ve 500 Internal Service Error kullanmak doğru olur .

HTTP Durum Kodları Hakkında Düşünme

2015 itibarıyla durumu yansıtmak için:

Davranışsal olarak hem 400 hem de 422 yanıt kodları müşteriler ve aracılar tarafından aynı şekilde ele alınacaktır, bu nedenle kullandığınız somut bir fark yaratmaz .

Ancak şu anda 400'ün daha yaygın olarak kullanıldığını ve ayrıca HTTPbis spesifikasyonunun sağladığı iki durum kodundan daha uygun olmasını sağlıyor:

• HTTPbis spesifikasyonu 400'ün sadece sözdizimi hataları için olmamasını amaçlamaktadır. Geniş deyim "sunucunun, istemci hatası olarak algılanan bir şey nedeniyle isteği işleyemeyeceğini veya işlemeyeceğini gösterir" kullanıldı.
• 422 Özellikle bir WebDAV uzantısıdır ve RFC 2616'da veya daha yeni HTTPbis spesifikasyonunda belirtilmez .

Bağlam için, HTTPbis, HTTP / 1.1 spesifikasyonunun, belirsiz veya tutarsız olduğu alanları netleştirmeye çalışan bir düzeltmesidir. Onaylanan duruma ulaştıktan sonra RFC2616'nın yerini alır.

Örnek olay: GitHub API

https://developer.github.com/v3/#client-errors

Belki iyi bilinen API'lerden kopyalamak akıllıca bir fikirdir:

İstek gövdelerini alan API çağrılarında üç tür istemci hatası vardır:

Geçersiz JSON göndermek 400 Hatalı İstek yanıtıyla sonuçlanır.

HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

Yanlış türde JSON değerleri göndermek 400 Hatalı İstek yanıtıyla sonuçlanır.

HTTP/1.1 400 Bad Request
Content-Length: 40

{"message":"Body should be a JSON object"}

Geçersiz alanların gönderilmesi 422 İşlenemez Varlık yanıtıyla sonuçlanır.

HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Issue",
      "field": "title",
      "code": "missing_field"
    }
  ]
}

Doğru bir cevap yoktur, çünkü isteğiniz için "sözdizimi" tanımının ne olduğuna bağlıdır. En önemli şey şu ki:

1. Yanıt kodlarını tutarlı bir şekilde kullanın
2. API'nızı kullanarak geliştiricilerin neler olup bittiğini anlamalarına yardımcı olmak için yanıt gövdesine mümkün olduğunca fazla bilgi ekleyin. =

Herkes burada doğru ya da yanlış bir cevap olmadığını söylediğim için zıplamadan önce, sonuca nasıl geldiğimi biraz açıklayayım.

Bu özel örnekte, OP'nin sorusu beklenenden farklı bir anahtar içeren bir JSON isteği ile ilgilidir. Şimdi, alınan anahtar adı, doğal dil açısından beklenen anahtara çok benzer, ancak kesinlikle farklıdır ve bu nedenle (genellikle) bir makine tarafından eşdeğer olarak tanınmaz.

Yukarıda söylediğim gibi, belirleyici faktör sözdizimi ile kastedilen şeydir . İstek bir İçerik Türü ile gönderildiyse application/json, evet, istek geçerli JSON sözdizimi olduğu için sözdizimsel olarak geçerlidir, ancak semantik beklenenle eşleşmediği için geçerli değildir. (söz konusu talebin anlamsal olarak geçerli olup olmadığını kesin olarak tanımlayarak).

Öte yandan, istek, aşağıdaki gibi daha spesifik bir özel İçerik Türü ile gönderildiyse application/vnd.mycorp.mydatatype+json , belki de tam olarak hangi alanların beklendiğini belirtirse, isteğin sözdizimsel olarak geçersiz olabileceğini, dolayısıyla 400 yanıtın olduğunu söyleyebilirim.

Söz konusu durumda , değer değil anahtar yanlış olduğu için, geçerli anahtarların ne olduğuna dair bir belirtim varsa bir sözdizimi hatası oluştu . Geçerli anahtarlar için bir spesifikasyon yoksa veya hata bir değerdeyse , değerdeyse anlamsal bir hata olur.

422 İşlenmemiş Varlık Açıklaması Güncelleme: 6 Mart 2017

422 İşlenemez Varlık Nedir?

Bir istek iyi biçimlendirildiğinde 422 durum kodu oluşur, ancak semantik hatalar nedeniyle işlenemez. Bu HTTP durumu RFC 4918'de tanıtıldı ve daha özel olarak Web Dağıtılmış Yazma ve Sürüm Oluşturma (WebDAV) için HTTP uzantılarına yöneliktir.

Geliştiricilerin istemcilere 400'e karşı 422 hatası döndürüp döndürmeyeceği konusunda bazı tartışmalar vardır (aşağıdaki her iki durum arasındaki farklar hakkında daha fazla bilgi). Ancak, çoğu durumda, 422 durumunun yalnızca WebDAV özelliklerini desteklediğinizde döndürülmesi gerektiği konusunda anlaşmaya varılmıştır.

RFC 4918'in 11.2 bölümünden alınan 422 durum kodunun sözcük-kelime tanımı aşağıda okunabilir.

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.

Tanım devam ediyor:

Ö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.

400 vs 422 Durum Kodları

Hatalı istek hataları 400 durum kodunu kullanır ve istek sözdizimi hatalı biçimlendirilmişse, geçersiz istek iletisi çerçevesi içeriyorsa veya aldatıcı istek yönlendirmesi varsa istemciye iade edilmelidir. Bu durum kodu, işlenemeyen 422 varlık durumuna oldukça benzeyebilir, ancak bunları ayıran küçük bir bilgi parçası, bir 422 hatası için bir istek varlığının sözdiziminin doğru, 400 üreten bir isteğin sözdiziminin doğru olmasıdır. hata yanlış.

422 durumunun kullanımı sadece çok özel kullanım durumları için ayrılmalıdır. Hatalı oluşturulmuş sözdizimi nedeniyle bir istemci hatasının oluştuğu diğer çoğu durumda, 400 Hatalı İstek durumu kullanılmalıdır.

https://www.keycdn.com/support/422-unprocessable-entity/

Davan: HTTP 400 göndermek için kendi sözdizimi yanlış olarak DİNLENME perspektiften dava için doğru durum kodu sales_taxyerine taxonun geçerli bir JSON olsa. Bu normalde, JSON'u nesnelerle eşlerken sunucu tarafı çerçevelerinin çoğu tarafından uygulanır. Ancak, keyJSON nesnesinde yeniyi yok sayan bazı REST uygulamaları vardır . Bu durumda, bir özelcontent-type yalnızca geçerli alanları kabul etmek için şartname sunucu tarafı tarafından uygulanabilir.

422 İçin İdeal Senaryo:

İdeal bir dünyada, 422 sunucu talep varlığının içerik türünü anlarsa ve talep varlığının sözdizimi doğruysa, ancak anlamsal olarak hatalı olduğu için verileri işleyemediğinde tercih edilir ve genellikle yanıt olarak göndermek için kabul edilebilir.

422'nin üzerindeki 400 durumlar:

Yanıt kodunun (422) uzatılmış bir HTTP (WebDAV) durum kodu olduğunu unutmayın. Hala 422 işlemek için hazır olmayan bazı HTTP istemcileri / ön uç kütüphaneleri vardır. Onlar için, "HTTP 422 yanlıştır, çünkü HTTP değil" . Hizmet açısından 400 tam olarak belli değil.

Kurumsal mimaride, hizmetler çoğunlukla SOA, IDM vb. Hizmet katmanlarına dağıtılır. Genellikle çok eski bir yerel istemciden en son HTTP istemcilerine kadar çok sayıda istemciye hizmet ederler. İstemcilerden biri HTTP 422'yi işlemezse, seçenekler istemciden yanıt kodunuzu herkes için HTTP 400'e yükseltmesini veya değiştirmesini istemektir. Deneyimlerime göre, bu bugünlerde çok nadir ama yine de bir olasılık. Bu nedenle, HTTP yanıt kodlarına karar vermeden önce mimarinizin her zaman dikkatli bir şekilde incelenmesi gerekir.

Bu gibi durumlarla başa çıkmak için, hizmet katmanları normalde katı HTTP uygunluk istemcilerinin 400 ve geri kalanı için 422 göndermek için bayrağını kullanır versioningveya ayarlar configuration. Bu şekilde mevcut tüketiciler için geriye dönük uyumluluk desteği sağlarlar, ancak aynı zamanda yeni istemcilerin HTTP 422'yi kullanmalarını da sağlarlar.

RFC7321'e yönelik en son güncelleme şöyle diyor:

The 400 (Bad Request) status code indicates that the server cannot or
   will not process the request due to something that is perceived to be
   a client error (e.g., malformed request syntax, invalid request
   message framing, or deceptive request routing).

Bu, sunucuların geçersiz istek için HTTP 400 gönderebileceğini doğrular. 400 artık sadece sözdizimi hatasına atıfta bulunmuyor , ancak 422, istemcilerin işleyebilmesi koşuluyla hala gerçek bir yanıt.

Öncelikle bu çok iyi bir soru.

400 Hatalı İstek - İstekte kritik bir bilgi eksik olduğunda

örn. Yetkilendirme üstbilgisi veya içerik türü üstbilgisi. Hangi kesinlikle sunucu tarafından isteği anlamak için gereklidir. Bu sunucudan sunucuya değişebilir.

422 İşlenemeyen Varlık - İstek gövdesi ayrıştırılamadığında.

Bu 400'den daha az şiddetlidir. İstek sunucuya ulaştı. Sunucu, isteğin temel yapıya sahip olduğunu kabul etti. Ancak istek gövdesindeki bilgiler ayrıştırılamaz veya anlaşılamaz.

örneğin Content-Type: application/xml, istek gövdesi JSON olduğunda.

Durum kodlarını ve REST API'lerindeki kullanımını listeleyen bir makale. https://metamug.com/article/status-codes-for-rest-api.php

Aslında "200 TAMAM" döndürmelisiniz ve yanıt gövdesinde yayınlanan verilerle ilgili bir mesaj içermelidir. Sonra mesajı anlamak uygulamanıza kalmıştır.

Mesele şu ki, HTTP durum kodları tam olarak budur - HTTP durum kodları. Ve bunların uygulama katmanında değil, sadece taşıma katmanında bir anlamı olması gerekir. Uygulama katmanı asla HTTP'nin kullanıldığını bile bilmemelidir. Taşıma katmanınızı HTTP'den Homing Pigeons'a değiştirdiyseniz, uygulama katmanınızı hiçbir şekilde etkilememelidir.

Size sanal olmayan bir örnek vereyim. Diyelim ki bir kıza aşık oluyorsun ve seni geri seviyor ama ailesi tamamen farklı bir ülkeye taşınıyor. Sana yeni salyangoz-posta adresini veriyor. Doğal olarak, ona bir aşk mektubu göndermeye karar veriyorsunuz. Böylece mektubunuzu yazar, bir zarfa koyarsınız, adresini zarfın üzerine yazarsınız, üzerine bir damga koyar ve gönderirsiniz. Şimdi bu senaryoları ele alalım

1. Bir sokak adı yazmayı unuttunuz. Açılmamış bir mektup, adresin hatalı biçimlendirildiğini belirten bir mesajla birlikte alacaksınız. İsteği iptal ettiniz ve alıcı postane bunu başaramıyor. Bu, "400 Kötü İstek" almanın karşılığıdır.
2. Böylece adresi düzeltip mektubu tekrar gönderirsiniz. Ancak bazı kötü şanslar nedeniyle sokak adını tamamen yanlış yazdınız. Mektubun adresin mevcut olmadığını belirten bir mesajla tekrar alacaksınız. Bu, "404 Bulunamadı" mesajını almanın karşılığıdır.
3. Adresi yeniden düzeltirsiniz ve bu kez adresi doğru yazmayı başarırsınız. Kızınız mektubu alır ve size geri yazar. Bu "200 OK" almanın karşılığıdır. Ancak, bu onun mektubunda yazdıklarını seveceğiniz anlamına gelmez. Bu sadece mesajınızı aldığı ve sizin için bir yanıtı olduğu anlamına gelir. Zarfı açana ve mektubunu okuyana kadar seni çok özlediğini ya da senden ayrılmak isteyip istemediğini bilemezsin.

Kısacası: "200 OK" döndürmek, sunucu uygulamasının sizin için iyi haber olduğu anlamına gelmez. Bu sadece bazı haberleri olduğu anlamına gelir.

Not: 422 durum kodunun yalnızca WebDAV bağlamında bir anlamı vardır. WebDAV ile çalışmıyorsanız, 422 diğer standart olmayan kodlarla aynı standart anlama sahiptir = hiçbiri.