REST-də POST-ə qarşı

HTTP / 1.1 Spec xüsusiyyətlərinə görə:

POST metodu, qaynaq serverinin istənilən obyekti İstehlak Request-URI ilə müəyyən edilmiş yeni bir alt resurs kimi qəbul etməsini tələb etmək üçün istifadə olunur

Başqa sözlə, POST yaratmaq üçün istifadə olunur.

PUT metodu, xüsusi obyektin təchiz olunmuş Request-URI də saxlanmasını tələb edir. Request-URI zaten mövcud bir kaynağa aidse, kapalı bir kuruluş, orijinal server üzerinde yer alan birinin değiştirilmiş bir versiyası olaraq kabul edilmelidir. Request-URI mövcud bir kaynak belirtmezse ve URI'nın istenen kullanıcı aracılığıyla yeni bir kaynak olarak tanımlanabileceği durumlarda, orijinal sunucusu bu URI ile bir kaynak oluşturabilir. ""

Yəni, PUT yaratmaq və ya yeniləmək üçün istifadə olunur.

Yəni bir qaynaq yaratmaq üçün istifadə olunmalıdır? Və ya hər ikinizi dəstəkləməlisiniz?

4581
10 марта '09 в 17:25 2009-03-10 17:25 alex 10 mart '09 saat 17:25 'də təyin olundu. 2009-03-10 17:25
@ 33 cavab
  • 1
  • 2

Ümumiyyətlə:

Həm PUT, həm də POST yaradılması üçün istifadə edilə bilər.

Siz soruşmaq lazımdır: nə üçün hərəkət edirsiniz? istifadə etdiyiniz şeyi ayırd etmək. Suallar üçün bir API hazırlayırsınız. POST istifadə etmək istəyirsinizsə, bunu suallar siyahısında etmək lazımdır. PUT istifadə etmək istəyirsinizsə, müəyyən bir məsələ ilə bunu edə bilərsiniz.

Hər iki variantdan istifadə edə bilərsiniz, belə ki, onu RESTful dizaynında istifadə etmək lazımdır:

PUT və POST dəstəyinə ehtiyacınız yoxdur.

Sizin üçün istifadə olunur. Ancaq istəkdə istinad etdiyiniz obyektdən asılı olaraq doğru seçimdən istifadə etməyi unutmayın.

Bəzi hallar:

  • Siz açıq şəkildə yaradılan URL obyektlərini adlandırırsınız və ya serverə icazə verirsiniz? Onlara zəng etsəniz, PUT istifadə edin. Əgər serverə icazə verərsinizsə, sonra POST istifadə edin.
  • PUT idempotentdir, buna görə bir obyektə ikiqat vurun, heç bir təsiri yoxdur. Bu gözəl bir xüsusiyyətdir, buna görə mümkün olduğunda PUT'u istifadə edə bilərəm.
  • Eyni obyekt URL ilə PUT istifadə edərək, bir qaydanı yeniləyə və ya yarada bilərsiniz
  • POST ilə eyni vaxtda 2 sorğu göndərə bilərsiniz, URL-də dəyişikliklər edər və obyektin müxtəlif hissələrini dəyişə bilərlər.

Məsələn:

Aşağıdakıları aşağıdakı mövzuda SO cavabının bir hissəsi kimi yazdım :

POST

Bir resursı dəyişmək və yeniləmək üçün istifadə olunur.

 POST /questions/<existing_question> HTTP/1.1 Host: www.example.com/ 

Aşağıdakı səhv olduğunu unutmayın:

 POST /questions/<new_question> HTTP/1.1 Host: www.example.com/ 

URL hələ yaradılmadıysa, adı göstərərək onu yaratmaq üçün POST istifadə etməməlisiniz. Bu, bir <new_question> hələ mövcud deyil, çünki bir kaynak <new_question> . <new_question> kaynak düğmesine <new_question> .

POST istifadə edərək resurs yaratmaq üçün belə bir şey edə bilərsiniz:

 POST /questions HTTP/1.1 Host: www.example.com/ 

Xahiş edirik, bu halda, resurs adı göstərilməyib, yeni URL obyektləri sizə qaytarılacaq.

PUT:

Bir resurs yaratmaq və ya yazmaq üçün istifadə olunur. Yeni URL-nin resurslarını müəyyən etdiyiniz müddətcə.

Yeni bir qaynaq üçün:

 PUT /questions/<new_question> HTTP/1.1 Host: www.example.com/ 

Mövcud bir qaydanın üzərində yazmaq üçün:

 PUT /questions/<existing_question> HTTP/1.1 Host: www.example.com/ 
3603
10 марта '09 в 17:29 2009-03-10 17:29 Brian R. Bondy -ə 10 mart 2009 -cu il saat 17: 29-da cavab verib

İnternette deyilənləri tapa bilərsiniz

Heç bir şey olmaz.


PUT və POST arasında idempotence fəaliyyətinə uyğun seçim etmək daha yaxşıdır.

PUT bir qaynağın yerləşdirilməsini nəzərdə tutur - hər hansı bir URL-də mövcud olan hər şeyi tamamilə əvəz edir. Tərifə əsasən, PUT idempotentdir. İstədiyiniz qədər bunu edin və nəticə eyni olacaq. x=5 idempotentdir. Daha əvvəl və ya mövcud olmayan bir qayda (məsələn, yaratmaq və ya yeniləmək üçün) müəyyən edə bilərsiniz!

POST bir qaydanı yeniləyir, köməkçi bir qaynaq əlavə edir və ya bir dəyişməyə səbəb olur. POST idempotent deyil, çünki x++ idempotent deyil.

border=0

Bu arqumentlə, PUT yaradılmış maddənin URL'sini bildiyiniz zaman yaratmaq üçün nəzərdə tutulmuşdur. POST, yaratmaq istədiyiniz şeylər kateqoriya üçün "zavod" və ya menecerin URL'sini bildiyiniz zaman yaratmaq üçün istifadə oluna bilər.

beləliklə:

 POST /expense-report 

və ya

 PUT /expense-report/10929 
1925
22 апр. Cavab 22 aprel tarixində Cheeso tərəfindən verilir 2010-04-22 17:55 '10 at 17:55 2010-04-22 17:55
  • URL'ə POST serverə xüsusi bir URLdə bir uşaq resursu yaradır .
  • URL-yə PUT müştəri tərəfindən göstərilən URL- bütün resursları yaradır / dəyişdirir .
  • URL URL'sinə PATCH , müəyyən bir müştəri URL- də resursun bir hissəsini yeniləyir .

PUT və POST RFC 2616 §9.5ff üçün müvafiq spesifikasiya .

POST bir uşaq resursu yaradır , belə ki POST /items /items altında yaşayan resursları yaradır. Məsələn, /items/1 . Eyni poçt paketinin göndərilməsi iki qaynaq yaradacaq.

PUT , müştəri üçün bilinən bir URL ilə bir resurs yaratmaq və ya dəyişdirmək üçün nəzərdə tutulmuşdur.

Buna görə: PUT yalnız CREATE üçün bir namizəddir, burada müştəri resurs yaratmadan əvvəl URL-ni bilir. Məsələn, /blogs/nigel/entry/when_to_use_post_vs_put , başlıq bir qaynaq açarı olaraq istifadə olunur

PUT, bilinən bir URL-də bir qaydanı əvəz edir, əgər varsa, eyni tələbi iki dəfə təsir etməyəcəkdir. Başqa sözlə, PUT çağırışları idempotentdir .

RFC aşağıdakı kimi oxunur:

POST və PUT sorğuları arasında əsas fərq, fərqli İstek-URI dəyərində əks olunur. POST sorğusundakı URI əlavə olunmuş obyekti idarə edəcək qaynağı müəyyənləşdirir. Bu qaynaq məlumat qəbul prosesi, başqa bir protokolun bir qapısı və ya şərhləri qəbul edən ayrı bir şəxs 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ə,

Qeyd: PUT əsasən resursları yeniləmək üçün istifadə edilmişdir (onları tam olaraq əvəz etməklə), lakin son zamanlar mövcud resursları yeniləmək üçün PATCH istifadə etmək üçün bir hərəkət olmuşdur, çünki PUT bütün resursları əvəz edir. RFC 5789.

575
07 апр. Nigel Thorne tərəfindən verilmiş cavab 07 Apr 2010-04-07 08:52 '10 at 8:52 2010-04-07 08:52

Xülasə:

Yarat:

PUT və ya POST ilə aşağıdakı kimi edilə bilər:

PUT

Yeni bir qaynaq yaradır resurs və ya toplama / uri -də identifikator kimi newResourceId ilə.

 PUT /resources/<newResourceId> HTTP/1.1 

POST

Resurs URI / kolleksiyasında yeni A resursu yaradır. Ümumiyyətlə, ID server tərəfindən qaytarılır.

 POST /resources HTTP/1.1 

Yeniləmə:

Yalnız aşağıdakı kimi PUT istifadə edilə bilər:

PUT

Mövcud ResourceId'yi resurs və ya toplama / URI'sında identifikator olaraq istifadə edən bir qaydanı yeniləyir.

 PUT /resources/<existingResourceId> HTTP/1.1 

Şərhlər:

REST və URI ilə ümumi olaraq işləyərkən, solda və hüququ birində müəyyən bir ümumi var. generics adətən koleksiyonlar deyilir və daha spesifik elementlər bir qaynaq adlandırıla bilər. Resursda bir kolleksiya ola biləcəyini unutmayın.

Nümunələr:

<- generic - xüsusi →

 URI: website.com/users/john website.com - whole site users - collection of users john - item of the collection, or a resource URI:website.com/users/john/posts/23 website.com - whole site users - collection of users john - item of the collection, or a resource posts - collection of posts from john 23 - post from john with identifier 23, also a resource 

POST istifadə etdiyiniz zaman , həmişə kolleksiyaya baxırsınız , buna görə də dediyiniz zaman:

 POST /users HTTP/1.1 

İstifadəçilər kolleksiyasına yeni istifadəçi göndərirsiniz.

Davam etsən və bu kimi bir şeyə cəhd edin:

 POST /users/john HTTP/1.1 

işləyəcək, ancaq semantik olaraq john kolleksiyasına bir qaynaq əlavə etmək istəyirik. toplanması altında .

PUT istifadə etdiyiniz kimi, ehtimal ki, bir kolleksiya daxilində bir qayda və ya bir maddəni istinad edirsiniz. Buna görə də deyirsiniz:

 PUT /users/john HTTP/1.1 

Bir server yeniləməsini bildirirsinizsə və ya mövcud deyilsə, john resurs yaratırsınız. istifadəçi kolleksiyası altında.

Xüsusiyyət:

Texnikanın bəzi vacib hissələrini qeyd edim:

POST

POST metodu, qaynaq serverinin sorğuda əlavə edilmiş bir obyektin sorğu sütununda istek-URI'sinde yeni alt tabanlı bir kaynak olaraq qəbul edilməsini tələb etmək üçün istifadə olunur

Buna görə toplanmada yeni bir resurs yaradılır. .

PUT

PUT üsulu, qapalı obyektin istənilən İstek-URI'da saxlanılmasını tələb edir. İstek-URI zaten var olan bir kaynağa aidse , kapalı bir varlık, kaynak sunucuda yer alan birinin değiştirilmiş bir versiyası olaraq kabul edilmelidir. İstek-URI mövcud bir kaynağa aid deyilsə və bu URI istənilən istifadəçi agenti tərəfindən yeni bir qaynaq kimi təyin oluna bilərsə, mənbə server URI ilə bir qaynaq yarada bilər. ""

Buna görə, resursun mövcudluğuna əsaslanaraq yaradın və ya yeniləyin.

Kömək:

173
15 авг. Cavab verilir 7hi4g0 15 aug. 2013-08-15 01:47 '13 'da 1:47' də 2013-08-15 01:47

Mən "pragmatik" məsləhətimi əlavə etmək istərdim. Saxlaya bilən bir obyekti saxlaya biləcəyiniz "id" ini bildiyiniz zaman PUT istifadə edin. Gələcək axtarış və ya yeniləmələr üçün sizə qaytarılacaq bir verilənlər bazasından yaradılan bir identifikatora ehtiyacınız olduqda, PUT istifadə edərək çox yaxşı işləməyəcəkdir.

Beləliklə: mövcud bir istifadəçi saxlamaq və ya müştəri bir identifikatoru yaradan və identifikatorun unikal olduğu təsdiq edilmişdir:

 PUT /user/12345 HTTP/1.1 <-- create the user providing the id 12345 Host: mydomain.com GET /user/12345 HTTP/1.1 <-- return that user Host: mydomain.com 

Əks halda, əvvəlcə obyekt yaratmaq üçün POST istifadə edin və obyekti yeniləmək üçün PUT:

 POST /user HTTP/1.1 <--- create the user, server returns 12345 Host: mydomain.com PUT /user/12345 HTTP/1.1 <--- update the user Host: mydomain.com 
158
15 янв. Cavab 15 yanvar ThaDon tərəfindən verilir 2011-01-15 22:59 '11 saat 10:59 'da 2011-01-15 22:59

POST "yeni bir yaratmaq" deməkdir. "Burada bir istifadəçi yaratmaq üçün giriş, mənim üçün yaradın."

PUT, "Burada istifadəçi 5-də məlumat" kimi olduğu kimi, "əlavə edin, əgər varsa, əvəz" deməkdir.

İstifadəçinin URL'sini bilmirsinizsə, serverin yaradılmasını istəyirik, çünki example.com/users üçün POST istifadə edirsiniz.

Xüsusi bir istifadəçi dəyişdirmək / yaratmaq istədiyiniz üçün example.com/users/id ünvanında PUT olunur.

Eyni məlumatlarla iki dəfə POSTing müxtəlif identifikatorlar ilə iki eyni istifadəçi yaratmaq deməkdir. Eyni məlumatlarla iki dəfə işləyən istifadəçi ilk yaradır və eyni vəziyyətdə ikinci dəfə (dəyişiklik yoxdur) yeniləyir. PUT-dan sonra eyni vəziyyətdə özünüzü tapdığınızdan, neçə dəfə həyata keçirməyinizə baxmayaraq, hər dəfə "eyni dərəcədə güclü" sayılır - idempotent. Bu avtomatik təkrar istəklər üçün faydalıdır. Brauzerdəki "Geri" düyməsinə basarkən daha çox "göndərmək istədiyinizə əmin deyilsiniz".

Ümumi bir ipucu, serverin resurs URL-lərinizin nəslinə nəzarət etməsini istədiyiniz zaman POST-dan istifadə etməkdir. Əks halda PUT istifadə edin. POST üzərində PUT üstünlük təşkil edin.

149
23 окт. 23 oktyabrda Alexander Torstlingə cavab verin 2011-10-23 17:27 '11 at 17:27 2011-10-23 17:27

Təqdim etmək üçün POST istifadə edin və yeniləmək üçün PUT. Yəqin ki, Ruby on Rails bunu necə edir.

 PUT /items/1 #=> update POST /items #=> create 
110
10 марта '09 в 17:28 2009-03-10 17:28 Tim Sallivan tərəfindən 10 Mart 2009-cu ildə verilmiş cavab 17:28 2009-03-10 17:28

REST çox yüksək səviyyəli bir konseptdir. Əslində, HTTP-nin heç də söz etməməsi!

HTTP-də REST-in həyata keçirilməsinə dair hər hansı bir şübhə varsa, həmişə Atom Nəşr Protokolu (AtomPub) spesifikasiyasına baxa bilərsiniz . AtomPub HTTP və HTTP özünün ixtiraçı Roy Fielding, REST ixtiraçıları və (co-) ixtiraçıları ilə bir çox HTTP və REST mənbələri tərəfindən hazırlanmış HTTP ilə RESTful web xidmətləri yazmaq üçün standartdır.

Əslində, doğrudan AtomPub istifadə edə bilərsiniz. Bloglama ictimaiyyətindən çıxsa da, heç bir şəkildə bloglarla məhdudlaşmır: HTTP vasitəsilə zahiri resursların keyfi (yuvalanmış) koleksiyonlarını RESTfully ilə qarşılıqlı ümumi protokoldur. Ərizənizi iç içə bir qaynaq koleksiyonu olaraq təqdim edə bilsəniz, sadəcə AtomPub-dan istifadə edə bilərsiniz və HTTP statusu kodlarının qaytarılması və bütün bu məlumatları PUT və ya POST istifadə etməyiniz barədə narahat olmayın.

AtomPub'un resursları yaratmaq barədə söylədiyi (9.2) bölmə:

Kolleksiyaya üzvləri əlavə etmək üçün müştərilər POST istəklərini toplama URI-na göndərirlər.

59
10 марта '09 в 18:27 2009-03-10 18:27 Cavab Jörg W Mittag tərəfindən martın 10-da saat 18: 27-də verilir. 2009-03-10 18:27

HTTP + REST API ilə serverdə resurs yaratmaq üçün PUT və ya POST istifadə etməyiniz barədə qərar URL quruluşuna sahib olanlara əsaslanır. Bir müştəri olması və ya müəyyənləşdirilməsinə qoşulması, URL strukturu SOA-dan çıxarılan istənməyən linklərə bənzəyən lazımsız bir linkdir. Kaplin tiplərindən qaçınmaq RESTin bu qədər populyar olması səbəbidir. Buna görə istifadə etmək üçün düzgün üsul POST'dur. Bu qayda üçün istisnalar var və müştəri o yerləşdirdiyi resursların yerləşdiyi yerə nəzarət etməsini istəyirsə ortaya çıxır. Bu nadirdir və ehtimal ki, başqa bir şey səhvdir.

Bu nöqtədə bəzi insanlar RESTful URL istifadə edildikdə, müştəri resurs URL-i bilir və bu səbəbdən PUT qəbul edilə bilər. Bütün sonra, bu səbəbdən, kanonik, normallaşdırılmış, Ruby on Rails, Django URL'ləri əhəmiyyətli, Twitter API ... blah blah baxın. Bu insanlar Rahat bir URL kimi bir şey olmadığını başa düşməlidirlər və Roy Fielding'in özündən belə bir iddia :

REST API sabit qaynaq adları və ya hiyerarşiləri müəyyən etməməlidir (müştəri ilə server arasındakı açıq bir əlaqə). Serverlər öz adlarını idarə etmək azadlığına sahib olmalıdırlar. Bunun əvəzinə, serverlərə müştərilərə müvafiq URI-ləri yaratmaq, məsələn, HTML formaları və URI nümunələri yaratmaq üçün təlimat verin, bu təlimatları bir növ və assosiasiya mühitində müəyyənləşdirin. [İşin baş verməməsi müştərilərin, RPC funksional bir linkə veri yönümlü bir ekvivalent olan domenə özgü bir standart kimi, qrupdan kənar məlumatlara görə bir qaynaq quruluşunu qəbul etdiyini nəzərdə tutur].

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

RESTful URL-nin ideyası həqiqətən REST-in pozulmasıdır, çünki server URL-nin strukturundan məsuliyyət daşıyır və ünsiyyətdən qaçmaq üçün necə istifadə olunacağına dair qərar vermək hüququ olmalıdır. Əgər bu sizi qarışdırırsa, API dizaynında özünü aşkarlamanın mənasını oxuyun.

POST istifadə edərək resursları yaratmaq dizayn məsələlərinə aiddir, çünki POST idempotent deyildir. Bu təkrarlanan POST bir neçə dəfə hər dəfə eyni davranışa zəmanət vermir. İnsanları lazım olmadığı zaman resursları yaratmaq üçün PUT-dan istifadə etməyi qorxudur. Onlar yanlış bilirlər (CREATE üçün POST), lakin onlar hələ də bu problemi həll etmək üçün necə bilmirlər. Bu problem aşağıdakı hallarda özünü göstərir:

  • Müştəri serverə yeni bir server göndərir.
  • Server tələbi işlədir və cavabı göndərir.
  • Müştəri heç vaxt cavab ala bilmir.
  • Server müştərinin cavab almadığını bilmir.
  • Müştəri heç bir resurs URL (bu səbəbdən PUT bir seçim deyil) və POST təkrar edir.
  • POST idempotent deyil və server ...

Addım 6 insanların tez-tez nə edəcəyi barədə səhv edildiyi yerdir. Ancaq bu problemi həll etmək üçün bir çuluq yaratmaq üçün bir səbəb yoxdur. Bunun yerine HTTP, RFC 2616'da göstərildiyi kimi istifadə edilə bilər və server cavab verir:

10.4.10 409 Münaqişə

Tələb resursun hazırkı vəziyyəti ilə ziddiyyətlər səbəbindən icra edilə bilməz. 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 verən orqan kifayət qədər daxil olmalıdır

münaqişənin mənbəyini tapmaq üçün istifadəçi üçün məlumat. 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) bir sorğuya zidd olan bir qayda dəyişiklikləri ehtiva edirsə, server 409 cavabını istifadə etməyərək istək yerinə yetirə bilməyəcəyini göstərə bilər. Bu halda, məzmun Tipi cavabı ilə müəyyənləşdirilmiş formatda iki versiya arasında fərqlərin siyahısını ehtiva edir.

Status koduyla cavab 409 Münaqişə düzgün regressiya, çünki :

  • Sistemdə artıq bir qayda ilə əlaqəli bir identifikatora sahib POST məlumatının yerinə yetirilməsi "resursun mövcud vəziyyətinə ziddir".
  • Mühüm hissə, müştərinin serverin öz resursuna malik olduğunu və müvafiq tədbirlər görəcəyini anladığıdır. Bu, istifadəçinin münaqişənin həllinə və tələbi yenidən göndərməyə imkan verəcəyi halda "vəziyyət (lər)" dir.
  • Çağırıcı identifikator olan bir qaynağın URL'si və resurs üçün müvafiq şərtlər ehtiva edən bir cavab RFC 2616 üçün ideal bir vəziyyət olan "istifadəçi və ya istifadəçi agenti problemi həll etmək üçün kifayət qədər məlumat" təmin edəcəkdir.

RFC 7231 versiyasına əsasən 2616 əvəzinə yenilənməsi

RFC 7231 , 2616 və 4.3.3-ün əvəz olunması üçün nəzərdə tutulub, POST üçün mümkün cavab verir

POST prosesinin nəticəsi mövcud bir resurs təqdim etmək üçün bərabərdirsə, mənbə server MƏRHƏLƏ sahəsində mövcud resurs identifikatoru ilə 303 ("Digərləri" bölməsinə bax) cavab göndərərək istifadəçi agentini bu resursa yönəldə bilər. Bu, istifadəçi agentinə bir qaynar identifikator təmin etmək və görünüşü daha ümumi bir önbellek üsulu ilə təqdim etmənin üstünlüyünə malikdir, ancaq istifadəçi agenti hələ önbelleklenmemişse əlavə sorğu hesabına.

İndi POST təkrarlansaydı, sadəcə 303-ə dönmək cazibədar ola bilər. Bunun əksinə də doğru. 303-ə qayıdarkən, eyni məzmunu yaratmaq üçün müxtəlif resurslar yaratmaq üçün bir neçə istək var. Bir nümunə, "istək mesajınızı göndərdiyiniz üçün təşəkkür edirik", bir müştərinin hər dəfə yenidən yüklənməsinə ehtiyac yoxdur. RFC 7231, Bölmə 4.2.2-də hələ POST'un idempotent olmaması və POST'un yaradılması üçün istifadə edilməsinə dəstək verməyə davam edir.

Bu barədə daha ətraflı məlumat üçün məqaləni oxuyun.

54
ответ дан Joshcodes 30 окт. '13 в 2:00 2013-10-30 02:00

Оба используются для передачи данных между клиентом на сервер, но между ними существуют тонкие различия, которые:

2019

ответ дан Premraj 11 сент. '15 в 16:12 2015-09-11 16:12

Мне нравится этот совет, из RFC 2616 определения PUT :

Основное различие между запросами POST и PUT отражается в различном значении Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать заключенный объект. Этот ресурс может быть процессом принятия данных, шлюзом к другому протоколу или отдельным объектом, который принимает аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный с запросом - пользовательский агент знает, что такое URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к другому ресурсу.

Это приводит к другому совету здесь, что PUT лучше всего применяется к ресурсам, которые уже имеют имя, а POST хорош для создания нового объекта под существующим ресурсом (и позволяя ему называть его имя).

Я интерпретирую это и требования идемпотентности в PUT, чтобы это означало, что:

  • POST хорош для создания новых объектов под коллекцией (и создавать не нужно идемпотент)
  • PUT хорош для обновления существующих объектов (и обновление должно быть идемпотентным).
  • POST также может использоваться для не-идемпотентных обновлений существующим объектам (особенно, изменяя часть объекта без указания всего этого - если вы думаете об этом, создание нового члена коллекции фактически является особым случаем этот вид обновления, с точки зрения коллекции)
  • PUT также может использоваться для создания, если и только если вы разрешаете клиенту указывать ресурс. Но поскольку клиенты REST не должны делать предположения о структуре URL, это меньше в намеченном духе вещей.
49
ответ дан metamatt 11 янв. '12 в 20:18 2012-01-11 20:18

Короче:

PUT является idempotent, где состояние ресурса будет одинаковым, если одна и та же операция выполняется один или несколько раз.

POST не является idempotent, где состояние ресурса может стать другим, если операция выполняется несколько раз по сравнению с выполнением одного времени.

Аналогия с запросом базы данных

PUT . Вы можете думать о том же, что и "UPDATE STUDENT SET address =" abc ", где id =" 123 ";

POST Вы можете думать о чем-то вроде "INSERT INTO STUDENT (имя, адрес) VALUES (" abc "," xyzzz ");

Идентификатор студента автоматически генерируется.

С PUT, если один и тот же запрос выполняется несколько раз или один раз, состояние таблицы STUDENT остается неизменным.

В случае POST, если один и тот же запрос выполняется несколько раз, в базе данных создается несколько записей Студента, а состояние базы данных изменяется при каждом выполнении запроса "INSERT".

Qeyd. PUT нуждается в местоположении ресурса (уже-ресурсе), на котором должно произойти обновление, тогда как POST этого не требует. Поэтому интуитивно POST предназначен для создания нового ресурса, тогда как PUT необходим для обновления уже существующего ресурса.

Некоторые могут придумать, что обновления могут быть выполнены с помощью POST. Нет жесткого правила, которое можно использовать для обновлений или для использования для создания. Опять же, это конвенции, и я интуитивно склоняюсь к вышеупомянутым рассуждениям и следую им.

40
ответ дан bharatj 29 июля '16 в 14:11 2016-07-29 14:11

POST - это как отправить письмо в почтовый ящик или отправить электронное письмо в очередь электронной почты. PUT похож на то, когда вы помещаете объект в кубическое отверстие или место на полке (у него есть известный адрес).

С помощью POST вы отправляете на адрес QUEUE или COLLECTION. С помощью PUT вы указываете адрес ITEM.

PUT является идемпотентным. Вы можете отправить запрос 100 раз, и это не имеет значения. POST не является идемпотентным. Если вы отправляете запрос 100 раз, вы получите 100 писем или 100 писем в почтовом ящике.

Общее правило: если вы знаете идентификатор или имя элемента, используйте PUT. Если вы хотите, чтобы идентификатор или имя элемента были назначены принимающей стороной, используйте POST.

2019

39
ответ дан Homer6 14 июня '13 в 21:10 2013-06-14 21:10

Новый ответ (теперь, когда я лучше понимаю REST):

PUT - это просто утверждение о том, какое содержание, которое служба должна использовать с этого момента, для визуализации представлений ресурса, идентифицированного клиентом; POST - это выражение о том, какой контент должен предоставлять служба, с этого момента (возможно, дублируется), но до сервера, как идентифицировать этот контент.

PUT x (если x идентифицирует ресурс ): "Замените содержимое ресурса, идентифицированного x моим содержимым".

PUT x (если x не идентифицирует ресурс): "Создайте новый ресурс, содержащий мой контент, и используйте x для его идентификации".

POST x : "Сохраните мой контент и дайте мне идентификатор, который я могу использовать для идентификации ресурса (старого или нового), содержащего указанный контент (возможно, смешанного с другим контентом). Указанный ресурс должен быть идентичным или подчиненным тому, который идентифицирует x ". "y ресурс подчинен x ресурсу", как правило, но не обязательно реализуется путем создания ya подпути x (например, x = /foo и y = /foo/bar ) и изменения представления (ов) x ресурса, чтобы отразить существование новый ресурс, например, с гиперссылкой на ресурс y и некоторые метаданные. Только последний действительно необходим для хорошего дизайна, поскольку URL-адреса непрозрачны в REST - вы должны использовать гипермедиа вместо структуры URL-адреса на стороне клиента, чтобы в любом случае проходить службу.

В REST нет такой вещи, как ресурс, содержащий "контент". Я называю "контент" данными, которые служба использует для рендеринга представлений. Он обычно состоит из некоторых связанных строк в базе данных или файле (например, файл изображения). Это до службы для преобразования пользовательского контента во что-то, что может использовать служба, например, преобразование полезной нагрузки JSON в SQL-запросы.

Оригинальный ответ (может быть, легче читать) :

PUT/something (если /something уже существует): "Возьмите все, что у вас есть /something и замените его тем, что я вам даю".

PUT/something (если /something еще не существует): "Возьми то, что я тебе даю, и поставлю его /something ".

POST/something : "Возьмите то, что я вам даю, и поставлю его в любом месте, где вы хотите /something пока вы дадите мне свой URL, когда закончите".

35
ответ дан Jordan 01 авг. '12 в 23:10 2012-08-01 23:10

Ruby on Rails 4.0 будет использовать метод PATCH вместо PUT для частичного обновления.

RFC 5789 говорит о PATCH (с 1995 года):

Для улучшения взаимодействия и предотвращения ошибок необходим новый метод. Метод PUT уже определен, чтобы перезаписать ресурс с полным новым телом и не может быть повторно использован для частичных изменений. В противном случае прокси и кэши, а также клиенты и серверы могут запутаться в результате операции. POST уже используется, но без широкой функциональной совместимости (например, нет стандартного способа обнаружения поддержки формата патча). PATCH упоминался в более ранних спецификациях HTTP, но не полностью определен.

" Edge Rails: PATCH - это новый первичный HTTP-метод для обновлений ", - объясняет он.

32
ответ дан germanlinux 26 февр. '12 в 12:21 2012-02-26 12:21

Короткий ответ:

Простое эмпирическое правило: используйте POST для создания, используйте PUT для обновления.

Длинный ответ:

POST:

  • POST используется для отправки данных на сервер.
  • Полезно, когда URL ресурса неизвестен

PUT

  • PUT используется для передачи состояния на сервер
  • Полезно, когда известен URL-адрес ресурса

Более длинный ответ:

Чтобы понять это, нам нужно задать вопрос, почему PUT был необходим, каковы были проблемы, которые PUT пытался решить, что POST не смог.

С точки зрения архитектуры REST нет ничего важного. Мы могли бы жить без PUT. Но с точки зрения клиентского разработчика это сделало его жизнь намного проще.

До PUT клиенты не могли напрямую знать URL-адрес, сгенерированный сервером, или все, что он создал, или данные, которые будут отправлены на сервер, уже обновлены или нет. PUT избавил разработчика от всех этих головных болей. PUT является idempotent, PUT обрабатывает условия гонки, а PUT позволяет клиенту выбрать URL.

28
ответ дан ishandutta2007 15 окт. '17 в 5:33 2017-10-15 05:33

Рискуя повторить сказанное, важно помнить, что PUT подразумевает, что клиент контролирует, каким образом URL-адрес будет создан, когда создается ресурс. Таким образом, часть выбора между PUT и POST будет заключаться в том, насколько вы можете доверять клиенту для предоставления правильного, нормализованного URL-адреса, которые согласуются с тем,

Если вы не можете полностью доверять клиенту делать правильные вещи, это будет более целесообразно использовать POST для создания нового элемента, а затем отправить URL-адрес обратно клиенту в ответ.

24
ответ дан skillet-thief 25 марта '11 в 13:17 2011-03-25 13:17

Самое важное соображение - надежность. Если сообщение POST потеряно, состояние системы undefined. Автоматическое восстановление невозможно. Для сообщений PUT состояние undefined только до первой успешной попытки.

Например, не может быть хорошей идеей создавать транзакции с кредитными картами с помощью POST.

Если у вас есть автогенерированный URI на вашем ресурсе, вы все равно можете использовать PUT, передав клиенту сгенерированный URI (указывая на пустой ресурс).

Некоторые другие соображения:

  • POST аннулирует кешированные копии всего содержащего ресурса (улучшенная согласованность)
  • Ответы PUT не подлежат кэшированию, тогда как POST - это (Требовать контент-местоположение и срок действия)
  • PUT менее поддерживается, например. Java ME, старые браузеры, брандмауэры.
18
ответ дан Hans Malherbe 08 февр. '12 в 19:31 2012-02-08 19:31

В очень простой форме я беру пример временной шкалы Facebook.

Случай 1: Когда вы публикуете что-то на своей временной шкале, это новая новая запись. Поэтому в этом случае они используют метод POST, потому что метод POST не является идемпотентным.

Случай 2: Если ваш знакомый прокомментирует ваше сообщение в первый раз, это также создаст новую запись в базе данных, чтобы использовать метод POST.

Случай 3: если ваш друг редактирует свой комментарий, в этом случае у них есть идентификатор комментария, поэтому они будут обновлять существующий комментарий вместо создания новой записи в базе данных. Поэтому для этого типа операции используйте метод PUT, потому что он идемпотент. *

В одной строке используйте POST , чтобы добавить новую запись в базу данных и PUT в обновить что-то в базе данных.

18
ответ дан UniCoder 14 февр. '17 в 9:55 2017-02-14 09:55

Кажется, всегда возникает некоторая путаница в том, когда использовать HTTP POST в сравнении с методом HTTP PUT для служб REST. Большинство разработчиков попытаются связать операции CRUD напрямую с методами HTTP. Я буду утверждать, что это неверно, и нельзя просто связать концепции CRUD с методами HTTP. Yəni:

 Create => HTTP PUT Retrieve => HTTP GET Update => HTTP POST Delete => HTTP DELETE 

Верно, что R (etrieve) и D (elete) операций CRUD могут быть сопоставлены непосредственно HTTP-методам GET и DELETE соответственно. Однако путаница заключается в операциях C (reate) и U (update). В некоторых случаях можно использовать PUT для создания, тогда как в других случаях потребуется POST. Неопределенность заключается в определении метода HTTP PUT и метода HTTP POST.

В соответствии с спецификациями HTTP 1.1 методы GET, HEAD, DELETE и PUT должны быть идемпотентными, а метод POST не является идемпотентным. То есть операция является идемпотентной, если она может выполняться на ресурсе один или несколько раз и всегда возвращает одно и то же состояние этого ресурса. В то время как операция без idempotent может возвращать измененное состояние ресурса от одного запроса другому. Следовательно, в не идемпотентной операции нет гарантии, что вы получите одно и то же состояние ресурса.

Основываясь на приведенном выше определении idempotent, я беру на себя использование метода HTTP PUT или используя метод HTTP POST для служб REST: Используйте метод HTTP PUT, когда:

 The client includes all aspect of the resource including the unique identifier to uniquely identify the resource. Example: creating a new employee. The client provides all the information for a resource to be able to modify that resource.This implies that the server side does not update any aspect of the resource (such as an update date). 

В обоих случаях эти операции могут выполняться несколько раз с теми же результатами. То есть ресурс не будет изменен, запросив операцию более одного раза. Следовательно, истинная идемпотентная операция. Используйте метод HTTP POST, когда:

 The server will provide some information concerning the newly created resource. For example, take a logging system. A new entry in the log will most likely have a numbering scheme which is determined on the server side. Upon creating a new log entry, the new sequence number will be determined by the server and not by the client. On a modification of a resource, the server will provide such information as a resource state or an update date. Again in this case not all information was provided by the client and the resource will be changing from one modification request to the next. Hence a non idempotent operation. 

Nəticə

Не напрямую связывать и сопоставлять операции CRUD с методами HTTP для служб REST. Использование метода HTTP PUT в сравнении с методом HTTP POST должно основываться на идемпотентном аспекте этой операции. То есть, если операция идемпотентна, используйте метод HTTP PUT. Если операция не является идемпотентной, используйте метод HTTP POST.

13
ответ дан Burhan 10 окт. '13 в 7:18 2013-10-10 07:18

исходный сервер может создать ресурс с этим URI

Таким образом, вы используете POST и, возможно, но не обязательно PUT для создания ресурса. Вам не нужно поддерживать оба. Для меня POST вполне достаточно. Итак, это дизайнерское решение.

Как упоминалось в вашей цитате, вы используете PUT для создания ресурса, назначенного IRI, и вы все равно хотите создать ресурс. Например, PUT /users/123/password обычно заменяет старый пароль новым, но вы можете использовать его для создания пароля, если он еще не существует (например, только что зарегистрированным пользователям или путем восстановления запрещенных пользователей).

12
ответ дан inf3rno 16 янв. '14 в 10:58 2014-01-16 10:58

Читатели, новые к этой теме, будут поражены бесконечным обсуждением того, что вы должны делать, и относительным отсутствием уроков из опыта. Тот факт, что REST является "предпочтительным" по сравнению с SOAP, я полагаю, высокоуровневое обучение на основе опыта, но доброта, которую мы, должно быть, продвинулись оттуда? Это 2016. Ройская диссертация была в 2000 году. Что мы разработали? Это было весело? Легко ли было интегрироваться? Поддерживать? Будет ли он справляться с ростом смартфонов и взломанными мобильными соединениями?

По мнению ME, реальные сети ненадежны. Требуется тайм-аут. Соединения сбрасываются. Сети работают в течение нескольких часов или дней. Поезда отправляются в туннели с мобильными пользователями на борту. По любому запросу (как это иногда признается во всех этих обсуждениях) запрос может попасть в воду на своем пути, или ответ может упасть в воду на обратном пути. В этих условиях выдача запросов PUT, POST и DELETE непосредственно к основным ресурсам всегда казалась мне немного жестокой и наивной.

HTTP ничего не делает для обеспечения надежного завершения запроса-ответа, и это просто отлично, потому что это должным образом работа приложений, ориентированных на сеть. Разрабатывая такое приложение, вы можете перепрыгнуть через обручи, чтобы использовать PUT вместо POST, а затем больше обручей, чтобы вызывать определенную ошибку на сервере, если обнаруживаете повторяющиеся запросы. Вернувшись к клиенту, вам придется перепрыгнуть через обручи, чтобы интерпретировать эти ошибки, повторить, повторить проверку и повторить.

Или вы можете это сделать : рассмотрите ваши небезопасные запросы как эфемерные однопользовательские ресурсы (позвольте им называть их действия). Клиенты запрашивают новое "действие" на основном ресурсе с пустым POST ресурсом. POST будет использоваться только для этого. После безопасного хранения URI недавно отчеканенного действия клиент выдает небезопасный запрос к URI действия, а не целевой ресурс. Урегулирование действия и обновление "реального" ресурса - это должным образом работа вашего API и здесь отключена от ненадежной сети.

Сервер выполняет бизнес, возвращает ответ и сохраняет его в соответствии с URI согласованного действия. Если что-то пойдет не так, клиент повторяет запрос (естественное поведение!), И если сервер уже видел его, он повторяет сохраненный ответ и ничего не делает.

Вы быстро обнаружите сходство с обещаниями: мы создаем и возвращаем местозаполнитель для результата, прежде чем что-либо делать. Также, как обещание, действие может преуспеть или сработать один раз, но его результат может быть получен повторно.

Лучше всего, мы даем возможность отправлять и получать приложения, чтобы связать уникально идентифицированное действие с уникальностью в их соответствующих средах. И мы можем начать требовать и обеспечивать соблюдение !, ответственное поведение клиентов: повторяйте свои запросы так, как вам нравится, но не начинайте генерировать новое действие, пока не получите окончательный результат от существующего.

Таким образом, многочисленные тернистые проблемы уходят. Повторные запросы вставки не будут создавать дубликаты, и мы не создадим реальный ресурс, пока не получим данные. (столбцы базы данных могут оставаться недействительными). Повторные запросы на обновление не будут попадать в несовместимые состояния и не будут перезаписывать последующие изменения. Клиенты могут (повторно) получать и беспрепятственно обрабатывать исходное подтверждение по любой причине (клиент потерпел крах, ответ пропал без вести и т.д.).

Последовательные запросы на удаление могут видеть и обрабатывать исходное подтверждение без ошибки 404. Если что-то происходит дольше, чем ожидалось, мы можем отреагировать временно, и у нас есть место, где клиент может проверить окончательный результат. Наилучшей частью этого шаблона является его свойство Kung-Fu (Panda). Мы принимаем слабость, склонность клиентов повторять запрос в любое время, когда они не понимают ответ, и превращают его в силу :-)

Прежде чем сказать мне, что это не RESTful, рассмотрите многочисленные способы уважения принципов REST. Клиенты не создают URL-адреса. API остается доступным, хотя и с небольшим изменением в семантике. HTTP-глаголы используются соответствующим образом. Если вы считаете, что это огромное изменение для реализации, я могу сказать вам по опыту, что это не так.

Если вы считаете, что у вас будет огромное количество данных для хранения, позвольте говорить томам: типичное подтверждение обновления составляет часть килобайта. HTTP в настоящее время дает вам минуту или две, чтобы ответить окончательно. Даже если вы только сохраняете действия в течение недели, у клиентов есть достаточный шанс догнать. Если у вас очень большие объемы, вам может потребоваться специализированное хранилище значений ключа, соответствующее кислотам, или решение в памяти.

12
ответ дан bbsimonbb 18 февр. '16 в 14:45 2016-02-18 14:45

Я собираюсь приземлиться со следующим:

PUT относится к ресурсу, идентифицированному URI. В этом случае вы обновляете его. Это часть трех глаголов, ссылающихся на ресурсы - удаляйте и становитесь двумя другими.

POST - это в основном сообщение о свободной форме, причем его значение определяется как "вне диапазона". Если сообщение можно интерпретировать как добавление ресурса в каталог, это будет нормально, но в основном вам нужно понять отправляемое сообщение (публикацию), чтобы узнать, что произойдет с ресурсом.


Поскольку PUT и GET и DELETE относятся к ресурсу, они также по определению идемпотент.

POST может выполнять другие три функции, но тогда семантика запроса будет потеряна для посредников, таких как кеши и прокси. Это также относится к обеспечению безопасности ресурса, поскольку почтовый URI необязательно указывает ресурс, к которому он применяется (может, хотя).

A PUT не нужно создавать; служба может ошибиться, если ресурс еще не создан, но в противном случае его обновит. Или наоборот - он может создать ресурс, но не разрешать обновления. Единственное, что требуется для PUT, это указание на определенный ресурс, а его полезная нагрузка - это представление этого ресурса. Успешный PUT означает (запрет помех), что GET будет извлекать один и тот же ресурс.


Изменить: Еще одна вещь - PUT может создавать, но если это так, то идентификатор должен быть естественным ID - AKA адресом электронной почты. Таким образом, когда вы дважды вставляете, второй ставит обновление первого. Это делает его идемпотентным.

Если идентификатор сгенерирован (например, новый идентификатор сотрудника), то второй PUT с тем же URL-адресом создаст новую запись, которая нарушает правило idempotent. В этом случае глагол будет POST, а сообщение (а не ресурс) будет состоять в создании ресурса с использованием значений, определенных в этом сообщении.

10
ответ дан Gerard ONeill 22 окт. '13 в 0:16 2013-10-22 00:16

Предполагается, что семантика различна, поскольку "PUT", например "GET", должен быть идемпотентным, то есть вы можете иметь один и тот же точный запрос PUT несколько раз, и результат будет таким, как если бы вы выполнили его только один раз,

Я опишу соглашения, которые, по моему мнению, наиболее широко используются и являются наиболее полезными:

При запуске ресурса по определенному URL-адресу происходит то, что он должен быть сохранен на этом URL-адресе или что-то в этом роде.

Когда вы отправляете POST на ресурс по определенному URL-адресу, вы часто отправляете связанный фрагмент информации на этот URL-адрес. Это означает, что ресурс по URL уже существует.

Например, если вы хотите создать новый поток, вы можете нажать его на некоторый URL. Но когда вы хотите отправить сообщение POST в существующий поток, вы отправляете POST по его URL-адресу.

Что касается модификации свойств потока, вы можете сделать это с помощью PUT или POST. В принципе, используйте только "PUT", когда операция идемпотентна, иначе используйте POST.

Обратите внимание, однако, что не все современные браузеры поддерживают HTTP-глаголы, отличные от GET или POST.

8
ответ дан Gregory Magarshak 23 окт. '11 в 23:07 2011-10-23 23:07

Несмотря на то, что, возможно, существует агностический способ их описания, он, похоже, противоречит различным утверждениям от @ на веб-сайты.

Позвольте быть предельно ясным и прямым здесь. Если вы являетесь разработчиком .NET, работающим с веб-API, факты (из документации Microsoft API), http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web-api-that-supports-crud-operations :

 1. PUT = UPDATE (/api/products/id) 2. MCSD Exams 2014 - UPDATE = PUT, there are **NO** multiple answers for that question period. 

Уверен, что вы "можете" использовать "POST" для обновления, но просто следуйте соглашениям, изложенным для вас с вашей картой. В моем случае это .NET/Web API, поэтому PUT для UPDATE нет дискуссий.

Я надеюсь, что это поможет любым разработчикам Microsoft, которые читают все комментарии с ссылками на Amazon и Sun/Java.

7
ответ дан Tom Stickel 21 июля '14 в 23:02 2014-07-21 23:02

В большинстве случаев вы будете использовать их следующим образом:

  • POST ресурс в коллекцию
  • PUT ресурс, идентифицированный с помощью коллекции /: id

Məsələn:

  • POST /items
  • PUT /items/1234

В обоих случаях тело запроса содержит данные для создаваемого или обновляемого ресурса. Из названий маршрутов должно быть очевидно, что POST не является идемпотентным (если вы вызываете его 3 раза, он будет создавать 3 объекта), но PUT является идемпотентным (если вы его назовете 3 раза, то результат будет таким же). PUT часто используется для операции "upsert" (создание или обновление), но вы всегда можете вернуть ошибку 404, если хотите использовать ее только для изменения.

Обратите внимание, что POST "создает" новый элемент в коллекции, а PUT "заменяет" элемент по заданному URL-адресу, но очень часто используется PUT для частичных модификаций, то есть использовать его только для обновления существующие ресурсы и только модифицировать включенные поля в теле (игнорируя другие поля). Это технически некорректно, если вы хотите быть REST-пуристом, PUT должен заменить весь ресурс, и вы должны использовать PATCH для частичного обновления. Мне лично все равно, насколько поведение ясное и последовательное во всех ваших конечных точках API.

Помните, что REST - это набор конвенций и рекомендаций, которые упрощают ваш API. Если вы закончите сложную работу, чтобы проверить поле "RESTfull", вы побеждаете цель;)

7
ответ дан tothemario 21 июня '17 в 20:38 2017-06-21 20:38

Если вы знакомы с операциями с базой данных, есть

  • Выберите
  • Вставить
  • Yeniləmə
  • Удалить
  • Объединить (обновить, если он уже существует, иначе вставить)

Я использую PUT для Merge и обновляю подобные операции и использую POST для Insertions.

6
ответ дан Rajan 30 июня '16 в 0:13 2016-06-30 00:13

Здесь простое правило:

PUT URL-адрес должен использоваться для обновления или создания ресурса, который может быть расположен по этому URL-адресу.

POST URL-адрес должен использоваться для обновления или создания ресурса, который находится на каком-то другом ( "подчиненном" ) URL-адресе, или не доступен для поиска через HTTP.

5
ответ дан Adam Griffiths 12 дек. '13 в 1:15 2013-12-12 01:15

На практике POST хорошо работает для создания ресурсов. URL-адрес вновь созданного ресурса должен быть возвращен в заголовке ответа местоположения. PUT должен использоваться для полного обновления ресурса. Пожалуйста, поймите, что это лучшие практики при разработке RESTful API. Спецификация HTTP как таковая не ограничивает использование PUT/POST несколькими ограничениями для создания/обновления ресурсов. Взгляните на http://techoctave.com/c7/posts/71-twitter-rest-api-dissected , в котором приведены лучшие примеры.

5
ответ дан java_geek 06 окт. '14 в 9:51 2014-10-06 09:51

В дополнение к различиям, предложенным другими, я хочу добавить еще один.

В методе POST вы можете отправлять параметры тела в form-data

В методе PUT вам необходимо отправить параметры тела в x-www-form-urlencoded

Заголовок Content-Type:application/x-www-form-urlencoded

В соответствии с этим вы не можете отправлять файлы или multipart данные в методе PUT

EDIT

Тип контента "application/x-www-form-urlencoded" неэффективен для отправки больших количеств двоичных данных или текста, содержащих символы, отличные от ASCII. Тип контента "multipart/form-data" должен использоваться для отправки форм, содержащих файлы, данные, отличные от ASCII, и двоичные данные.

Это означает, что вам нужно подать

файлы, данные, отличные от ASCII, и двоичные данные

вы должны использовать метод POST

4
ответ дан Rohit Dhiman 25 сент. '18 в 11:28 2018-09-25 11:28
  • 1
  • 2

Другие вопросы по меткам или Задайте вопрос