REST API'sında “Henüz Hazır Değil, Daha Sonra Tekrar Deneyin” için bir HTTP durum kodunu nasıl seçerim? [kapalı]

152

http://server/thingyapi/thingyblob/1234İndirmek için thingy # 1234 ile ilişkili dosyayı (aka "blob") döndüren bir RESTful API geliştiriyorum . Ancak, istek sunucuda bulunmayan bir zamanda yapılmış olabilir, ancak kesinlikle daha sonraki bir zamanda kullanılabilir olacaktır . Sunucuda tüm nesneler için tüm lekeleri üreten bir toplu işlem var. Thingy 1234 zaten var ve blob dışındaki verileri zaten mevcut. Sunucunun henüz 1234'ün blobunu üretmesi gerekmiyor.

404 geri dönmek istemiyorum; bu var olmayan şeyler için. Bu var olan bir şeydir, ancak blob henüz oluşturulmamıştır. Biraz "işleyen" bir YouTube videosu gibi. Yeniden yönlendirme kodlarının da uygun olacağını sanmıyorum; denenecek "başka" bir URL yok.

Böyle bir durumda döndürülecek doğru HTTP durum kodu nedir?

— JCCyC
kaynak

3

Biraz ilgili

— Rob Hruska

7

İlk olarak, thingy 1234'ün henüz GET-mümkün bir temsili yoksa, hangi anlamda bir kaynak olarak (müşterinin bakış açısından) var olur? Sunucunun içinde 1234 oluşturmak için sıraya alınmış bir iş olması gerçeği, 1234 kaynağının var olduğu anlamına gelmez. İkincisi, istemci URI ... / thingyblob / 1234'ü nereden aldı? Sunucunun, kaynak gerçekten ALINABİLENEBİLDİĞİNDE, sunucunun URI'yi istemciye sağlamamış olması gerekirdi.

— Andy Dennie

1

Bir şey, damla dışında almaya değer diğer özelliklere sahiptir. Sadece üretmek için zaman alan damla. Müşteri bunları sunucu / thingyapi / thingy / 1234 ile alır

— Mart'ta JCCyC

10

HTTP standardı, hangi durumlar için hangi durum kodlarının kullanılacağı hakkında rehberlik sağlar. Bu nedenle bu soru aslında öncelikle görüşe dayalı değildir .

— Raedwald

2

204"İçerik Yok" nasıl olur ? Is, sunucunun isteği başarıyla işlediğini ve [şu anda] herhangi bir içerik döndürmediğini gösterir.

— Timo

77

Ben öneririm 202 - Accepted. Gönderen belgeler :

İstek işlenmek üzere kabul edildi, ancak işlem tamamlanmadı. [...] Amacı, bir sunucunun başka bir işlem için bir istek kabul etmesine izin vermektir (belki de günde sadece bir kez çalıştırılan toplu işlem tabanlı bir işlem)

— matsev
kaynak

62

-1: Bu, sonunda "thingy # 1234" oluşturan işlemi başlatan, ancak daha sonra "thingy # 1234" için verilen GET isteği için geçerli olmayan istek için anlamlı olacaktır. Özellikle, 202, GET talebinin bir sonucu olarak, servisin "şeyli # 1234" verilerini daha sonraki bir zamanda göndereceğini ileri sürmektedir. Bu doğru değil.

— Sam Harwell

7

Ayrıca, "Bu yanıtla döndürülen varlık, isteğin geçerli durumunun bir göstergesini ve bir durum izleyicisine bir işaretçi ya da kullanıcının isteğin ne zaman yerine getirilmesini bekleyebileceğine ilişkin bir tahmin içermelidir." müşteriye blobun henüz hazır olmadığını bildirmenin iyi bir yolu ve ne zaman hazır olduğunu öğrenmenin bir yolu.

— Remy Lebeau

3

"İşlem için kabul edildi" ifadesinin, daha sonra gerçekleştirilecek isteği kaydettiğinizi gösterdiğini iddia ediyorum. Sadece yok sayılıyorsa, istemciye tekrar denemek isteyebileceklerini belirtmek için bir 4xx veya 5xx kodu döndürmelisiniz.

— Luke

3

102 (işleme) bazen webdav özelliğinde olmasına rağmen makul bir seçim gibi görünüyor.

— akostadinov

2

Bu cevaba daha fazla katılmıyorum. Sunucu hiçbir şey döndürmüyor ya da (bu istek nedeniyle herhangi bir işlem yapmıyor - yine de bir GET için olmamalıdır). Bu nedenle, kaynak bazı şekillerde müşteri tarafından kullanılamaz. Bu hata olarak kabul edilmelidir, böylece 2XX kodu uygun değildir. 4XX veya 5XX alanında bir şey. İstek vardır değil "işlenmek üzere kabul edilmiş" istek pratikte atılır ediliyor,

— Adam

52

"Sorun", olduğu gibi, sunucu tarafında: istemci iyi biçimlendirilmiş bir istekte bulundu, ancak sunucu tatmin edemiyor. Bu yüzden bir "Sunucu Hatası", 5xx durum kodu eğilimindedir.

Quoth RFC 7231 (geçerli HTTP standardı, vurgu eklendi):

5xx (Sunucu Hatası) durum kodu sınıfı, sunucunun, istenen yöntemi gerçekleştirdiğini veya gerçekleştiremediğinin farkında olduğunu gösterir . Bir HEAD isteğine yanıt verirken, sunucu, hata durumunun açıklamasını ve geçici veya kalıcı bir durum olup olmadığını içeren bir temsil göndermelidir .

Not

"hata yaptı veya isteği gerçekleştiremedi": "Sunucu Hatası" başlıklarına rağmen, yalnızca sunucu hataları için değil.
" geçici veya kalıcı": bu kodlar sizinki gibi geçici olarak kullanılamayan kaynaklar için uygundur.

Mevcut kodlardan 503, "Hizmet Kullanılamıyor" diyebilirim :

503 (Hizmet Kullanılamıyor) durum kodu, sunucunun geçici bir aşırı yüklenme veya zamanlanmış bakım nedeniyle şu anda isteği işleyemediğini ve bunun bir süre sonra hafifletileceğini gösterir. Sunucu, istemcinin isteği yeniden denemeden önce beklemesi için uygun bir süre önermek üzere bir Yeniden Dene Sonrası başlık alanı gönderebilir.

Not:

"biraz gecikmeden sonra muhtemelen hafifletilebilir": davanız için doğru.
"geçici aşırı yük": davanız için bilgiçlikle doğru değil. Ama, bu ileri sürülebilir, istemci istekte zaman sunucu çok daha hızlı, toplu işlem zaten o kadar, bitmiş olurdu idi ise istemci yapabilirsiniz hızlı sunucudan daha kaynakların istiyor: "aşırı" bir tür kullanılabilir.
Yeniden denemek hizmetiniz için uygundur, bu nedenle cevabınız bir Retry-Afterdeğer içermelidir . Değer olarak, toplu işlemin bir sonraki yürütülmesinin tahmini tamamlanma süresini veya toplu işlemin yürütme aralığını sağlayabilirsiniz.

Kendi 5xx durum kodunuzu tanımlamak (örneğin, 591) izin verilse de yanlış anlambilime sahip olacaktır:

bir istemci, ilk hane ile belirtildiği gibi herhangi bir durum kodunun sınıfını anlamalı ve tanınmayan bir durum kodunu o sınıfın x00 durum koduna eşdeğer olarak kabul etmelidir

İstemciler kendi durum kodunuzu doğru olmayan 500 "Dahili Sunucu Hatası" olarak değerlendirir.

— Raedwald
kaynak

2

202'den daha iyi göremiyorum: benramsey.com/blog/2008/04/…

— JCCyC

4

@JCCyC blogunuz, bir şey (POST veya PUT) oluşturma isteğine yanıt olarak 202 değerini döndürmek için iyi bir durum oluşturur. Soru, bir GET için ne döneceğini soruyor gibi görünüyor.

— Raedwald

@JCCyC, hazır olmama durumunun farklı bir tonu olarak görülebilir: bu kaynak için bir ajax hayal edin, bir başarı durumu olarak 202'yi veya hata durumu olarak 503'ü tercih ediyor musunuz? uygulamanızın yanıta verdiği tepki bağlamında dolaylı olarak tercih ettiğiniz anlamı görebilirsiniz

— rloth

Ayrıca bir şey "hazır değil" ile iyi gider "Retry-After" pratik yönünü seviyorum

— rloth

1

Not: "Yeniden deneyin" sonra da 307 - TEMPORARY REDIRECTkaynak ile "hazır" iken başka bir yerde beklemek istemci tarafı zorlamak istiyorsanız iyi

— gidebilirsiniz rloth

28

Bence 423 - Kilitli bu amaç için kullanılabilir:

423 (Kilitli) durum kodu, bir yöntemin kaynak veya hedef kaynağının kilitli olduğu anlamına gelir. Bu yanıt, 'kilit jetonu gönderildi' veya 'çelişkili kilit yok' gibi uygun bir ön koşul veya son koşul kodu içermelidir.

— Fernando Ortega
kaynak

1

Mükemmel cevap! Neden daha fazla oylama olmadığını merak ediyorum.

— lex82

10

Belki bir WebDAV HTTP kodu olduğu için?

— Stephan L

1

Akka-http adresinden ActionCode RetryWith = reg (c (449) ("Yeniden Dene", "İstek, uygun eylemi gerçekleştirdikten sonra yeniden denenmelidir.")),

— İşlemin beklenmesi

2

Birçok açıdan buna katılıyorum. Benzer bir durum var (benim durumumda henüz doldurulmamış olabilir bir dizinden arama). Anlamsal olarak, bunun doğru olduğunu düşünüyorum. Bununla birlikte, 423 için RFC, "Bu yanıt, 'kilit belirteci tarafından gönderilmiş' veya 'çelişkili kilit yok' gibi uygun bir ön koşul veya son koşul kodu içermelidir." Bunu nasıl uygulayacağınızdan emin değilim. Ve şahsen 409 Çatışma ile giderdim, ama bu yorum olmadan indirildi - neden emin değilim?

— Adam

22

404 geri dönmek istemiyorum; bu var olmayan şeyler için.

URL, bir şey isteğine karşılık gelmiyor.

http://server/thingyapi/thingyblob/1234

İstemci, var olmayan bir şey istiyor. Varsa, onlara verirdiniz.

404.

— funroll
kaynak

1

Birinin bunu söylediğine sevindim! 503Uygun bir yanıt olduğunu düşünen çok insan olduğuna inanamıyorum . Diğer garip önerilerden bahsetmiyorum bile.

— Jason Desrosiers

Her ne kadar burada bir 404'ün en uygun yanıt olduğunu kabul etsem de, OP'nin şeylerin ne zaman mevcut olduğunu nasıl belirleyeceği sorusuna cevap vermiyor :-). Bence Retry-After alanı en iyi aday gibi görünüyor ama sadece resmi olarak 503 ve 3xx kodları için kullanılabilir. @ Jason: Sanırım bu bazı garip önerileri açıklıyor.

— Ron Deijkers

Bence bu en iyi cevap. Bir vücudu 404 yanıtıyla geri göndermenize izin verilir. Organ, nesnenin daha sonraki bir tarihte mevcut olacağını gösterebilir. Veya Retry-After başlığını da kullanın. Standardın burada biraz uzatılması gerekiyor, çünkü bu durumu güzel bir şekilde kapsamıyor.

— WW.

4

İnsanlar, bir API bağlamında bunu mantıklı bir şekilde ayıramayacakları anlamına gelmeyen 404 anlam sayfasına çok alıştı.

— Çörek Adamı

1

Bu sooooo 404. Thingyblob henüz mevcut değil veya hiç .. http için hiç mevcut değilse onunla alakasız. Şu anda mevcut değil ve 404. Ne zaman kullanılabilir olacak başka bir sorundur, bu da sunucudan istemciye bir mesaj göndererek çözülebilir. Tekrar alın ve

— deneyin

21

Başka bir seçenek: 503 - Service Unavailable.

— Brian Kelly
kaynak

5

W3C'ye göre istemciye söylemek istediğiniz şey bu değil ("bir şekilde" tekrar gelmek "anlamına gelmesine rağmen):" Sunucu şu anda geçici bir aşırı yükleme veya sunucunun bakımı nedeniyle isteği işleyemiyor. Bu, bir gecikmeden sonra hafifletilecek geçici bir durumdur.Biliniyorsa, gecikmenin uzunluğu bir Yeniden Dene-Başlığı başlığında gösterilebilir.Tekrar-Sonrası verilmezse, müşteri yanıtı bir 500 yanıt. "

— skalee

4

Hizmet kullanılamıyor, hizmet var, ancak işlem tamamlanmadı. Yani 503 muhtemelen iyi bir fikir değil.

— Ishtiaque Khan

17

Kaynağınız hazır olmadığından, muhtemelen ne zaman (yaklaşık olarak) kullanılabilir olacağını ve istemcinin isteğini ne zaman yeniden deneyebileceğini bilirsiniz. Bu, Retry-After başlığını kullanmak isteyebileceğiniz anlamına gelir . Bu üstbilgi, 503 (Hizmet Kullanılamıyor) için geçerlidir; bu, tüm sitenin bakım için kapalı olduğu ve 3xx (Yeniden Yönlendirme) yanıtları anlamına gelir.

Bence 302 (Bulundu) ile Retry-After üstbilgisi en iyi seçenek olurdu, ancak yanıt üstbilgisinin Konum alanının istek URL'sine eşit olup olmadığından emin değilim. Her neyse, dairesel yönlendirme.

— skalee
kaynak

3

İzin verilse bile, istemci Retry-After üstbilgisi için destek uygulamadıysa, aynı sayfaya 3xx Yeniden Yönlendirme sonunda 503 ... (isteğe bağlı olarak tabii ki Retry-After üstbilgisiyle)

— Ron Deijkers

1

Tekrar Dene, RFC 6585 (Nisan 2012) tarafından eklenen HTTP 429 "Çok Fazla İstek" ile de geçerlidir. Kaynağın henüz hazır olmama nedeni, istemciye sunucuya çok fazla iş vermiş olması durumunda bu uygun olabilir.

— Silas S. Brown

8

409 Çatışma

Birden çok güncelleme durumunda düzenleme çakışması gibi isteğin çakışması nedeniyle isteğin işlenemediğini belirtir. [Kaynak Wikipedia.]

Bu uygun olabilir.

Verileri döndürerek isteği yerine getiremezseniz - bu bir başarı değildir. 202, sunucunun isteği kuyruğa aldığını ve isteği daha sonra yerine getireceğini önerdiğini düşünüyorum. Ancak sizin durumunuzda, istek şu anda veriler içindir ve başarısız olmuştur. Daha sonra tekrar denerseniz, bu farklı bir istektir.

Sanırım bir çatışmanız var .. Verileri istiyorsunuz .. ama düzenleniyor / güncelleniyor. Thingy1234 zaten mevcutsa ve daha önce başarıyla indirilmişse, ancak şimdi düzenleme aşamasındayken düzenleme yapılırken kullanılamamış olsaydı da bu olurdu.

— J Moore
kaynak

2

Bunun neden oylandığından emin değilim. Bana doğru cevap gibi görünüyor. RFC'den: "409 (Çakışma) durum kodu, hedef kaynağın geçerli durumu ile bir çakışma nedeniyle isteğin tamamlanamadığını gösterir. Bu kod, kullanıcının çakışmayı çözebileceği durumlarda ve talebinizi yeniden. "sunucu söz konusu kaynağın güncelleştirme sürecinde olduğundan sunucu döndüremez bir kaynak için istedi - yani nedeniyle kaynağın güncel durumuna. Müşteri bunu bekleyerek ve yeniden

— Adam

1

@Adam Ben "kullanıcı çatışmayı çözmek mümkün olabilir" ima yeniden gönderme hakkında bir şey sadece beklemek dışında farklı olacağını düşünüyorum.

— Holistic Developer

3

501 - Uygulanmadı

Tam olarak nasıl göründüğü gibi. Henüz uygulanmayan ancak gelecekteki kullanılabilirlik anlamına gelen bir özellik.

İşte 5xx hatalarının bir özeti .

— Dan
kaynak

4

Bu soru için, özelliğin kendisi varmış gibi görünüyor, ancak istenen öğe mevcut değil.

— Luke

@Luke 501'in cevabımdaki linkten açıklaması, '... isteği yerine getirme yeteneğinden yoksun. Bu genellikle gelecekteki kullanılabilirliği ifade eder '. Bu OP'nin tam olarak ne istediğini yerine getiriyor. Verilerin sunucularında veya DB'sinde olup olmadığına bakılmaksızın. Nihai sonuç, şimdilik API aracılığıyla erişilememesidir. Bu nedenle API isteği yerine getiremez, ancak gelecekte http kodu aracılığıyla kullanılabilir olacağını ima etmek ister.

— Dan