Doğru HTTP durum kodu yanlış girişe

200 (her şey yolunda değil) ancak girişte hata bildirmediğinde en uygun HTTP yanıt kodu nedir?

Örneğin, sunucuya bazı veriler gönderirsiniz ve verilerinizin yanlış olduğu yanıtlanır

kullanarak 500Sunucu Sorunu gibi daha görünüyor
kullanarak 200uyarı / hata yanıtı metin ile kötü (önbelleğe sağlayan ve her şey tamam değil) olduğu
kullanarak 204, hiçbir şey ve geri dönen (ama iyi desteklenen?) belki iyidir
kullanılarak 404istenen yol (script) mevcuttur ve eğer yanlış uygun yerde

API'mızı yaparken de aynı sorunu yaşadık. İle eşdeğer bir HTTP durum kodu arıyorduk InvalidArgumentException. Aşağıdaki kaynak makaleyi okuduktan sonra 422 Unprocessable Entityhangi durumları kullandık:

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.

kaynak: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm

4 (4xx) ile başlayan kodlar istemci hataları içindir. Belki 400 (Kötü İstek) bu davaya uygun olabilir mi? Http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html'deki tanım :

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

RFC Spesifikasyonuna ek olarak, bunu çalışırken de görebilirsiniz. Twitter yanıtlarına göz atın.

https://developer.twitter.com/en/docs/ads/general/guides/response-codes

409 Conflict kabul edilebilir bir çözüm olabilir.

Buna göre: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Kaynağın geçerli durumu ile bir çakışma nedeniyle istek tamamlanamadı. Bu koda yalnızca kullanıcının çakışmayı çözebileceği ve isteği yeniden gönderebileceği durumlarda izin verilir. Yanıt kuruluşu kullanıcının çatışmanın kaynağını tanıması için yeterli bilgi içermelidir. İdeal olarak, yanıt veren varlık, sorunu çözmek için kullanıcı veya kullanıcı aracısı için yeterli bilgi içerir; ancak bu mümkün olmayabilir ve gerekli değildir.

Doküman bir örnekle devam ediyor:

Çatışmaların bir PUT isteğine yanıt olarak ortaya çıkması muhtemeldir. Örneğin, sürüm oluşturma kullanılıyorsa ve PUT olan varlık, önceki (üçüncü taraf) bir istek tarafından yapılanlarla çakışan bir kaynakta değişiklikler içeriyorsa, sunucu, isteği tamamlayamayacağını belirtmek için 409 yanıtını kullanabilir . Bu durumda, yanıt veren varlık, iki tür arasındaki yanıtın Content-Type tarafından tanımlanan bir biçimde farklılıklarının bir listesini içerecektir.

Benim durumumda, bir API aracılığıyla bir veritabanına benzersiz olması gereken bir dize PUT istiyorum. Veritabanına eklemeden önce, veritabanında olmadığını kontrol ediyorum.

Eğer öyleyse, geri döneceğim "Error: The string is already in the database", 409.

Ben OP istediğini bu olduğuna inanıyorum: veri sunucunun kriterlerini geçmediğinde uygun bir hata kodu.

Aşağıdaki senaryoya göre,

Diyelim ki birisi sunucunuzdan doğru biçimdeki, ancak "iyi" veri olmayan verilerle bir istekte bulunuyor. Örneğin, birinin bir API uç noktasına bir String değeri bekleyen bir String değeri gönderdiğini düşünün; ancak, dizenin değeri kara listeye alınan verileri içeriyordu (ör. kişilerin şifre olarak "şifre" kullanmasını engelleme). durum kodu 400 veya 422 olabilir?

Şimdiye kadar, w3.org'a göre: "400 Kötü İstek" i geri verirdim:

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

Bu açıklama duruma tam olarak uymuyor; ancak, HTTP / 1.1 protokolünde tanımlanan temel HTTP durum kodları listesine giderseniz, muhtemelen en iyi seçeneğinizdir.

Ancak son zamanlarda, Dev ekibimden biri [bana] popüler API'lerin hata raporlarında daha ayrıntılı bilgi almak için HTTP uzantılarını kullanmaya başladığını belirtti. Özellikle Twitter ve Recurly gibi birçok API, WebDAV için HTTP uzantısında tanımlandığı gibi "422 İşlenemez Varlık" durum kodunu kullanıyor. HTTP durum kodu 422 şunları belirtir:

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.

Yukarıdaki şifre örneğimize geri dönersek, bu 422 durum kodu çok daha uygun geliyor. Sunucu ne yapmaya çalıştığınızı anlar; ve gönderdiğiniz verileri anlar; verilerin işlenmesine izin vermez.

404 - Bulunamadı - İstenen URI geçersiz veya kullanıcı gibi istenen kaynak mevcut olmadığında kullanılabilir.