Bir proje üzerinde çalışıyorum ve iş yerindeki insanlarla yaklaşık bir saatten fazla çalıştıktan sonra. Borsadaki insanların ne söyleyebileceğini öğrenmeye karar verdim.

Bir sistem için bir API yazıyoruz, bir Organizasyon ağacını veya Hedefler ağacını döndürmesi gereken bir sorgu var.

Organizasyon ağacı, kullanıcının bulunduğu organizasyondur, Başka bir deyişle, bu ağaç daima mevcut olmalıdır. Organizasyonda, bir hedef ağacı daima mevcut olmalıdır. (tartışma başladığı yer). Ağacın olmadığı durumlarda, iş arkadaşım 200 durum koduyla cevabını cevaplamanın doğru olacağına karar verdi. Daha sonra, ağaç yokken uygulama ayrıldığından kodumu düzeltmemi istedi.

Alev ve öfke biriktirmeye çalışacağım.

Ağaç olmadığında 404 hatası üretmeyi önerdim. En azından bir şeyin yanlış olduğunu bilmeme izin verecek. 200 kullanırken, hataları işlemek için geri aramadaki yanıtımı özel olarak kontrol etmem gerekiyor. Bir nesne almayı bekliyorum, ancak boş bir yanıt alabilirim çünkü hiçbir şey bulunamadı. Yanıtı 404 olarak işaretlemek tamamen adil gözüküyor. Sonra savaş başladı ve HTTP durum kodu şemasını anlamadığım mesajını aldım. Yani buradayım ve bu davada 404'ün neyin yanlış olduğunu soruyorum? Hatta "Bu argüman var buldum şey, bu yüzden doğru 200 dönmek var". Ağacın daima mevcut olması gerektiği için yanlış olduğuna inanıyorum. Hiçbir şey bulamazsak ve bir şey bekliyorsak, 404 olmalı.

Daha fazla bilgi,

Alınan URL’leri eklemeyi unuttum.

Organizasyonlar

/OrgTree/Get

Hedef

/GoalTree/GetByDate?versionDate=...
/GoalTree/GetById?versionId=...

Benim hatam, her iki parametre de gerekli. Bir tarihe ayrıştırılabilecek herhangi bir versionDate sağlanmışsa, kapanış revizyonunu döndürür. Geçmişte bir şey girerseniz, ilk revizyona geri dönecektir. Eğer kimliği olmayan bir kimliğe göre, 200 ile boş bir cevap vereceğinden şüpheleniyorum.

Ekstra

Ayrıca, sorunun en iyi cevabının, kuruluşlar oluşturulduğunda varsayılan nesneler oluşturmak olduğuna, hiçbir ağacın bulunmamasının geçerli bir durum olmamasına ve tanımlanmamış bir davranış olarak görülmesi gerektiğine inanıyorum. Bir hesap her iki ağaç olmadan da kullanılamaz. Bu sebeplerden dolayı daima mevcut olmalıdırlar.

ayrıca bunu da bağladım (benzer ama bulamıyorum)

http://viswaug.files.wordpress.com/2008/11/http-headers-status1.png

Şüphe durumunda, belgelere bakın . HTTP Durum kodları için W3C tanımlarını incelemek bize şunları verir:

200 Tamam - İstek başarılı oldu. Yanıtla döndürülen bilgi, istekte kullanılan yönteme bağlıdır.

404 Bulunamadı - Sunucu, İstek URI'siyle eşleşen hiçbir şey bulamadı.

API'nız bağlamında, bu sorguların nasıl yaratıldığına ve nesnelerin nasıl alındığına bağlıdır. Ancak, yorumum her zaman şöyle olmuştur:

• Belirli bir nesneyi sorarsam ve dönüş 200kodu varsa, yoksa doğru 404kodu döndürür .
• Ancak, bir sorguyla eşleşen bir nesne kümesi sorarsam, boş bir set geçerli bir cevaptır ve 200kodla döndürülmesini istiyorum . Bunun mantığı, sorgunun geçerli olduğu, başarılı olduğu ve sorgunun hiçbir şey döndürmediğidir.

Yani bu durumda haklısın , hizmet "belirli bir şey" için arama yapmıyor , belirli bir şeyi talep ediyor , eğer bulunamadığı açıkça söyleniyorsa.

Bence Vikipedi en iyisini koyar:

200 OK - ... Gerçek cevap, kullanılan istek yöntemine bağlı olacaktır. Bir GET isteğinde, yanıt istenen kaynağa karşılık gelen bir varlık içerecektir.

404 Bulunamadı - Talep edilen kaynak bulunamadı, ancak gelecekte tekrar mevcut olabilir. Müşteri tarafından müteakip taleplere izin verilir.

Bana oldukça açık görünüyor.

Örnek isteklerle ilgili

/GoalTree/GetByDate?versionDate=...
/GoalTree/GetById?versionId=...

Formata göre, her zaman en yakın revizyonu o tarihe döndürürsünüz. Asla bir nesneyi döndürmez, bu yüzden daima geri dönmesi gerekir 200 OK. Bu tarih aralığını alabilmiş olsa ve mantık o zaman dilimindeki tüm nesneleri 200 OK döndüren olsa bile - 0 Sonuçlar tamam, isteğin de bu - bu kriterleri karşılayan şeyler seti.

Bununla birlikte, ikincisi , muhtemelen kimliğiyle benzersiz olan belirli bir nesne istemenizden farklıdır . 200 OKİstenen kaynak bulunamadığından ve bulunamadığından bu durumda geri dönmek yanlıştır .

Durum kodlarının seçilmesi ile ilgili olarak

• 2xx kodları Bir UA'ya doğru olanı yaptığını söyleyin , istek işe yaradı. Gelecekte bunu yapmaya devam edebilir.
• 3xx kodları Bir UA'ya muhtemelen eskiden çalıştığını sorduğunuzu söyleyin, ancak bu şey şimdi başka bir yerde. Gelecekte, UA sadece yönlendirmeye gitmeyi düşünebilir .
• 4xx kodları Bir UA'ya yanlış bir şey yaptığını söyleyin , yapılan istek uygun değil ve en azından bir değişiklik yapmadan tekrar denememesi gerekir.
• 5xx kodları Bir UA’ya sunucunun bir şekilde bozulduğunu söyleyin . Ancak hey bu sorgu gelecekte çalışabilir, bu yüzden tekrar denememek için hiçbir sebep yoktur. (4001 sayıdan fazlası olan 501 hariç).

5xx kodunu kullanarak bir yorumda sizden bahsettiniz, ancak sisteminiz çalışıyor. Çalışmayan ve bunu UA'ya iletmesi gereken bir sorgu istendi. Ne kadar dilimleseniz, bu 4xx bölgesidir.

Güneş sistemimizi sorgulayan bir uzaylı düşünün

Alien: Bilgisayar, lütfen bana insanların yaşadığı tüm gezegenleri söyle.

Bilgisayar: 1 sonuç bulundu. Dünya

Alien: Bilgisayar, lütfen bana Dünya'dan bahset .

Bilgisayar: Dünya - Çoğunlukla Zararsız.

Alien: Bilgisayar, lütfen bana yaşayan asteroid kuşağı dışındaki tüm gezegenlerden bahset.

Computer: 0 sonuç bulundu.

Alien: Bilgisayar, lütfen Dünya'yı yok et.

Bilgisayar: 200 tamam.

Alien: Bilgisayar, lütfen bana Dünya'dan bahset .

Bilgisayar: 404 - Bulunamadı

Alien: Bilgisayar, lütfen bana insanların yaşadığı tüm gezegenleri söyle.

Computer: 0 sonuç bulundu.

Alien: Güçlü Irken İmparatorluğu için zafer!

/ GoalTree / Get * 'in kaynaklara değil fiil gibi göründüğü gerçeğini göz ardı ederek, URI / GoalTree / Get * erişim için her zaman kullanılabilen kaynakları temsil ettiğinden ve sonuç olarak bir ağaç yoksa müşteri hatası olmadığı için her zaman 200 döndürmelisin. bir istek. İade edilecek bir varlık olmadığı zaman, sadece 200'ü boş set ile geri getirin.

Eğer kaynak bulunamazsa, varlık olmadığı zaman değil, 404'ü kullanırsınız.

Başka bir şekilde koyun, eğer nesneleriniz için 404'ü iade etmek istiyorsanız, onlara kendi URI'lerini verin.

Bu ilginç bir soru, çünkü her şey sistemin özellikleri ile ilgili.

410 kod ailesi çoğunlukla kullanıcı / müşteri hataları için olduğundan, imel96'nın yanıtı beni 404'ün uygun bir cevap olmayacağına ikna etti . URL iyi biçimlendirilmiş ve ağaç orada olmalı; değilse, sistem tutarsız bir durumdadır!

Bu nedenle bu bir sunucu hatası, yani 5xx ailesindeki bir şey. Muhtemel bir 500 Dahili Sunucu Hatası veya Kullanılamayan bir 503 Servisi (hizmet "orada olması gereken ağacı getir" şeklinde).

Duruma nasıl baktığınıza bağlı olarak 200 veya 404 yanıt kodunun geçerli olabileceğini söyleyebilirim .

Mesele şu ki, HTTP cevap kodları , URL'lerine dayalı olarak çeşitli kaynaklar sunabilen bir sunucu bağlamında tanımlanmıştır . Bu bağlamda, anlamları ve tamamen açık bir şekilde anlaşılırlar: birincisi "işte istediğiniz kaynak" diyor, ikincisi "özür dilerim, böyle bir kaynağım yok" diyor.200 OK404 Not Found

Bununla birlikte, sizin durumunuzda, HTTP sunucusu ile istenen gerçek kaynaklar (ağaçlar) arasında ek bir uygulama katmanınız vardır. Uygulama, HTTP spesifikasyonunda iyi ele alınmamış bir çeşit ara boşluğu kaplar.

Web sunucusu bakış açısından, uygulama görünüyor tür bir kaynak gibi: sadece sunucu yayınlıyor olabilecek diğer kaynakların (örneğin statik dosyaları) gibi tipik tarafından tespit sunucusundaki bir dosyayı, (bir kısmı) bir URL var. Öte yandan, tuhaf bir kaynaktır, çünkü cevabın içeriğini ve hatta durum kodunu dinamik bir şekilde belirleyen yürütülebilir bir koddan ve mini sunucu gibi davranmasını sağlayan durum kodunu bile içerebilir.

Özellikle, örnek durumunuzda, web sunucusu uygulamayı gayet iyi bulabilir, ancak uygulama daha sonra istenen alt kaynağı (ağacı) bulamaz. Şimdi, uygulamanın sunucunun yalnızca bir uzantısı ve alt öğenin (ağaç) asıl kaynak olduğunu düşünüyorsanız, o zaman 404 yanıtı uygundur: sunucu yalnızca asıl kaynağı bulmaya görev vermiştir. , hangi dönüş bunu başaramadı.

Öte yandan, bakış açınız uygulamanın talep edilen kaynak olduğu durumdaysa, açıkça web sunucusu 200 yanıt vermelidir ; Sonuçta, uygulama doğru bulundu ve yürütüldü. Açıkçası, bu durumda, uygulama aslında beklenen formatta geçerli bir cevap gövdesi döndürmelidir, bu, sorguyla eşleşen hiçbir gerçek veri bulunmadığını belirterek (kodlayan formattaki daha yüksek seviyedeki protokolleri kullanarak) belirtmelidir.

Bu bakış açılarının her ikisi de mantıklı olabilir. Çoğu durumda , en azından sıradan bir web tarayıcısıyla HTTP üzerinden doğrudan erişilmesi amaçlanan uygulamalar için , eski görüşü tercih ederim : kullanıcı genellikle sunucu ile uygulama arasındaki fark gibi iç detaylar ile ilgilenmez, sadece İstedikleri verilerin orada olup olmadığına dikkat edin.

Bununla birlikte, özel bir üst düzey API protokolü kullanarak diğer bilgisayar programlarıyla iletişim kurmak için tasarlanmış bir uygulamanın özel durumunda, HTTP'yi yalnızca düşük düzeyli bir taşıma katmanı olarak kullanmak , ikinci bakış açısına göre yapılması gereken bir argüman vardır : HTTP düzeyinde , gerçekten ilgilendikleri tek şey, böyle bir uygulama ile etkileşime giren müşteriler , uygulama ile başarılı bir şekilde iletişim kurmayı başarabilmeleridir. Bu gibi durumlarda, her şey, daha yüksek seviyeli protokol kullanılarak daha doğal bir şekilde iletişim halindedir.

Her durumda, yukarıdakilerden hangisini tercih ettiğinize bakılmaksızın, aklınızda bulundurmanız gereken birkaç ayrıntı vardır. Birincisi, çoğu durumda, (esas olarak) boş bir kaynak ile var olmayan bir kaynak arasında anlamlı bir fark olabilir .

HTTP düzeyinde, boş bir kaynak sadece 200 yanıt kodu ve boş bir yanıt gövdesiyle gösterilirken, varolmayan bir kaynak bir 404 yanıtı ve kaynağın yokluğunu açıklayan bir kaynak gövdesi ile gösterilir. Daha yüksek seviyeli bir API protokolünde, tipik olarak uygun bir protokole özel hata kodu / mesajı içeren bir hata yanıtı ile varolmayan bir kaynak belirtilirken, boş bir yanıt sadece veri maddesi içermeyen normal bir yanıt yapısı olacaktır.

(Bir kaynağın kelimenin tam anlamıyla sıfır bayt olması gerekmediğine dikkat edin, yukarıda demek istediğim anlamda "boş" olması gerekir. Örneğin, eşleşen bir öğeye sahip olmayan bir arama sonucu geniş anlamda boş sayılır, örneğin bir SQL sorgusu sonucu satır yok veya gerçek veri içermeyen bir XML belgesi.)

Uygulama gerçekten istenen subresource inanıyoruz eğer Ayrıca, tabii ki, gereken orada olmak, ama bulamıyorum, o zaman üçüncü bir olası yanıt kodu var: 500 Internal Server Error. Bu tür bir cevap, kaynağın varlığının başvuru için varsayılan bir önkoşul olması durumunda anlamlıdır, öyle ki yokluğu zorunlu olarak bir iç arıza olduğunu gösterir.

Son olarak, Postel'in yasasını daima aklınızda tutmalısınız :

" Gönderdiklerinizde muhafazakar olun ve aldıklarınızda liberal olun. "

Sunucunun 200 veya 404 yanıtıyla belirli bir durumda yanıt vermesi gerekip gerekmediği , bu durum , müşteri uygulayıcı olarak yanıtı uygun şekilde ve sağlam birlikte çalışabilirliği en üst düzeye çıkaracak şekilde ele almanıza izin vermez . Elbette, farklı durumlarda "uygun" işlemlerin ne anlama geldiği tartışılabilir, ancak kesinlikle normalde çarpma veya başka şekilde "dağılma" içermemelidir.

204 İçerik Yok mu? İsteğinizin başarıyla işlendiğini, ancak hiçbir şey döndürmediğini gösterir. Hala bir "başarı" dır, ancak yalnızca durum kodunu temel alan sonuçlara sahip olup olmadığınızı görmenizi sağlar.

URL, hiç bulunmayan bir kaynağı temsil ediyorsa 404 Bulunamadı

URL, boş bir liste olan bir kaynağı temsil ediyorsa, boş bir liste ve 200 OK döndür.

Örnek:

{
  total: 0,
  items: []
}

URL, varolan bir kaynağı temsil ediyorsa, 410 Gone değerini döndürün.

Lego Stormtrooper'ın diyalogu hakkında:

Alien: Computer, please tell me all planets that humans inhabit. GET /planets?inhabitedBy=humans

Computer: 200 OK. { total: 1, items:[{name:'Earth'}] }

Alien: Computer, please tell me about Earth. GET /planets/earth

Computer: 200 OK. {name:'Earth', status: 'Mostly Harmless'}

Alien: Computer, please tell me about all planets humans inhabit, outside the asteroid belt. GET /planets?inhabitedBy=humans&distanceFromSun=lots

Computer: 200 OK. {total:0, items:[] }

Alien: Computer, please destroy Earth. DELETE /planets/earth

Computer: 204 No Content. (or 202 Accepted if it takes some time to destroy Earth)

Alien: Computer, please tell me about Earth. GET /planets/earth

Computer: 410 Gone

Alien: Computer, please tell me all planets that humans inhabit. GET /planets?inhabitedBy=humans

Computer: 200 OK 0 {total: 0, items:[] }

Alien: Victory for the mighty Irken Empire!

Bunun sesinden, bu dahili kullanım için bir API'dir . Bu, kitabın (şartname) olup olmadığına bakılmaksızın , en fazla yararı sağlayan şemayı kullanma avantajını sağlar . Bu, kendi durum kodlarınızı tamamen icat etmek anlamına gelmez, ancak yararlı olması halinde kuralları biraz 'bükmek' uygundur.

Standınızla, bir şeyler ters gittiğini gösteren bir durum kodu almanız gerektiği konusunda hemfikirim. Bu durum kodlarının ne için olduğuna bağlı. Ayrıca istisnalar / vb. Atan kütüphanelerden de faydalanabilirsiniz. 200 olmayan durum kodunda bu yüzden açıkça kontrol etmek zorunda değilsiniz (Ya da bunu yapan kendi paketleyicinizi yazabilirsiniz).

Andres F.'in, ağacın olması gerektiğinden 500'ün uygun olduğuna dair görüşüne katılıyorum . Uygulamada ise sunucu hatalarını iki kategoriye ayırmayı seviyorum. Bir şeyler beklenmedik ters gitti ve ben hemen kontrol edebilirsiniz şeyler ters gitti. Bu, aşağıdaki durum kodlarıyla sonuçlanır,

• 200 - Her şey yolunda
• 404 - Yanlış URL
• 409 - Bir şeyler ters gitti
• 500 - Sunucuda beklenmeyen bir hata oluştu

Özel bir durumda, ağacın sunucu tarafında olup olmadığını kontrol edebilirsiniz ve orada değilse 409 döndürür. Beklenen bir hatadır (bunun olduğunu biliyorsunuz, onu kontrol edebilirsiniz, vb.) . 409 ihtilaf benim kişisel tercihimdir, 5xx ayrıca oturup ekibinize karar verdiğiniz sürece uygun olabilir.

Kodları bu şekilde kategorize etmek, hatanın türünü daha hızlı tanımlamanıza yardımcı olur, ancak kuruluş dışında da faydaları olabilir. Genellikle web sitesi hatalarıyla istemcinin beklenmedik hatalar almasını istemezsiniz, çünkü bu bir güvenlik kaygısı olabilir ve güvenlik açıklarını açığa çıkarabilir, bu nedenle genel bir 500 "Bir hata oluştu" döndürürsünüz. ve tam hatayı sunucuda günlüğe kaydedin. Ancak 409 gibi beklenen bir hata meydana gelirse, hatayı müşteriye göstermenin güvenli olacağını ve ne olduğuna dair onları karanlıkta bırakmak zorunda kalmayacağınızı biliyorsunuzdur. Bu, açıklayabileceğim tek bir pratik kullanım, ancak birçok olasılık var.

Bu bir avuç-22, çünkü iş arkadaşlarınızla aynı fikirde olamadığınız için bunu gönderiyorsunuz, ama sizler anlambilim hakkında daha fazla tartışan ve politik olarak doğru olanlarınız gibi görünüyor. Gerçekten şirkete en fazla yarar sağlayan bir sistem bulabildiğiniz sürece kimin daha uygun olduğu hiç önemli değil.

Öte yandan, bu şartnameleri mümkün olduğunca yakından takip eden herkese açık bir API ise, toplum arasında karışıklığı önlemek kadar önemlidir.

Bu konuda teğet bir bıçak alarak: Eğer bir kişi sonunda API kullanıyorsa (bir GUI aracılığıyla), son kullanıcı için hayatı kolaylaştıracak her şeyi yapmayı öneririm. Ağacın olması gerektiğinde olmaması, "Etki alanı modeli tutarsızlığı" hatasıdır. Bir sistem hatası, hafızanız tükendiğinde veya başka bir sistemik arıza olduğunda ortaya çıkar. 5xx döndürmek uygun değil. Yukarıdaki birkaç kişi tarafından belirtildiği gibi, eğer ağacın kendisi URI'sı varsa 4xx uygun olabilir, buradaki durum böyle değil. Fakat işte 404 müşteriye ne diyor: bir şey geri dönene kadar tekrar tekrar deneyebilirsiniz. 200 döndürdüyseniz, kullanıcı aracısına geri dönmeyi ve kullanıcı desteğini durdurabilmesi için bir aracı görüntüleyebilir, böylece kullanıcı yeniden denemeyi durdurur ve yalnızca destekle iletişim kurar. Öte yandan, bu API yalnızca sistemlere yönelikse,