İstekte gerekli bir parametre eksikse hangi HTTP durum yanıt kodunu kullanmalıyım?

Ben 412 (Önkoşul Başarısız) düşünüyorum ama daha iyi bir standart olabilir?

Durum 422 en çok spesifikasyona göre uygun görünüyor .

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.

Hatalı biçimlendirilmiş xml'nin kötü sözdiziminin bir örneği olduğunu belirtirler (400 çağrısında bulunur). Hatalı biçimlendirilmiş bir sorgu dizesi buna benziyor, bu yüzden 400 bir param eksik olan iyi biçimlendirilmiş bir sorgu dizesi için uygun görünmüyor.

UPDATE @DavidV, bu özelliğin çekirdek HTTP için değil, WebDAV için olduğunu doğru bir şekilde gösteriyor. Ancak bazı popüler WebDAV olmayan API'ler, daha iyi bir durum kodunun bulunmaması nedeniyle yine de 422 kullanıyor (buna bakın ).

Belirlenmiş bir standart olduğundan emin değilim, ancak en son HTTP spesifikasyonunun (2014'ten itibaren) aşağıdaki gibi belgelerini içeren 400 Kötü İstek'i kullanırdım :

6.5.1. 400 Hatalı İstek

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.

WCF API NET kulpları bir döndürerek parametreleri eksik HTTP 404kullanırken, "Son nokta Bulunamadı" hatası WebHttpBinding .

404 Not FoundOnun parametre imzayla birlikte web hizmeti yöntem adı düşünülürse mantıklı olabilir. Yani, bir web hizmeti yöntemini açığa çıkarır LoginUser(string, string)ve talep ederseniz LoginUser(string), ikincisi bulunmaz.

Temel olarak bu, aradığınız web hizmeti yönteminin, belirttiğiniz parametre imzasıyla birlikte bulunamadığı anlamına gelir.

10.4.5 404 Bulunamadı

Sunucu, İstek URI'sı ile eşleşen bir şey bulamadı. Koşulun geçici mi yoksa kalıcı mı olduğuna dair herhangi bir gösterge yoktur.

400 Bad RequestGibi Gert önerdi , geçerli bir yanıt kodu kalır, ama normalde alt düzey sorunları belirtmek için kullanılır düşünüyorum. Kolayca hatalı biçimlendirilmiş bir HTTP isteği, eksik veya geçersiz HTTP üstbilgileri veya benzeri olarak yorumlanabilir.

10.4.1 400 Hatalı İstek

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

400 Hatalı İstek kodu gönderebilirsiniz. Daha genel amaçlı 4xx durum kodlarından biridir, bu yüzden ne istediğinizi ifade etmek için kullanabilirsiniz: istemci, doğru bir şekilde işlemek için uygulamanızın gerektirdiği bilgi / parametreleri eksik bir istek gönderiyor.

API projemizden birinde, eksik parametre nedeniyle% 100'de tam olarak dolduramadığımızda bazı isteklere 409 Durumu ayarlamaya karar veriyoruz.

HTTP Durum Kodu "409 Çakışma" bizim için iyi bir denemeydi çünkü tanımı kullanıcının çakışmanın kaynağını tanıması için yeterli bilgi içermesini gerektiriyor.

Referans: w3.org/Protocols/

400 veya 404 gibi diğer yanıtların yanı sıra, yeni ve doğru bir istek oluşturmaya yardımcı olan istekte bazı notlara bakma ihtiyacını zorlamak için 409'u seçtik.

Her durumda bizim durumumuz özeldi, çünkü istek tamamen doğru değilse bazı veriler göndermemiz gerekiyor ve istemciye iletiye bakıp istekte neyin yanlış olduğunu anlaması için zorlamalıyız.

Genel olarak sadece eksik bir parametremiz varsa , 400 ve eksik parametre dizisi için gidiyoruz . Ancak, belirli bir vaka mesajı gibi daha fazla bilgi göndermemiz gerektiğinde ve müşterinin bununla ilgileneceğinden daha emin olmak istediğimizde, bir 409 göndeririz

I Gerekli parametrelerdeki bir şey API uç noktasının (çok kısa bir parola gibi) gerekenle eşleşmediği halde 422 (İşlenemez varlık) için gider, ancak eksik bir parametre için 406 (Kabul Edilemez) için giderim.

İlgilenenler için, Spring MVC (en az 3.x) bu durumda 400'ü döndürüyor, bu da benim için yanlış görünüyor.

Birkaç Google URL'sini (accounts.google.com) test ettim ve gerekli parametreleri kaldırdım ve bu durumda genellikle 404 döndürüyorlar.

Google'ı kopyalarım.

404 Not FoundBelirtilen kaynak bulunamadığı için a'nın kullanılması gerektiği söylenebilir.

Sıklıkla 403 Yasak hata kullanıyorum. Nedeni, isteğin anlaşılmış olmasıdır, ancak istendiği gibi yapmayacağım (çünkü işler yanlıştır). Yanıt varlığı neyin yanlış olduğunu açıklar, bu nedenle yanıt bir HTML sayfasıysa, hata iletileri sayfadadır. Bir JSON veya XML yanıtıysa, hata bilgisi oradadır.

Gönderen RFC2616 :

10.4.4 403 Yasak

Sunucu isteği anladı, ancak yerine getirmeyi reddediyor.
Yetkilendirme yardımcı olmaz ve istek tekrarlanmamalıdır.
İstek yöntemi HEAD değilse ve sunucu
, isteğin neden yerine getirilmediğini halka duyurmak istiyorsa, kuruluştaki ret nedenini açıklamalıdır. Sunucu bu bilgileri istemcinin kullanımına açmak istemiyorsa,
bunun yerine 404 (Bulunamadı) durum kodu kullanılabilir.

ASP.NET Core'u bir referans veya örnek olarak kullanmak için ASP.NET Core, bir denetleyiciyi eylemlerle oluşturmanıza izin verir, "Ayrıntılar" eylemi bu şekilde görünür.

    // GET: Cars/Details/5
    public async Task<IActionResult> Details(int? id)
    {
        if (id == null)
        {
            return NotFound();
        }

        var car = await _context.Cars.FirstOrDefaultAsync(m => m.CarId == id);
        if (car == null)
        {
            return NotFound();
        }

        return View(car);
    }

Parametre idayarlanmamışsa, 404 Bulunamadı değerini döndürür.

Bir 404 döndürün - bu, kaynağın bulunamadığı anlamına gelir.

Kimlik içeren bir sitenin URL'sini düzenlemeyi deneyin. Birkaçını denedim:

• gitub repo sorunu
• izdiham sayfası
• amazon ürün görünümü
• ebay listeleme
• bbc haber makalesi

Tüm dönüşler 404, imo çünkü bu geliştiriciler standardı doğru yorumluyorlar, burada ve diğerlerinin cevabı değil!

403 ile giderdim.

Gönderen RFC 2616 - Köprü Metni Aktarım Protokolü - HTTP / 1.1

403 yasak

Sunucu isteği anladı, ancak yerine getirmeyi reddediyor. Yetkilendirme yardımcı olmaz ve istek tekrarlanmamalıdır. İstek yöntemi HEAD değilse ve sunucu, isteğin neden yerine getirilmediğini halka duyurmak istiyorsa, kuruluştaki ret nedenini açıklamalıdır. Sunucu bu bilgileri istemcinin kullanımına açmak istemiyorsa, bunun yerine 404 (Bulunamadı) durum kodu kullanılabilir.

Yanıtınızdaki başarısızlığın nedenini açıklamalısınız. Bunu yapmamayı tercih ederseniz, sadece 404 kullanın.