Başarısız doğrulama veya geçersiz kopya için REST HTTP durum kodları

REST tabanlı bir API ile bir uygulama inşa ediyorum ve her istek için durum kodları belirtiyorum noktasına geldim.

Doğrulama işlemi başarısız olan veya bir isteğin veritabanımdaki kopyayı eklemeye çalıştığı durumlarda hangi durum kodunu göndermeliyim?

Http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html adresine baktım ancak hiçbiri doğru gözükmüyor.

Durum kodlarını gönderirken yaygın bir uygulama var mı?

Giriş doğrulama hatası için: 400 Hatalı İstek + isteğe bağlı açıklamanız. Bu, " RESTful Web Services " kitabında önerilmektedir . Çift başvuru için: 409 Çatışma

Haziran 2014 Güncellemesi

İlgili şartname eskiden RFC2616 400 (Yanlış Request) kullanımını verdi ziyade dar olarak

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

Bu yüzden anlambilimsel hatalar için uygunsuz olduğu iddia edilmiş olabilir . Ama artık değil; Haziran 2014'ten beri , önceki RFC2616'nın yerini alan ilgili standart RFC 7231 , 400 (Kötü İstek) kullanımını daha geniş

sunucu, istemci hatası olarak algılanan bir şey nedeniyle isteği işleyemiyor veya işlemeyecek

• Doğrulama başarısız: 403 Yasak ("Sunucu isteği anladı, ancak yerine getirmeyi reddediyor"). Popüler düşüncenin aksine, RFC2616 "403 sadece başarısız kimlik doğrulaması için tasarlanmıştır" değil, "403: Ne istediğini biliyorum, ama bunu yapmayacağım" demiyor. Bu koşul kimlik doğrulaması nedeniyle olabilir veya olmayabilir.
• Bir kopya eklemeye çalışılıyor: 409 Çakışma ("Kaynağın geçerli durumu ile bir çakışma nedeniyle istek tamamlanamadı.")

Yanıt başlıklarında ve / veya gövdesinde kesinlikle daha ayrıntılı bir açıklama yapmalısınız (örneğin, özel bir başlıkla - X-Status-Reason: Validation failed).

Durum kodu 422, "İşlenemez Varlık" öneririm .

11.2. 422 İşlenemeyen Varlı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.

200,300, 400, 500 çok geneldir. Genel istiyorsanız, 400 tamam.

422 artan sayıda API tarafından kullanılıyor ve hatta Rails tarafından kutunun dışında kullanılıyor.

API'nız için hangi durum kodunu seçerseniz seçin, birileri katılmayacaktır. Ama 422'yi tercih ediyorum çünkü '400 + metin durumu' çok genel. Ayrıca, JSON için hazır bir ayrıştırıcıdan yararlanmıyorsunuz; bunun aksine, JSON yanıtı olan bir 422 çok açıktır ve çok sayıda hata bilgisi iletilebilir.

JSON yanıtından bahsetmişken, bu durum için Rails hata yanıtında standartlaşma eğilimindeyim:

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

Bu biçim, 'hata raporlama zenginliği' açısından desteklenmesi gereken en karmaşık durumu düşündüğüm form doğrulaması için mükemmeldir. Hata yapınız bu ise, muhtemelen tüm hata raporlama ihtiyaçlarınızı karşılayacaktır.

200

Ugh ... (309, 400, 403, 409, 415, 422) ... başarılı bir HTTP isteği için başarısız bir REST çağrısı için en iyi dönüş kodunun ne olduğunu tahmin etmeye, tartışmaya ve standartlaştırmaya çalışan birçok cevap .

Öyle yanlış HTTP durum kodları ve DİNLENME durum kodlarını karıştırmak için.

Bununla birlikte, onları karıştıran birçok uygulama gördüm ve birçok geliştirici benimle aynı fikirde olmayabilir.

HTTP dönüş kodları HTTP Requestkendisiyle ilgilidir. Bir REST çağrısı, Köprü Metni Aktarım Protokolü isteği kullanılarak yapılır ve çağrılan REST yönteminin kendisinden daha düşük bir düzeyde çalışır. REST bir kavram / yaklaşımdır ve çıktısı bir iş / mantıksal sonucudur, HTTP sonuç kodu ise bir aktarımdır .

Örneğin, / users / komutunu çağırdığınızda "404 Bulunamadı" ifadesinin döndürülmesi karıştırılabilir, çünkü bu şu anlama gelebilir:

• URI yanlış (HTTP)
• Kullanıcı bulunamadı (REST)

"403 Yasak / Erişim Reddedildi":

• Özel izin gerekiyor. Tarayıcılar kullanıcı / parola sorarak bunu kaldırabilir. (HTTP)
• Sunucuda yanlış erişim izinleri yapılandırılmış. (HTTP)
• Kimlik doğrulamanız gerekiyor (REST)

Ve liste '500 Sunucu hatası' (Apache / Nginx HTTP atılan hatası veya REST'te iş kısıtlaması hatası) veya diğer HTTP hataları vb. İle devam edebilir.

Koddan, hata nedeninin, HTTP (taşıma) hatasının veya REST (mantıksal) hatasının ne olduğunu anlamak zordur.

HTTP isteği fiziksel olarak başarıyla gerçekleştirilmişse , bulunan kayıt (lar) ne olursa olsun, her zaman 200 kod döndürmelidir. Çünkü URI kaynağı bulundu ve HTTP sunucusu tarafından işlendi. Evet, boş bir set döndürebilir. HTTP sonucu 200 olan boş bir web sayfası almak mümkün müdür, değil mi?

Bunun yerine bazı seçeneklerle 200 HTTP kodu döndürebilirsiniz:

• bir şeyler ters giderse JSON sonucundaki "hata" nesnesi
• Kayıt bulunamadığı takdirde boş JSON dizisi / nesnesi
• Daha iyi bir kullanım için önceki seçeneklerle birlikte bir bool sonucu / başarı bayrağı.

Ayrıca, bazı internet sağlayıcıları isteklerinizi kesebilir ve size 404 HTTP kodu verebilir. Bu, verilerinizin bulunmadığı anlamına gelmez, ancak taşıma düzeyinde yanlış bir şeydir.

Gönderen Wiki :

Temmuz 2004'te, Birleşik Krallık telekom sağlayıcısı BT Grubu, Internet Watch Foundation tarafından potansiyel olarak yasadışı olduğu belirlenen içerik taleplerine 404 hatası veren Cleanfeed içerik engelleme sistemini kurdu. Diğer ISS'ler aynı durumlarda bir HTTP 403 "yasak" hatası döndürür. Tayland ve Tunus'ta sansürü gizlemenin bir yolu olarak sahte 404 hatalarının kullanıldığı bildirildi. 2011 devriminden önce sansürün ağır olduğu Tunus'ta, insanlar sahte 404 hatalarının doğasının farkına vardı ve "görünmez sansürü" temsil eden "Ammar 404" adlı hayali bir karakter yarattı.

Neden böyle bir şeyle cevap vermiyorsun?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

İstek mantıksal olarak başarısız olsa bile Google, her zaman 200'ü Geocoding API'sında durum kodu olarak döndürür: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

REST isteği başarısız olsa bile Facebook başarılı HTTP istekleri için her zaman 200 döndürür: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling

Çok basit, HTTP durum kodları HTTP istekleri içindir. REST API Sizin, durum kodlarınızı tanımlayın.

Veritabanındaki bir kopya bir olmalıdır 409 CONFLICT.

422 UNPROCESSABLE ENTITYDoğrulama hataları için kullanmanızı öneririm .

Burada 4xx kodlarının daha uzun bir açıklamasını yapıyorum .

Durum Kodu 304 Değiştirilmedi , yinelenen bir isteğe de kabul edilebilir bir yanıt verir. Bu, If-None-Matchbir varlık etiketi kullanma üstbilgisini işlemeye benzer .

Kanımca, @ Piskvor'un cevabı, algıladığım şeyin orijinal sorunun amacı olduğunu daha açık bir seçenektir, ancak aynı zamanda alakalı bir alternatifim var.

Yinelenen bir talebi hata yerine uyarı veya bildirim olarak ele almak istiyorsanız, 304Değiştirilmedi yanıt durumu kodu Content-Locationve mevcut kaynağı tanımlayan başlık da aynı şekilde geçerli olur. Amaç yalnızca bir kaynağın var olmasını sağlamaksa, yinelenen bir istek bir hata değil bir onay olur. İstek yanlış değil, yalnızca gereksizdir ve istemci varolan kaynağa başvurabilir.

Başka bir deyişle, istek iyidir, ancak kaynak zaten mevcut olduğundan, sunucunun başka işlem gerçekleştirmesi gerekmez.

Ember-Data'nın ActiveRecord bağdaştırıcısı 422 UNPROCESSABLE ENTITYsunucudan döndürülmeyi bekliyor . Yani, istemciniz Ember.js'de yazılmışsa 422'yi kullanmalısınız. Ancak o zaman DS.Errors döndürülen hatalarla doldurulur. Elbette 422'yi adaptörünüzdeki herhangi bir kodla değiştirebilirsiniz .