Kaynak zaten mevcut olduğunda POST için HTTP yanıt kodu

842

İstemcilerin nesneleri depolamasına izin veren bir sunucu oluşturuyorum. Bu nesneler, nesnenin tüm ömrü boyunca kalıcı olan nesne kimlikleriyle tamamlanan istemci tarafında tamamen oluşturulur.

Istemciler PUT kullanarak nesneleri oluşturmak veya değiştirmek için API tanımladı:

PUT /objects/{id} HTTP/1.1
...

{json representation of the object}

{İd} nesne kimliğidir, bu nedenle Request-URI'nin bir parçasıdır.

Şimdi, istemcilerin POST kullanarak nesne oluşturmasına izin vermeyi de düşünüyorum:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

POST "append" işlemi anlamına geldiğinden, nesnenin zaten orada olması durumunda ne yapacağımdan emin değilim. İsteği değişiklik isteği olarak mı ele almalıyım yoksa bazı hata kodu (da) döndürmeli miyim?

rest http http-status-codes

— VMJ
kaynak

5

Haziran 2016 itibarı ile FB, e-posta olduğunda kayda değer bir şekilde 200 tutar

— Green

4

Github API, zaten kullanımda olan bir adla kaynak (ekip / repo) oluşturmaya çalışırken 422 döndürür

— Ken

1

Nesnenin varlığını bir hata olarak kabul edip etmediğinize bağlıdır. Eki işlerseniz, 200 veya 204 en uygun yanıt kodlarıdır.

— Suncat2000

1055

Duygularım 409 Conflicten uygun olanıdır, ancak, elbette vahşi doğada nadiren görülür:

Kaynağın geçerli durumu ile bir çakışma nedeniyle istek tamamlanamadı. Bu koda yalnızca kullanıcının çakışmayı çözebileceği ve isteği yeniden gönderebileceği durumlarda izin verilir. Yanıt kuruluşu kullanıcının çatışmanın kaynağını tanıması için yeterli bilgi içermelidir. İdeal olarak, yanıt veren varlık, sorunu çözmek için kullanıcı veya kullanıcı aracısı için yeterli bilgi içerecektir; ancak bu mümkün olmayabilir ve gerekli değildir.

Çatışmaların bir PUT isteğine yanıt olarak ortaya çıkması muhtemeldir. Örneğin, sürüm oluşturma kullanılıyorsa ve PUT olan varlık, önceki (üçüncü taraf) bir istek tarafından yapılanlarla çakışan bir kaynakta değişiklikler içeriyorsa, sunucu, isteği tamamlayamayacağını belirtmek için 409 yanıtını kullanabilir . Bu durumda, yanıt veren varlık, iki tür arasındaki yanıtın Content-Type tarafından tanımlanan bir biçimde farklılıklarının bir listesini içerecektir.

— Wrikken
kaynak

11

neden 400 Kötü İstek için gitmiyorsun? Benim için bu bir doğrulama hatasına benziyor (yasadışı kimlikle yanlış yük sağlıyorsunuz).

— manuel aldana

314

400 => "İstek, hatalı biçimlendirilmiş sözdizimi nedeniyle sunucu tarafından anlaşılamadı" . Ve sunucu mükemmel bir şekilde anlıyor, ancak bir çakışma nedeniyle uyum sağlayamıyor. İstek ve sözdiziminde yanlış bir şey yok, sadece bir veri sorunu var. 400, anında kullandığım mekanizmanın sadece veriler yerine kusurlu olduğuna inandırıyor.

— Eylül'de Wrikken

42

@Wrikken Bu artık doğru değil. HTTP 400 yılında değiştirildi RFC 7231 anlamında "Sunucu ya olamaz olmayacak nedeniyle bir istemci hatası (örneğin, hatalı istek sözdizimi geçersiz istek mesajı çerçeveleme veya aldatıcı isteği yönlendirme) olarak algılanan şeye isteği işlemek." Bu durumda 400'ün doğru kullanım olduğunu söylemiyorum ama yeni 400 tanımı ile doğru olabilir .

— javajavajavajavajava

19

@javajavajavajavajava: yine de, yinelenen veriler aklımda bir 'müşteri hatası' değil, ama elbette bakanın gözünde.

— Wrikken

21

Varolan / çakışan kaynağa işaret eden HTTP 409bir Locationbaşlık ile geri dönüyorum.

— Gili

100

RFC 7231'e göre , 303 Bkz. Diğer MAYIS kullanılabilir Bir POST işlemenin sonucu mevcut bir kaynağın temsiline eşdeğerse .

— nullius
kaynak

4

Bence bu kabul edilmiş cevap olabilir. "MAYIS" tamamen isteğe bağlı bir öğeyi gösterse de, resmi RFC 7231 belgeleri tarafından önerilen tek yanıt kodudur .

— Nando

16

Bu en RESTful cevap.

— Seth

6

Bağlamın önemli olduğunu düşünüyorum. Örneğin: 303 döndürmek, bulunan kaynağa yeniden yönlendirmenin gerekli olduğu anlamına gelir. Bir sunucudan sunucuya çağrı yapmak mantıklı olabilir, ancak bir kullanıcı kayıt işlemi yürütüyorsanız hiç mantıklı olmaz.

— Sinaesthetic

11

Üzgünüm, bunu küçümsüyorum. HTTP 300'ler yönlendirme ile ilgilidir ve muhtemelen farklı özelliklere sahip başka bir nesneye yönlendirme çok yanıltıcı olacaktır.

— Michael Scheper

6

Üzgün olmak zorunda değilsin. Ancak, gösterim varolan bir kaynağa eşitse, nasıl farklı özelliklere sahip olabilir? Ve olsa bile, bir yönlendirme nasıl yanıltıcı olur? OP diyor ki: Nesnenin zaten orada olması durumunda ne yapacağımdan emin değilim. Aslında 'aynı' nesne. Yönlendirme neden yanıltıcı olabilir? OP'nin zihninde açıkça olmayan başka bir nesneden bahsediyorsunuz .

— Nullius

86

Şahsen ben WebDAV uzantısı ile gidiyorum 422 Unprocessable Entity.

RFC 4918'e göre

422 Unprocessable EntityDurum kodu sunucu istek varlık (dolayısıyla bir içerik türünü anlar anlamına 415 Unsupported Media Typedurum kodu uygun değildir) ve istek varlığı, sözdizimi (böylece bir doğru 400 Bad Requestdurum kodu olmayan) ama içerdiği komutları işlemek üzere 'edemedi.

— Gareth
kaynak

19

Bu ilginç bir düşünce ve sonunda WebDAV RFC'yi okumamı istedi. Bununla birlikte, 422'nin anlamının, istek ve dahil edilen varlığın sözdizimsel olarak doğru olduğu ancak anlamsal olarak anlamlı olmadığıdır.

— vmj

4

Hatalı biçimlendirilmiş JSON sözdizimsel olarak doğru bir varlık değildir, bu yüzden 422bana tuhaf geliyor ...

— awendt

7

Ben bununla gitmezdim. Yanıtta başvurulan aynı URL'den: "Ö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." Bu, geçerli sözdizimi VE anlambilimiyle tamamen geçerli bir istek varlığı gönderdiğinizde olduğu gibi, işlenemez bir varlığın gerçek anlamıdır, ancak tek sorun, var olan bir varlıkla çakışmasıdır. Aslında, talep eden varlığın anlambilimi geçerli değilse, benzer, mevcut bir varlık olmamalıdır.

— Tamer Shlash

1

Tamer yorumuna ekleyerek, eğer ikinci istek önce gelirse, başarılı olur, ki bu anlamsal olarak doğruysa mümkün olmaz. Dolayısıyla doğru anlambilimde burada geçerli olmaz.

— Harish

4

@Tamer Neden böyle? "Lütfen xy nesnesini oluştur" komutu sözdizimsel olarak doğrudur. Anlamsal olarak, yalnızca xy nesnesi oluşturulabiliyorsa doğrudur. Xy nesnesi zaten varsa, artık oluşturulamaz, bu nedenle bu bir anlamsal hatadır.

— Hagen von Eitzen

48

Her şey bağlamla ilgilidir ve ayrıca isteklerde (sunucu veya istemci veya her ikisi) yinelenen işlemleri yapmaktan kim sorumludur?

Sunucu sadece takdirde yinelenen işaret 4xx de, göz:

400 Hatalı İstek - sunucu, açık istemci hatası olduğu için bir isteği işlemediğinde
409 Çakışma - sunucu bir isteği işlemeyecekse, bunun nedeni istemcinin hatası değildir
...

İçin örtük kopyaların işlenmesi, 2xx bakmak:

200 TAMAM
201 Oluşturuldu
...

sunucunun bir şey döndürmesi bekleniyorsa , 3XX'e bakın:

302 Bulundu
303 Diğer
...

sunucu var olan kaynağı gösterebildiğinde, yeniden yönlendirme anlamına gelir.

Yukarıdakiler yeterli değilse, yanıtın gövdesinde bir hata mesajı hazırlamak her zaman iyi bir uygulamadır.

— Sławomir Lenart
kaynak

2

İstek bir kaynağı çoğaltmıyor, bir kaynağa veri ekliyor. Bence senin en iyisi senin en iyisi.

— Suncat2000

28

Oyuna geç belki ama bir REST API yapmaya çalışırken bu anlambilim sorunu tökezledi.

Wrikken'in cevabını biraz genişletmek için, duruma göre 409 Conflictveya 403 Forbiddenduruma bağlı olarak kullanabileceğinizi düşünüyorum - kısaca, kullanıcı çakışmayı çözmek ve isteği tamamlamak için kesinlikle hiçbir şey yapamadığında 403 hatası kullanın (örn. DELETEkaynağı açıkça kaldırma isteğinde bulunabilirsiniz) veya bir şey yapılabilirse 409 kullanın.

10.4.4 403 Yasak

Sunucu isteği anladı, ancak yerine getirmeyi reddediyor. Yetkilendirme yardımcı olmaz ve istek tekrarlanmamalıdır. İstek yöntemi HEAD değilse ve sunucu, isteğin neden yerine getirilmediğini halka duyurmak istiyorsa, kuruluştaki ret nedenini açıklamalıdır. Sunucu bu bilgileri istemcinin kullanımına sunmak istemiyorsa, bunun yerine 404 (Bulunamadı) durum kodu kullanılabilir.

Günümüzde, birisi "403" diyor ve bir izin veya kimlik doğrulama sorunu akla geliyor, ancak spesifikasyon, temelde sunucunun istemciye bunu yapmayacağını söyleyen, tekrar sormadığını ve istemcinin neden istememesi gerektiğini söylüyor 't.

Gelince PUTvs. POST... POSTkullanıcı için hiçbir araca sahip olduğunda bir kaynağın yeni bir örneğini oluşturmak için kullanılması gerektiğini ya da kaynak için bir tanımlayıcı oluşturmamalıdır. PUTkaynağın kimliği bilindiğinde kullanılır.

9.6 PUT

...

POST ve PUT istekleri arasındaki temel fark, İstek-URI'sinin farklı anlamına yansır. Bir POST isteğindeki URI, ekteki varlığı işleyecek kaynağı tanımlar. Bu kaynak veri kabul eden bir süreç, başka bir protokole açılan bir geçit veya ek açıklamaları kabul eden ayrı bir varlık olabilir. Buna karşılık, bir PUT isteğindeki URI, istekle birlikte gelen varlığı tanımlar - kullanıcı aracısı, URI'nin amaçlandığını bilir ve sunucunun, isteği başka bir kaynağa uygulamaması GEREKİR. Sunucu, isteğin farklı bir URI'ye uygulanmasını istiyorsa,

301 (Kalıcı Olarak Taşındı) yanıtı göndermelidir ZORUNLU; kullanıcı aracısı daha sonra isteği yeniden yönlendirip yönlendirmemeye ilişkin kendi kararını verebilir.

— p0lar_bear
kaynak

7

Bence 403 Yasak , kullanıcının kimliği doğrulanmış olmasına rağmen , istenen eylemi gerçekleştirme yetkisine sahip olmadığını ima eder . Doğrulama hataları için kullanmazdım. Örnek : Giriş yapmadım, bir şey silmeye çalışıyorum. Sunucu bana 401 Yetkisiz gönderir (sadece kötü adlandırılmış, 401 Kimliği Doğrulanmamış olmalıdır ). Giriş yapıp tekrar deniyorum. Bu kez sunucu izinlerimi kontrol ediyor, izin verilmediğimi görüyor ve 403 Yasak değerini döndürüyor . Ayrıca bu soruya bakın .

— Stijn de Witt

Hm ... doğru. Buradaki düşünce, kullanıcıya yetkilerinin kaynağı OP'nin kullanım durumunda değişmez hale getirdiğini söylemek için atlamaktı - zaten var, çatışmayı çözmek için hiçbir şey yapma izniniz yok, kaynağı tekrar oluşturmaya çalışmayın.

— p0lar_bear

3

Spesifikasyona göre, 409 hatasının bir hedef tarafından POST(doğru kullanıldığında) döndürülemeyeceği , hedef kaynakla çakıştığında geri döndürülmesi gerektiğini belirttiği ima edilmektedir . Hedef kaynak henüz gönderilmediğinden, muhtemelen çakışamaz ve bu nedenle yanıt vermek 409 Conflictmantıklı değildir.

— Grant Gryczan

1

Ben bir 409 hata a tarafından döndürülemez POSTçıkarım olmaz, aslında, ben tersini çıkarım olur çünkü "Çatışmalar büyük olasılıkla bir PUT isteğine yanıt olarak ortaya çıkacak." diğer istek yöntemlerinin de bu kodu kullanabileceğini gösteriyor. Ayrıca, "Yanıt gövdesi , kullanıcının çakışmanın kaynağını tanıması için yeterli bilgi içermelidir . İdeal olarak, yanıt kuruluşu kullanıcı veya kullanıcı aracısının sorunu düzeltmesi için yeterli bilgi içermelidir ; ancak bu mümkün olmayabilir ve gerekli değil . " ( webdav.org/specs/rfc2616.html#status.409 )

— JWAspin

14

"302 Bulundu" kulağa mantıklı geliyor. Ve RFC 2616 , GET ve HEAD dışındaki diğer talepler için cevaplanabileceğini söylüyor (ve bu kesinlikle POST'u içeriyor)

Ancak ziyaretçinin RFC tarafından bu "Bulundu" kaynağını alması için bu URL'ye gitmeye devam ediyor. Doğrudan gerçek "Bulunan" URL'ye gitmesini sağlamak için, mantıklı olan ancak başka bir çağrıyı aşağıdaki URL'yi ALMASI için zorlayan "303 Diğerlerine Bakın" kullanılmalıdır. İyi tarafta, bu GET önbelleğe alınabilir.

"303 Diğerlerine Bak" ı kullanacağımı düşünüyorum . Ben vücutta bulunan "şey" ile cevap verebilir, bilmiyorum ama sunucuya bir gidiş dönüş kaydetmek için bunu yapmak istiyorum.

GÜNCELLEME: RFC yeniden okuduktan sonra, hala bir düşünüyorum inexistent kodu "Bulunan 4XX + 303" doğru olmalıdır. Ancak, "409 Çakışması" (@Wrikken'in işaret ettiği gibi) mevcut en iyi yanıt kodudur , belki de mevcut kaynağa işaret eden bir Konum başlığı içerir.

— alanjds
kaynak

88

3xx durumları yeniden yönlendirme içindir

— Aviram Netanel

1

"İstenen kaynak geçici olarak farklı bir URI altında bulunuyor." dan w3.org/Protocols/rfc2616/rfc2616-sec10.html

— statueofmike

1

IMHO, "307 Geçici Yönlendirme" gerçek geçici yönlendirmedir. "302" belirsiz, ancak "BULUNAN !!" burada gerçekten istenen mesaj. En iyi belirsiz uzlaşma, HTTP anlambiliminde "303 Diğerlerine Bak" tır. Ben "303 Diğer bakın" ile gider.

— alanjds

@DavidVartanian Hum ... Burada bir hata görmüyorum. İstemci doğru bir istek gönderir, ancak "Üzgünüm, ama burada oluşturmaya çalıştığınız şey zaten var" nasıl söylenir? Bazı 3xx için bir iş gibi görünüyor. İstemci hatası olmadığı için benim için bir 4xx değil.

— alanjds

1

@DavidVartanian Tartışma için teşekkürler. Cevabı 409'a güncelledi . Müşteri, imkansız olduğunu bilmese bile imkansız şeyler istemek yanlıştır.

— alanjds

11

Bunu yapman gerektiğini sanmıyorum.

POST, bildiğiniz gibi koleksiyonu değiştirmek ve yeni bir öğe OLUŞTURMAK için kullanılır. Yani, kimliği gönderirseniz (iyi bir fikir olmadığını düşünüyorum), koleksiyonu değiştirmelisiniz, yani öğeyi değiştirmelisiniz, ancak kafa karıştırıcı.

Kimliği olmayan bir öğe eklemek için kullanın. En iyi uygulama bu.

UNIQUE kısıtlamasını (kimliğini değil) yakalamak istiyorsanız, PUT isteklerinde yapabileceğiniz gibi 409 yanıt verebilirsiniz. Ama kimlik değil.

— Alfonso Tienda
kaynak

Birleştirme tablosu ilişkisi olan bir nesneye ne dersiniz? Veritabanı tabloları olarak hesap, ürün ve hesap_ürünümüz olduğunu varsayalım. Bir hesaba ürün eklemek istiyorum, bu nedenle product_id ile / account / {id} / ürüne yayın yapmak istiyorum. Yalnızca bir hesap-ürün ilişkisine izin verilirse, ne döndürmeliyim?

— partkyle

2

Veritabanı tablolarını unutun. Bir ürünün yalnızca bir hesapla ilgili olabileceğini varsayalım ... O zaman bu çok fazla ilişkidir. Bu nedenle, POST / product / {id} ile {'account': account_id}. Eğer maksimum kardinalite '1' (bire bir ilişki) olarak ayarlanmışsa .... Neden dinlenme nesneleri ayrılır? Kardinalite hatası sadece 400 hata olacaktır. Basit tutun. Umarım sorunuzu anladım.

— Alfonso Tienda

Ben de sadece bu soruyu sordum ve benim için kimlik veritabanındaki teknik kimlik değil, şirket kodu gibi bir şey. Bu uygulamada bir yönetici kullanıcı şirketler oluşturabilir ve onlara bir kod vermek zorundadır. DB tablosunun teknik bir kimliği olmasına rağmen, bu kullanıcı için şirket kimliğidir. Benim durumumda, eğer aynı şirket kodu zaten mevcutsa, 409'u iade edeceğim.

— AlexCode

@partkyle PK'ları genel kimlik olarak kullanmayı bırakın !!

— Sinaesthetic

Bazı varlıkların sadece kimliğe değil, kendilerine özgü kısıtlamaları vardır. Bir hesap gibi, kullanıcı kullanıcı adı sağlamıyorsa hesap oluşturamazsınız. Ve kullanıcı adı olmayan bir hesap eklemek kesinlikle imkansız

— rocketspacer

9

Ben 422 Unprocessable Entitybir istek geçersiz, ancak sorun sözdizimi veya kimlik doğrulaması olduğunda kullanılan ile gider .

Diğer yanıtlara karşı bir argüman olarak, 4xxhata olmayan herhangi bir kod kullanmak, bir istemci hatası olmadığını ve açıktır. 4xxİstemci hatasını temsil etmek için hata olmayan bir kod kullanmak hiç mantıklı değildir.

Görünüşe göre 409 Conflictburadaki en yaygın cevap, ancak spesifikasyona göre, kaynağın zaten var olduğunu ve ona uyguladığınız yeni verilerin mevcut durumu ile uyumsuz olduğunu ima ediyor. Eğer birPOSTörneğin, önceden alınmış bir kullanıcı adıyla, hedef kaynak (oluşturmaya çalıştığınız kaynak) henüz gönderilmediğinden, aslında hedef kaynakla çakışmıyor. Depolanan kaynağın sürümü ile istenen kaynağın sürümü arasında bir çakışma olduğunda, özellikle sürüm kontrolü için bir hatadır. Bu amaç için çok kullanışlıdır, örneğin istemci kaynağın eski bir sürümünü önbelleğe aldığında ve artık koşullu olarak geçerli olmayacak olan yanlış sürüme dayanan bir istek gönderdiğinde. "Bu durumda, yanıt gösterimi, düzeltme geçmişine dayalı olarak farklılıkları birleştirmek için yararlı bilgiler içerebilir." Bu kullanıcı adıyla başka bir kullanıcı oluşturma isteği yalnızca işlenemez ve sürüm kontrolü ile ilgisi yoktur.

Kayıt için 422, GitHub'ın zaten kullanımda olan bir adla bir havuz oluşturmaya çalıştığınızda kullandığı durum kodudur.

— Grant Gryczan
kaynak

422 webdav spec bu yüzden bir REST API için kullanmanızı tavsiye

— etmem

7

Ben REST için düşünüyorum, sadece belirli bir sistem için davranış hakkında bir karar vermek zorunda, bu durumda, bence "doğru" cevap burada verilen birkaç cevaptan biri olacaktır. İsteğin durmasını ve istemcinin devam etmeden önce düzeltmesi gereken bir hata yaptığını düşünüyorsanız, 409'u kullanın. Çakışma gerçekten önemli değilse ve isteği devam ettirmek istiyorsanız, bulunan varlığa müşteri. Bence uygun REST API'leri bir POST sonra yine de bu kaynak için GET bitiş noktasına yönlendirmek (veya en azından konum üstbilgisi) olmalıdır, bu nedenle bu davranış tutarlı bir deneyim verecektir.

DÜZENLEME: Ayrıca kimliği sağladığınızdan bir PUT düşünmeniz gerektiğini de belirtmek gerekir. O zaman davranış basit: "Şu anda ne var umrumda değil, bu şeyi oraya koy." Yani, orada hiçbir şey yoksa yaratılacak; orada bir şey varsa değiştirilir. Sunucu bu kimliği yönettiğinde bir POST daha uygun olduğunu düşünüyorum. İki kavramı birbirinden ayırmak temel olarak onunla nasıl başa çıkacağınızı anlatır (yani PUT idempotenttir, bu yüzden her zaman yük yükü geçerli olduğu sürece çalışmalıdır, POST her zaman yaratır, bu yüzden bir kimlik çarpışması varsa, bir 409 bu çatışmayı tarif eder) .

— Sinaesthetic
kaynak

Spesifikasyona göre, 409 hatasının bir hedef tarafından POST(doğru kullanıldığında) döndürülemeyeceği , hedef kaynakla çakıştığında geri döndürülmesi gerektiğini belirttiği ima edilmektedir . Hedef kaynak henüz gönderilmediğinden, muhtemelen çakışamaz ve bu nedenle yanıt vermek 409 Conflictmantıklı değildir.

— Grant Gryczan

Debatable imo. Eğer / kullanıcılara

— gönderiyorsanız

Depolanan kaynağın sürümü ile istenen kaynağın sürümü arasında bir çakışma olduğunda, özellikle sürüm kontrolü için bir hatadır. Bu amaç için çok kullanışlıdır, örneğin istemci kaynağın eski bir sürümünü önbelleğe aldığında ve artık koşullu olarak geçerli olmayacak olan yanlış sürüme dayanan bir istek gönderdiğinde. "Bu durumda, yanıt gösterimi, düzeltme geçmişine dayalı olarak farklılıkları birleştirmek için yararlı bilgiler içerebilir."

— Grant Gryczan

PUTYine de kullanmak için öneri istiyorum .

— Grant Gryczan

4

Bir başka potansiyel tedavi de sonuçta PATCH kullanmaktır. PATCH, dahili durumu değiştiren ve ekleme ile sınırlı olmayan bir şey olarak tanımlanır.

PATCH, mevcut öğeleri güncellemenize izin vererek sorunu çözecektir. Bakınız: RFC 5789: PATCH

— Martin Kersten
kaynak

2

Yama PUT gibidir, ancak tam bir yedek değildir. Kaynağın bir parçasını değiştirmek yerine kaynağın tek bir öğesini eklemek, kaldırmak veya değiştirmek gibi bir parçayı değiştirmek için kullanılır.

— Sinaesthetic

4

Neden 202 Kabul Edilmedi ? Tamam bir istek (200s), kendi başına hiçbir müşteri hatası (400s) yoktu.

Dan 10 Durum Kodu Tanımlar :

"202 Kabul edildi. İstek işlenmek üzere kabul edildi, ancak işlem tamamlanmadı."

... çünkü tamamlanması gerekmiyordu, çünkü zaten vardı. Müşteri zaten var olduğunu bilmiyor, yanlış bir şey yapmadı.

Bir 202 atmaya ve benzer içeriği bir GET'in /{resource}/{id}döndürdüğü şeye geri döndürmeye eğilimliyim .

— Phillip Harrington
kaynak

21

Bu cevap yanlış. 202, sunucunun istekle ilgili bir sorun bulamadığı, ancak yanıt verdikten sonra isteği işlemeyi seçtiği anlamına gelir. Ayrıca işlemenin başarılı olmasını beklediği anlamına da gelir. Bizim durumumuzda sunucu işlemenin başarısız olacağını bilir, bu nedenle 202 yanlış yanıttır.

— Adrian

4

202 örneği bir kuyruk veya abonelik olabilir. Diğer bir deyişle, bu anda sorguyu sormanız halinde isteğin sonucu hemen kullanılamayabilir.

— Sinaestetik

1

Sunucu hala isteği işliyorsa, bu uygun olacaktır. 200 veya 204 daha yaygın olurdu. OP bir ekleme isteği yaptığı için, nesnenin varlığı beklenen bir durumdur, bir hata değildir.

— Suncat2000

Müşteriye isteğin kabul edildiğini söylemenin bir anlamı yok çünkü zaten olmadığını biliyorsunuz !

— lucastamoios

1

@Adrian ve lucastamoios, ikinizin de yanıt vermeden önce sunucunun veritabanından eşzamanlı olarak okuduğunu varsayalım. Bu her zaman böyle değildir, bu nedenle sunucu mevcut kayıt hakkında her zaman "bilmediği" için bu cevap "yanlış" değildir. Bu, api katmanının basitçe arka plan işçileri tarafından işleme yönelik talepleri kaydettiği asenkron sistemlerde çok geçerlidir.

— gsaslis

2

Yinelenen kayıt için doğru kodu kontrol ederken bu soru üzerine tökezledi.

Cehaletimi affedin ama neden herkesin "300" kodunu görmezden geldiğini anlamıyorum, bu açıkça "çoktan seçmeli" veya "Belirsiz"

Bence bu, kendi kullanımınız için standart olmayan veya belirli bir sistem oluşturmak için mükemmel bir kod olacaktır. Ben de yanılmış olabilirim!

https://tools.ietf.org/html/rfc7231#section-6.4.1

— Vurmak
kaynak

Anladığım kadarıyla: "durum kodu, hedef kaynağın birden fazla temsili olduğunu gösteriyor ... kullanıcı (veya kullanıcı aracısı) isteğini bunlardan bir veya daha fazlasına yönlendirerek tercih edilen bir temsili seçebilmesi için alternatifler hakkında bilgi sağlanıyor "Birden fazla temsili açıkça engellemeye çalışıyoruz. Seçenek yok. Müşterinin aralarından seçim yapabileceği alternatifler yoktur. İstemci farklı bir kimlikle yeniden göndermelidir. Bununla birlikte, istemcide sunucuda benzersiz kimliklerin oluşturulup oluşturulmayacağı da düşünülmelidir.

— musicin3d

Anlamsal olarak, istemci "Bunu oluştur" diyor ve sunucu "Yerine git" diyerek yanıt veriyor. Konuşma hiç mantıklı değil. Neredeyse sunucu istemciye "bunun yerine bu konuma posta göndermesini" söylüyor. 300'ler bir GET isteğine veya bir

— POST'a

2

Büyük olasılıkla 400 Bad Request

6.5.1. 400 Hatalı İstek

400 (Hatalı İstek) durum kodu, sunucunun, istemci hatası olarak algılanan bir şey (örneğin, hatalı biçimlendirilmiş istek sözdizimi, geçersiz istek iletisi çerçeveleme veya aldatıcı istek yönlendirmesi) nedeniyle isteği işleyemeyeceğini veya işlemeyeceğini gösterir.

İstek yinelenen değer (zaten var olan değer) içerdiğinden, istemci hatası olarak algılanabilir. Bir sonraki denemeden önce isteği değiştirmeniz gerekiyor.
Bu gerçekleri göz önüne alarak HTTP STATUS 400 Hatalı İstek olarak sonuçlandırabiliriz.

— Muhammed Güven
kaynak

1

Hatalı İstek, paketin sözdiziminde doğal bir sorun olduğu anlamına gelir. Başka bir bağlamda (kaynak zaten mevcut değilse), paket başarılı olursa, 400 hatasını döndürmemelidir.

— Gryczan

1

208 hakkında ne - http://httpstatusdogs.com/208-already-reported ? Bu bir seçenek mi?

Kanımca, tek şey tekrarlanan bir kaynaksa, hiçbir hata ortaya çıkmamalıdır. Sonuçta, istemci veya sunucu tarafında hiçbir hata yoktur.

— Fernando Ferreira
kaynak

Zaten mevcut olan belirli bir öğeyi eklemek istediğiniz için bu seçenek yoktur. Yani bir şey eklemeye çalışıyorsunuz ama bu zaten orada. Tamam, yalnızca veri kümesi büyütüldüğünde uygulanır. Bir Şey Ekle -> Tamam Hiçbir şey eklemedim. Uymuyor sanırım.

— Martin Kersten

Dediğim gibi, bunun bir hata olduğu bir şey değil. Ama @martin noktasını görüyorum

— Fernando Ferreira

Kaynak başarıyla oluşturulmazsa, tanım gereği bir hata vardır.

— Grant Gryczan

POST ayrıca veri eklemek için de kullanılır. Bu tanım ile , olmayan bir hata .

— Suncat2000

@ Suncat2000 Durum böyle olsa bile, veriler başarıyla eklenmezse, hala bir hata vardır. Ve kaynak zaten mevcutsa, hiçbir veri eklenmeyecektir.

— Grant Gryczan

0

Sizin durumunuzda 409 Conflict

Ve HTTPsaşağıdaki listeden başka bir durum kodunu kontrol etmek istiyorsanız

1 ×× Bilgilendirici

100 Continue
101 Switching Protocols
102 Processing

2 ×× Başarı

200 OK
201 Created
202 Accepted
203 Non-authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used

3 ×× Yönlendirme

300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect

4 ×× İstemci Hatası

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
444 Connection Closed Without Response
451 Unavailable For Legal Reasons
499 Client Closed Request

5 ×× Sunucu Hatası

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required
599 Network Connect Timeout Error

— Abd Abughazaleh
kaynak