UPDATE( PUT) Ve DELETE(örneğin ürün başarıyla güncellendi) için hangi durum kodunu ayarlamalıyım ?
Güncelleme ve silme için HTTP durum kodu?
Yanıtlar:
Bir PUT isteği için: HTTP 200 veya HTTP 204 "kaynak başarıyla güncellendi" anlamına gelmelidir.
Bir İçin SİL isteği: HTTP 200 veya HTTP 204 belitmelidir.Ayni "kaynak başarıyla silindi". HTTP 202 de döndürülebilir, bu da talimatın sunucu tarafından kabul edildiğini ve "kaynağın silinmek üzere işaretlendiğini" ima eder.
Mevcut bir kaynak değiştirilirse, isteğin başarıyla tamamlandığını belirtmek için 200 (Tamam) veya 204 (İçerik Yok) yanıt kodu> GÖNDERİLMELİDİR.
Yanıt, durumu tanımlayan bir varlık içeriyorsa başarılı bir yanıt 200 (Tamam), eylem henüz yürürlüğe girmediyse 202 (Kabul edildi) veya işlem yürürlüğe girdiyse ancak yanıt içermiyorsa 204 (İçerik Yok) olmalıdır bir varlık.
Kaynak: W3.org: HTTP / 1.1 Yöntem Tanımları
HTTP 200 OK: Başarılı HTTP istekleri için standart yanıt. Gerçek yanıt kullanılan istek yöntemine bağlı olacaktır.
HTTP 204 İçerik Yok: Sunucu isteği başarıyla işledi, ancak içerik döndürmüyor
40
Çok faydalı bir yazı! Ancak HTTP durum kodu ne olmalıdır merak ediyorum istemci tarafından gönderilen istek geçerli (DELETE mySite / entity / 123 ) ve silinecek varlık yok.
—
Martin
@Martin: Bu durumda, hizmet bir HTTP dönmelidir 404. Açıkçası, bir DELETE veya varolmayan bir kaynak için bir GET isteği değil , bir "geçerli" isteği - yani. istemci bu isteği hiçbir zaman başarılı olamayacağı için yeniden denememelidir ... HTTP protokolü 2 sorun kategorisi tanımlar - 4xx durum koduna sahip olanlar, istemcinin yeniden denemeden önce isteği değiştirmesi gereken ve 5xx durumundaki olanlar Hizmetin sorunla karşılaştığını ve istemcinin aynı isteği değiştirmeden yeniden denemesi gerektiğini / yeniden deneyebileceğini belirten kod.
—
Daniel Vassallo
@JeffMartin Bu, kullanıcının bakış açısından olabilir, ancak sunucu söz konusu olduğunda, kaynak yoksa, sunucu 404'ü döndürmelidir.
—
Randolpho
@Rololpho, Idempotence, bir işlemi bir veya daha fazla kez çağırsanız da aynı sonucu elde etmekle ilgilidir. İstemci, kaynağın silinmesini sağlamanızı istiyor. 404'ü iade etmenin faydası nedir? Neden her iki şekilde de bilmek gerekiyor? Şimdi istemci mantığı bir yerine iki ayrı yanıt kodunu işlemelidir.
—
Gili
@Gili: belki wiki daha iyi açıklayacaktır: PUT ve DELETE yöntemleri idempotent olarak tanımlanır ... idempotence, istek tamamlandıktan sonra sistemin durumuna işaret eder, bu nedenle sunucu eylemi gerçekleştirirken (örn. Bir kaydı silme) ) veya sonraki yanıtlarda döndürdüğü yanıt kodu farklı olabilir, sistem durumu her seferinde aynı olacaktır.
—
Randolpho
Kısa cevap: PUT ve DELETE için, 200 (Tamam) veya 204 (İçerik Yok) göndermelisiniz.
Uzun cevap: İşte tam bir karar diyagramı (büyütmek için tıklayın).
Diyagram inanılmaz. Çıktı almak için daha yüksek çözünürlüklü bir sürüm var mı?
—
KiKi
Mevcut bir kaynağın POST bağlamında, başka bir SO tartışması ( stackoverflow.com/questions/3825990/… ) içeriği eklemek yerine 409 Çakışma veya 302 Bulunan göndermenizi önerir.
—
koppor
Bir silme işleminden sonra 204 ve 200 yanıtının ters çevrilmesi gerekip gerekmediğini merak ediyorum ve eğer oldukları gibi doğruysa, neden? Silindi? -> Yanıt bir varlık içeriyor mu? -> evet -> 204 İçerik Yok; hayır -> 200 TAMAM
—
mat
Görüntünün güncellenmiş sürümü burada: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png
—
zaius
PATCH eksik.
—
doremi
İşte bazı ipuçları:
SİL
200 (Yanıtta bazı ek veriler göndermek istiyorsanız) veya 204 (önerilir).
202 Silinen işlem henüz gerçekleştirilmedi.
Silinecek bir şey yoksa, 204 veya 404'ü kullanın (SİL işlemi idempotent, zaten silinmiş bir öğeyi silme işlemi başarılı , bu nedenle 204'ü döndürebilirsiniz , ancak idempotent'in aynı yanıtı ima etmediği doğrudur)
Diğer hatalar:
- 400 Hatalı İstek (Hatalı oluşturulmuş sözdizimi veya hatalı sorgu garip ancak mümkün).
- 401 Yetkisiz Kimlik Doğrulama hatası
- 403 Yasak : Yetkilendirme hatası veya geçersiz Uygulama Kimliği.
- 405 İzin Verilmez . Elbette.
- 409 Karmaşık sistemlerde Kaynak Çatışması mümkün olabilir.
- Ve 501 , 502 hata durumunda.
KOYMAK
Bir koleksiyonun öğesini güncelliyorsanız
- 200/204 yukarıdaki DELETE ile aynı nedenlerle.
- 202 henüz işlem yapılmadıysa.
Başvurulan öğe mevcut değil:
- PUT 201 olabilir (öğeyi davranışınız olduğu için oluşturduysanız)
404 PUT ile eleman oluşturmak istemiyorsanız.
400 Hatalı İstek ( Yanlış biçimlendirilmiş sözdizimi veya DELETE durumundakinden daha yaygın olan hatalı bir sorgu).
- 401 Yetkisiz
- 403 Yasak : Kimlik doğrulama hatası veya geçersiz Uygulama Kimliği.
- 405 İzin Verilmez . Elbette.
- 409 Kaynak Çakışması , DELETE'deki gibi karmaşık sistemlerde mümkün olabilir.
- 422 İşlenemeyen varlık "Bozuk istek" (örn. Hatalı biçimlendirilmiş XML / JSON) ile geçersiz alan değerleri arasında ayrım yapılmasına yardımcı olur
- Ve 501 , 502 hata durumunda.
Bu cevap neredeyse tamamen iki büyük alıntıdan oluşuyor, ancak atıf yok. Nereden alıntı yapıyorsun?
—
Quentin
Durum etkili bir şekilde değiştirilmezse 204, bir PUT isteği için geri dönmek için uygun bir durum mudur? Örneğin, bir kullanıcıyı devre dışı bırakmayı istersiniz, ancak kullanıcı zaten etkin değildir.
—
Г И І И О
PUT isteği idempotenttir, bu nedenle nesne sistemde değiştiği için 204'ü döndürebilirsiniz . PUT PATCH değil, bu nedenle hangi alanı değiştirmek istediğinizden emin değilsiniz. Tasarımınızın, nesnenin istekteki nesneyle tamamen aynı olup olmadığını bilmesi gerekiyorsa, 501 - 502'yi geri gönderebilirsiniz, ancak ... Gerçekten hoşlanmıyorum .. 204'ü tercih ederim veya daha fazla alan değiştirmeden bir kullanıcıyı devre dışı bırakma, PATCH kullanabilirsiniz.
—
Alfonso Tienda
HTTP 422 İşlenemez Varlık eklerdim. "Bozuk istek" (örn. Hatalı biçimlendirilmiş XML / JSON) ve geçersiz alan değerleri arasında ayrım yapılmasına yardımcı olur.
—
vdboor
RFC 2616 hangi durum kodlarının kullanılacağını açıklar .
Ve hayır, her zaman 200 değil .
200 ve 204'e ek olarak 205 (İçeriği Sıfırla) geçerli bir yanıt olabilir.
Sunucu isteği yerine getirdi ve kullanıcı aracısı, isteğin gönderilmesine neden olan belge görünümünü sıfırlamalıdır ... [örneğin] girişin verildiği formun silinmesi.
Soru DELETE'in " 200'e karşı 204'ü döndürmesi gerekip gerekmediğini" araştırdığından , bazı kişilerin bağlantıları olan bir varlığı iade etmeyi önermesi önemlidir, bu nedenle tercih 200'dür .
"204 (İçerik Yok) döndürmek yerine, API yararlı olmalı ve gidilecek yerler önermelidir. Bu örnekte sağlamak için bariz bir bağlantı" "somewhere.com/container/ '(eksi' kaynak ') " - istemcinin bir kaynağı sildiği kapsayıcı olabilir. Belki de istemci daha fazla kaynağı silmek istediği için bu yararlı bir bağlantıdır. "
http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/
İstemci 204 yanıtıyla karşılaşırsa, vazgeçebilir, API'nın giriş noktasına veya ziyaret ettiği önceki kaynağa geri dönebilir. Her iki seçenek de özellikle iyi değildir.
Şahsen 204'ün yanlış olduğunu söyleyemem (yazar da yapmaz; "sinir bozucu" diyor) çünkü müşteri tarafında iyi önbelleklemenin birçok faydası var. En iyisi her iki şekilde de tutarlı olmaktır.
İşte bilginiz için bilmeniz gereken bazı durum kodları.
1XX Bilgi Yanıtları
- 100 Devam
- 101 Anahtarlama Protokolleri
- 102 İşleme
- 103 Erken İpuçları
2XX Başarısı
- 200 TAMAM
- 201 Oluşturuldu
- 202 Kabul edildi
- 203 Yetkili Olmayan Bilgiler
- 204 İçerik Yok
- 205 İçeriği Sıfırla
- 206 Kısmi İçerik
- 207 Çok Durumlu
- 208 Önceden Bildirildi
- 226 IM Kullanılmış
3XX Yönlendirme
- 300 Birden Fazla Seçenek
- 301 Kalıcı Olarak Taşındı
- 302 Bulundu
- 303 Diğer
- 304 Değiştirilmedi
- 305 Proxy Kullan
- 306 Anahtar Proxy
- 307 Geçici Yeniden Yönlendirme
- 308 Kalıcı Yönlendirme
4XX İstemci hataları
- 400 Hatalı İstek
- 401 Yetkisiz
- 402 Ödeme Gerekli
- 403 Yasak
- 404 Bulunamadı
- 405 Yönteme İzin Verilmiyor
- 406 Kabul Edilemez
- 407 Proxy Kimlik Doğrulaması Gerekiyor
- 408 İstek Zaman Aşımı
- 409 Çatışma
- 410 Gitti
- 411 Uzunluk Gerekli
- 412 Önkoşul Başarısız
- 413 Yükü Çok Büyük
- 414 URI Çok Uzun
- 415 Desteklenmeyen Ortam Türü
- 416 Aralık Tatmin Edilemez
- 417 Beklenti Başarısız
- 418 Ben bir çaydanlık
- 420 Yöntem Hatası
- 421 Yanlış Yönlendirilmiş İstek
- 422 İşlenemeyen Varlık
- 423 Kilitli
- 424 Başarısız Bağımlılık
- 426 Yükseltme Gerekli
- 428 Önkoşul Gerekli
- 429 Çok Fazla İstek
- 431 İstek Üstbilgisi Alanları Çok Büyük
- 451 Yasal Nedenlerle Kullanılamıyor
5XX Sunucu hataları
- 500 Dahili Sunucu hatası
- 501 Uygulanmadı
- 502 Bozuk Ağ Geçidi
- 503 Hizmet Kullanılamıyor
- 504 ağ geçidi Zaman Aşımı
- 505 Http sürümü desteklenmiyor
- 506 Değişken Ayrıca müzakere
- 507 Yetersiz Depolama
- 508 Döngü Algılandı
- 510 Genişletilmiş Değil
- 511 Ağ Kimlik Doğrulaması Gerekiyor
Haziran 2014'te RFC7231, RFC2616'yı geçersiz kılar. HTTP üzerinden REST yapıyorsanız, RFC7231 , GET, PUT, POST ve DELETE'den tam olarak hangi davranışın beklendiğini açıklar
Bir kaynak değiştirildiğinde, yanıt kodu 200 (“Tamam”) olmalıdır . Kaynak durumu URI'yi kaynağa değiştirecek şekilde değişirse (örneğin, bir kullanıcı hesabı yeniden adlandırılır), yanıt kodu 301'dir (“Kalıcı Olarak Taşındı”) ve Konum başlığı yeni URI'yi sağlamalıdır.
Bir nesne silindiğinde, yanıt kodu 200 (“Tamam”) olmalıdır.
Daha fazla ayrıntı için aşağıdaki bağlantıyı izleyin - dinlenme durum kodu