Geçersiz veriler için REST yanıt kodu

272

Aşağıdaki senaryolarda istemciye hangi yanıt kodu geçirilmelidir?

Yanlış e-posta biçimi gibi kullanıcı kaydı yapılırken geçersiz veriler geçti
Kullanıcı adı / E-posta adresi zaten var

Ben 403 seçtim. Ben de kullanılabilir olduğunu hissediyorum aşağıdaki bulundu.

Wikipedia:

412 Önkoşul Başarısız: Sunucu, istekte bulunanın istekte bulunduğu önkoşullardan birini karşılamıyor

403 dışında bir kod kullanmam gerekirse kod öner.

http rest jax-rs

— Amit Patel
kaynak

Olası kopya: stackoverflow.com/questions/3050518/…

— Genjo

Bu sorunu da çözüyorum. Bölüm 7: JAX-RS spesifikasyonunun (2017) doğrulanması, özellikle kısıtlama ihlalleri için durum kodu tavsiyesi sağlar. download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-spec/…

— burntsugar

298

Her iki durumda da 400 en iyi seçimdir. Hatayı daha ayrıntılı olarak açıklamak isterseniz, Neden İfadesini değiştirebilir veya hatayı açıklamak için bir gövde ekleyebilirsiniz.

412 - Son değiştirilme tarihi ve ETag'ler kullanılırken koşullu istekler için önkoşul başarısız oldu.

403 - Yasak, sunucu bir kaynağa erişimi engellemek istediğinde kullanılır.

Mümkün olan tek seçenek 422 - İşlenemez varlıktır.

— Darrel Miller
kaynak

10

bu bağlamda sıklıkla kullanılırken, 403 erişim kontrolü ile sınırlı değildir, çünkü rfc2616-10.4.4 diyor ki: "Sunucu isteği anladı, ancak yerine getirmeyi reddediyor. [...] sunucu yapmak istiyorsa talebin neden yerine getirilmediğini kamuoyu önünde, bu durum kuruluşta ret nedenini açıklamalıdır. " Nedeni geçersiz veriler olabilir. Ancak, 422 burada daha uygulanabilir.

— Yannick Loiseau

7

Metinsel eleştiriye kapılmayalım. Örneğin bkz. Trac.tools.ietf.org/wg/httpbis/trac/ticket/294 , 403'ün her zaman yetkilendirme olduğunu ve her zaman yetkilendirme ile ilgili olduğunu açıklamaya çalışan .

— fumanchu

2

@fumanchu İyi yakaladım. Yalnızca 7 saatlik bir değişiklik isteğinin bağlantısı :-)

— Darrel Miller

1

@fumanchu Kullanıcının istenen kaynağa erişme izni yoksa 403'ün geri döndürülmesi gerektiği anlamına gelir. Ancak 401 Yetkisiz'in, kullanıcının izni olmayan kaynaklara erişmeye daha uygun olduğunu düşünüyorum.

— Amit Patel

1

401 Yetkisiz, bir web tarayıcısından kullanıcıya standart HTTP kullanıcı adı / şifre istemini göstermesini ister. Hizmetiniz için bu tür bir kimlik doğrulaması kullanmıyorsanız veya kullanıcı zaten HTTP kimlik doğrulamasına sahipse, 401 uygun değildir.

— Greg Ball

92

Ben 422 tavsiye ederim. Bu ana HTTP spec bir parçası değil, ama genel bir standart (WebDAV) tarafından tanımlanır ve diğer 4xx durum kodu gibi tarayıcılar tarafından tedavi edilmelidir.

Gönderen RFC 4918 :

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.

— Mike Deck
kaynak

20

Alıntılanan metnin, talep varlığı sözdizimsel olarak iyi biçimlendirilmiş, ancak anlamsal olarak hatalı olduğunda 422'nin uygulanabilir olduğunu belirtir. Talepte bulunan kişi karışırsa, uygun yanıt 400'dür.

— Matty K

87

İstek doğru şekilde ayrıştırılamadıysa (istek varlığı / kuruluşu dahil) uygun yanıt 400 Hatalı İstektir [ 1 ].

RFC 4918 , 422 İşlenemez Varlık olduğunu belirtir , talep varlığı sözdizimsel olarak iyi biçimlendirilmiş, ancak anlamsal olarak hatalı olduğunda geçerli . Dolayısıyla, istek varlığı bozulursa (kötü bir e-posta biçimi gibi) 400 kullanın; ama eğer mantıklı değilse @example.com422 kullanın.

Sorun şu ki, soruda belirtildiği gibi, kullanıcı adı / e-posta zaten mevcutsa, çatışmanın bir açıklaması ve nasıl düzeltileceği hakkında bir ipucu olan 409 Çakışma [ 2 ] kullanabilirsiniz (bu durumda " farklı kullanıcı adı / e-postası "). Ancak, yazılan spesifikasyonda , bu durumda HTTP Yetkilendirmesi ile ilgili argümanlara rağmen 403 Yasak [ 3 ] da kullanılabilir.

412 Önkoşul Başarısız [ 4 ], istemci tarafından sağlanan bir önkoşul isteği üstbilgisi (örn. If-Match) Yanlış olarak değerlendirildiğinde kullanılır. Yani, müşteri bir şey istedi ve bu ön koşulların başarısız olabileceğini tam olarak bilerek ön koşullar sağladı. 412 müşteriye asla maviden çıkarılmamalı ve talep sahibi tüzel kişi ile ilişkili olmamalıdır .

— Matty K
kaynak

1

Güncellenmiş HTTP / 1.1 RFC'lere dikkat etmeliyim: 400 Hatalı İstek, 409 Çakışma, 403 Yasak vb. Tools.ietf.org/html/rfc7231'de canlı ; 412 Ön Koşul Başarısız Oldu tools.ietf.org/html/rfc7232#section-4.2

— Matty K

41

418 I'm a teapotAçıkça hazırlanmış veya kötü amaçlı olan ve CSRF denetiminin başarısız olması veya istek isteklerinin eksik olması gibi "gerçekleşemez" isteklerine geri dönmek eğlencelidir .

2.3.2 418 Ben bir çaydanlığım

Bir çaydanlıkla kahve demlemek için yapılan herhangi bir girişim "418 Ben bir çaydanlığım" hata koduyla sonuçlanmalıdır. Ortaya çıkan varlık gövdesi kısa ve sağlam olabilir.

Makul düzeyde ciddi tutmak için, komik hata kodlarının kullanımını doğrudan kullanıcıya maruz olmayan RESTful uç noktalarıyla kısıtlıyorum.

— doug65536
kaynak

11

418 I'm a teapotPatronunuzdan gelen tüm istekler için

— API'nizin

2

@vikarjramun, sahte bir REST oluşturdu ve çevrimdışı bir üretim yaptı. (yayın öncesi) şimdi öğrencilerimiz geçerli veri istekleri oluşturmaya çalışıyorlar, ancak hepsi çaydanlık. Ben "patron "um - ama o da çalışıyor.

— LenglBoy

2

Bu RFC aptal. Bir çay süzgecinden fincanınıza döktüğünüz sürece çaydanlıkta kahve yapabilirsiniz. Tıpkı gevşek yapraklı çay kullanmak gibi. Herhangi bir sorunu olmayan bir kafede çay da yapabilirsiniz.

— gburton

2

@gburton Bu bir insanın müdahalesini gerektiriyor. Ağ üzerinden, kahve yapmak için kesinlikle kahve özellikli bir cihaza ihtiyacınız var. Tabii ki, bir kahve ve çaydanlık bir 418 ile cevap vermemelidir.

— Jasper