Hangi REST PUT / POST / DELETE çağrıları bir kongre ile geri dönmelidir?

1. "REST ideolojisine" göre PUT / POST / DELETE istekleri için yanıt organında ne olmalıdır?

2. İade kodları ne olacak? Mı HTTP_OKyeter?

3. Varsa, bu tür sözleşmelerin nedeni nedir?

POST / PUT farklılıklarını açıklayan iyi bir yazı buldum: POST vs PUT Ama yine de soruma cevap vermiyor.

Ters çevirmeyi affedin, ancak HTTP üzerinden REST yapıyorsanız, RFC7231, GET, PUT, POST ve DELETE'den hangi davranışın beklendiğini tam olarak açıklar.

Güncelleme (3 Temmuz 14):
HTTP spesifikasyonu kasıtlı olarak POST veya DELETE'dan döndürülenleri tanımlamaz. Spesifikasyon sadece neyin tanımlanması gerektiğini tanımlar. Gerisi seçmek için uygulayıcıya bırakılır.

Genel olarak, sözleşmeler “sadece web sayfaları yayınlıyormuşsunuz gibi düşünün”.

Bir PUT için, hemen sonra bir GET yaptıysanız alacağınız aynı görünümü döndürürdüm; bu 200 ile sonuçlanır (iyi, renderın başarılı olduğu varsayılarak). Bir POST için, oluşturulan kaynağa bir yönlendirme yapardım (bir oluşturma işlemi yaptığınızı varsayarsak; değilse, sonuçları döndürün); başarılı bir oluşturmanın kodu 201'dir, bu da 300 aralığında olmayan bir yönlendirme için gerçekten tek HTTP kodudur.

DELETE'nin döndürmesi gereken şeyden hiç memnun kalmadım (kodum şu anda bir HTTP 204 ve bu durumda boş bir gövde üretiyor).

Bir kaynak oluşturmak genellikle POST ile eşlenir ve bu yeni kaynağın konumunu döndürmelidir; örneğin, bir Rails iskelesinde bir CREATE yeni oluşturulan kaynak için SHOW'a yönlendirir. Aynı yaklaşım güncelleme (PUT) için de anlamlı olabilir, ancak bu daha az konvansiyon; bir güncelleme yalnızca başarıyı gösterir. Silme işlemi muhtemelen sadece başarıyı göstermelidir; yönlendirmek istiyorsanız, kaynakların LIST'ini döndürmek muhtemelen en mantıklıdır.

Başarı HTTP_OK ile belirtilebilir, evet.

Yukarıda söylediğim tek ve hızlı kural, bir CREATE'in yeni kaynağın konumunu döndürmesi gerektiğidir. Bu benim için bir beyinsiz gibi görünüyor; müşterinin yeni öğeye erişebilmesi için mükemmel bir anlam ifade eder.

RFC7231 ile önemli değil ve boş olabilir

Projede json api standart tabanlı çözümü nasıl uygularız:

post / put: nesne niteliklerini get'de olduğu gibi çıktılar (alan filtresi / ilişkiler aynıdır)

delete: veriler yalnızca null içerir (eksik nesnenin temsili için)

standart silme durumu: 200

Güncelleme ve silme için HTTP durum kodundan Alfonso Tienda yanıtını seviyorum ?

İş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 tamamlanmadı.

• 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) ve geçersiz alan değerleri arasında ayrım yapılmasına yardımcı olur

• Ve 501 , 502 hata durumunda.