Resurs zaten mövcud olduğunda POST üçün HTTP cavab kodu

Müştərilərin obyektləri saxlamağa imkan verən bir server yaratmaq. Bu obyektlər tamamilə müştəri tərəfində qurulub, bütün obyekt həyatı dövrü üçün sabit olan obyektin identifikatorları ilə tamamlanır.

Müştərilər PUT istifadə edərək, obyektlərin yarada və ya dəyişdirə bilməsi üçün API müəyyənləşdirdim:

 PUT /objects/{id} HTTP/1.1 ... {json representation of the object} 

Identifikator (id) obyektin identifikatorudur, ona görə də İstehlak-URI-nın bir hissəsidir.

İndi də POST istifadə edərək müştərilərin yaradılması imkanını nəzərdən keçirirəm:

 POST /objects/ HTTP/1.1 ... {json representation of the object, including ID} 

POST bir "əlavə etmə" əməliyyatı kimi başa düşüldükdə, obyekt artıq mövcud olduqda nə edəcəyinə əmin deyiləm. İstədiyi dəyişdirmə sorğusu kimi işləməməliyəmmi və ya bir səhv kodunu geri qaytarmalıyam?

454
30 сент. vmj tərəfindən müəyyən 30 sep . 2010-09-30 00:26 '10 at 0:26 2010-09-30 00:26
@ 12 cavab

409 Conflict mənim hissi ən uyğun, lakin nadir hallarda yabanı şəkildə baş verir:

Tələb, resursun hazırki vəziyyətinə zidd olduğundan tamamlana bilmədi. Bu kod yalnız istifadəçinin münaqişəni həll edə və tələbi yenidən göndərə biləcəyi vəziyyətlərdə icazə verilir. Cavab orqanı kifayət qədər məlumatı daxil etməlidirlər ki, istifadəçi münaqişənin mənbəyini tanıya bilsin. Ideal halda, cavab obyekti problemi həll etmək üçün istifadəçi və ya istifadəçi agenti üçün kifayət qədər məlumatı ehtiva edir; Ancaq bu mümkün deyil və ya tələb edilə bilməz.

Çatışmalar ən çox PUT tələbinə cavab olaraq baş verir. Məsələn, versiya istifadə edildikdə və PUT obyekti əvvəlcədən (üçüncü tərəf) sorğu ilə edilənlərə zidd olan bir qayda olan dəyişiklikləri ehtiva etdiyində, server 409 cavabını istifadə edə bilmir ki, bunun tələbi icra edə bilmir. Bir cavab obyekti olması halında, məzmun Türü cavab ilə müəyyən edilmiş formatda iki versiya arasında fərqlərin siyahısını ehtiva edir.

544
30 сент. Wrikken cavab 30 Sentyabr. 2010-09-30 00:31 '10 at 0:31 2010-09-30 00:31

Şəxsən mən WebDAV 422 Unprocessable Entity ilə gedirəm.

REST şablonları bunu təsvir edir

border=0

422 Unprocessable Entity statusu kodu server tələbin obyektinin məzmununu anlayır (bu səbəbdən, 415 Unsupported Media Type status kodu uyğun deyildir) və sorgu obyekti sözdizimi düzgündür (beləliklə, 400 Bad Request statusu kodu uyğun deyil), lakin təlimatlar.

41
30 сент. Gareth tərəfindən verilmiş cavab 30 sentyabr 2010-09-30 00:44 '10 at 0:44 2010-09-30 00:44

RFC 7231 uyğun olaraq 303-ə baxa bilərsiniz. POST emalının nəticəsi mövcud bir ehtiyatın bərabər təmsil olunmasıdır.

33
09 нояб. Cavab Nullius 09 noyabrda verilir. 2016-11-09 12:54 '16 at 12:54 2016-11-09 12:54

Daha sonra oyunda bəlkə, amma bu semantik problemi aradan qaldırdım, REST API'sini etməyə çalışırdım.

Wrikken'in cavabı haqqında bir az danışmaq üçün 409 Konvensiyadan və ya vəziyyətdən asılı olaraq 403 Forbidden istifadə edə biləcəyinizi düşünürəm - qısa olaraq, istifadəçi münaqişəni həll etmək üçün heç bir şey edə bilmədi və (məsələn, bir DELETE silmək üçün bir DELETE sorğu göndərə bilməzsiniz) və ya bir şey varsa, 409 istifadə edin.

10.4.4 403 Yasaq olun

Server sorğunu anladı, ancaq bunu icra etməkdən imtina etdi. Yetkilendirme kömək etməyəcək və tələb təkrarlanmamalıdır. Tələbi metodu HEAD deyilsə və server tələbi niyə yerinə yetirmədiyini ictimaiyyətə çatdırmaq istəyirsə, hüquqi şəxsin imtina edilməsinin səbəbini təsvir etməlidir. Server bu məlumatı müştəri istəməsə, vəziyyət kodu 404 (tapılmadı).

Hal-hazırda kimsə "403" deyir və icazələrin və ya identifikasiyası ilə bağlı problem ağla gəlir, lakin dəqiqləşdirmənin əsas şərtlərindən biri sadəcə olaraq serverin müştəriyə nə etməyəcəyini söyləyir, bir daha soruşmağı tələb etmir və bu səbəbdən müştəri .

PUT vs. POST ... POST , istifadəçi resurs identifikatorunu yaratmaq və ya yaratma imkanına malik olmadığı zaman yeni bir resurs nüsxəsi yaratmaq üçün istifadə edilməlidir. PUT , resurs identifikatoru bilinəndə istifadə olunur.

9.6 PUT

...

POST və PUT sorğuları arasında əsas fərq, fərqli İstek-URI dəyərində əks olunur. POST İstədiyiniz URI, əlavə təşkilatın idarə edəcəyi resursları müəyyənləşdirir. Bu qaynaq məlumat qəbul prosesi, başqa bir protokola keçid və ya ek notları qəbul edən bir vahid ola bilər. Bunun əksinə, PUT sorğusundakı URI tələbi ilə əhatə olunan obyekti müəyyənləşdirir - istifadəçi agenti URI-nin nə olduğunu bilir və server tələbi başqa bir mənbəyə tətbiq etməyə cəhd etməməlidir. Əgər server tələbi fərqli bir URI tətbiq etmək istəyirsə,

301 (köçürülən qalıcı) cavabı göndərməli; istifadəçi agenti tələbi yönləndirməyin olub-olmadığı barədə qərar qəbul edə bilər.

9
25 дек. Cavab p0lar_bear 25 dekabrda verilir. 2015-12-25 01:40 '15 'də 1:40' de 2015-12-25 01:40

"302 tapıldı" mənə mantiqlı səslənir. Və RFC 2616 onu GET və HEAD başqa istəklər üçün cavab verə bilər (və əlbəttə ki, POST daxildir)

Lakin bu, "bu" tapılmış "RFC-i almaq üçün qonaqa bu URL-ə getməyə imkan vermir. Doğrudan "Real" ünvanına getmək üçün, "303 Bax" Digər ", bu mənada, lakin başqa bir zəng edir aşağıdakı URL GET. Yaxşı tərəfdən, bu GET cached bilər.

Düşünürəm ki, mən "303 digərinə bax" istifadə edəcəyəm . Bədəndə olan "şey" ilə cavab verə biləcəyimi bilmirəm, amma serverdə bir geri hərəkət etmək üçün bunu etmək istərdim.

Yeniləmə :. RFC'yi yenidən oxuduqdan sonra hələ də "4XX + 303 tapılmadı" kodunun doğru olduğuna inanıram. Bununla belə, "409 Münaqiş " ən yaxşı mövcud cavab kodudur (@Wrikken göstərildiyi kimi), ehtimal ki, Mövcud bir mənbəyə işarə edən bir Mövzu başlığı daxildir.

9
16 мая '12 в 12:25 2012-05-16 12:25 Cavab alanjds tərəfindən verilir 16, '12 12:25 2012-05-16 12:25

Bunu etməməyi düşünmürəm.

POST, bildiyiniz kimi, kolleksiyanı dəyişir və yeni bir maddə yaratmaq üçün istifadə olunur. Belə ki, bir identifikator göndərirsinizsə (yaxşı fikir deyildirsə), toplusunu dəyişdirməlisiniz, yəni. Maddəni dəyişdirin, ancaq bu qarışıqdır.

Kimliksiz bir maddə əlavə etmək üçün onu istifadə edin. Bu ən yaxşı təcrübədir.

Bir UNIQUE məhdudiyyətini (identifikator deyil) düzəltmək istəyirsinizsə, PUT sorğularında olduğu kimi 409-a cavab verə bilərsiniz. Ancaq bir identifikator deyil.

7
30 сент. Alfonso Tienda'ya cavab 30 Sep. 2014-09-30 13:12 '14 'də 13:12' de 2014-09-30 13:12

Hesab edirəm ki, REST üçün bu sistemin davranışı barədə qərar qəbul etməlisiniz və bu halda "düzgün" cavabı burada verilən iki cavabdan biri hesab edirəm. İstədiyiniz müştərinin bir səhv etdiyini dayandırmaq və davranışını davam etdirmədən əvvəl düzəltmək istədiyində 409 istifadə edin. Əgər münaqişə həqiqətən əhəmiyyətli deyilsə və o, istəkləri saxlamaq istəyirsə, onda müştərini tapın obyektə. Hesab edirəm ki, doğru REST API'ları POST-dan sonra bu qayda üçün GET son nöqtəsinə istiqamətləndirməlidir (və ya ən azı bir yerin başlığı), buna görə də bu davranış davamlı təcrübə verəcəkdir.

EDIT: Qeyd etmək lazımdır ki, bir identifikator təmin etdikdən sonra PUT hesab etməlisiniz. Sonra davranış sadədir: "İndi nə var ki, mənə qayğı yoxdur, bu işi orada qoyun." Heç bir şey olmasa, dəyər yaradılacaq; bir şey varsa, əvəz olunacaq. Hesab edirəm ki, server bu identifikatoru idarə edərkən POST daha münasibdir. İki konsepsiyanın ayrılması, əsasən, onunla necə məşğul olacağınızı (yəni PUT idempotentdir, buna görə də paylayıcı yükləndikdən sonra həmişə işləməlidir, POST həmişə yaradıcıdır, buna görə də identifikatorların toqquşması olduqda, 409 bu qarşıdurma).

3
27 окт. cavab Senaesthetic Oct 27 verildi . 2016-10-27 07:51 '16 saat 07:51 'də 2016-10-27 07:51

418-i geri qaytarmaq necə olar?

Müştəri serverdə mövcud olan bir şəxsin saxlanmasını istəməsi səbəbindən server nəhayət qəzəblənəcək və çaydanın geri qaytarıldığını düşünəcəkdir: 418 I'm a teapot .

Ədəbiyyat:

3
20 июля '17 в 23:39 2017-07-20 23:39 Cavab Ruffp tərəfindən 20 İyulda '17 'də 23:39 2017-07-20 23:39' də verildi

Niyə 202 qəbul edilmədi? Bu bir OK sorğu (200 saniyə), müştəri səhvləri (400) olmadı.

10 dövlət kodu anlayışından :

"202 qəbul edildi. İstehsal üçün qəbul edildi, amma emal tamamlanmadı".

... çünki başa çatdırmaq lazım deyil, çünki artıq mövcuddur. Müştəri artıq mövcud olduğunu bilmir, heç bir şey etməyiblər.

Mən 202 atmaq və GET /{resource}/{id} nə dönəcəyinə bənzər məzmuna dönməyə meyl edirəm.

2
18 марта '16 в 1:12 2016-03-18 01:12 Cavab Phillip Harrington tərəfindən 18 Mart 18:12 ' də 1:12 2016-03-18 01:12' də verilir

Digər potensial müalicə PATCH istifadə edir. PATCH daxili vəziyyəti dəyişən və əlavə etməklə məhdudlaşmır bir şey kimi müəyyən edilir.

PATCH, mövcud elementləri yeniləməyə imkan verərək problemi həll edir. Bax: RFC 5789: PATCH

2
07 сент. Martin Kersten tərəfindən verilmiş cavab 07 Sep 2015-09-07 14:33 '15 'də saat 14:33' de

Duplicate girişlər üçün doğru kodu yoxlayaraq, bu sual üzərinə sıçradı.

Üzr istəmirəm, ancaq başa düşmürəm ki, hər kəs "300" kodunu görməməzdən əvvəl "çox seçim" və ya "qeyri-müəyyən"

Məncə, bu, öz istifadəsi üçün qeyri-standart və ya xüsusi bir sistem yaratmaq üçün ideal bir kod olacaq. Mən də yanlışyam!

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

1
02 янв. Cavab Hitin verildi 02 Yanvar. 2017-01-02 17:01 '17 saat 17.00 'də 2017-01-02 17:01

Haqqında 208 - http://httpstatusdogs.com/208-already-reported ? Bu bir seçimdir?

Mənim fikrimcə təkrar bir qayda var ki, tək şey varsa, səhvlər qaldırılmamalıdır. Nəticədə, müştəri tərəfində və ya server tərəfində heç bir səhv yoxdur.

1
31 июля '15 в 21:07 2015-07-31 21:07 cavab Fernando Ferreira 31 iyul 'da 21:07' də verilir 2015-07-31 21:07