PUT vs POST – ero niiden välillä

Tärkeimmät erot PUT:n ja POSTin välillä

  • PUT-menetelmää kutsutaan, kun sinun on muokattava yhtä resurssia, kun taas POST-menetelmää kutsutaan, kun sinun on lisättävä aliresurssi.
  • POST-menetelmän vastaukset voidaan tallentaa välimuistiin, mutta et voi tallentaa PUT-menetelmän vastauksia välimuistiin.
  • Voit käyttää UPDATE-kyselyä PUT:ssa, kun taas voit käyttää luomiskyselyä POSTissa.
  • PUT-menetelmässä asiakas päättää, mikä URI-resurssi pitäisi olla, ja POST-menetelmässä palvelin päättää, mikä URI-resurssi tulee olla.
  • PUT toimii erityisenä, kun taas POST toimii abstraktina.
  • Jos lähetät saman PUT-pyynnön useita kertoja, tulos pysyy samana, mutta jos lähetät saman POST-pyynnön useita kertoja, saat erilaiset tulokset.
  • PUT-menetelmä on idempotentti, kun taas POST-menetelmä ei ole idempotentti.
PUT vs POST
PUT vs POST

Mikä on PUT-menetelmä?

PUT-menetelmää käytetään palvelimella olevien resurssien päivittämiseen. Yleensä se korvaa kohde-URL-osoitteessa olevan sisällön jollain muulla. Voit käyttää sitä uuden resurssin luomiseen tai olemassa olevan resurssin päälle. PUT pyytää, että suljettu entiteetti on tallennettava toimitetun pyydetyn URI:n (Uniform Resource Identifier) ​​alle.

Mikä on POST-menetelmä?

POST on menetelmä, jota tukevat HTTP ja

kuvaa, että web-palvelin hyväksyy pyydetyn viestin runkoon sisältyvät tiedot. World Wide Web käyttää usein POST-testiä lähettämään käyttäjien luomia tietoja verkkopalvelimelle tai kun lataat tiedoston.

Erot PUT:n ja POSTin välillä REST-sovellusliittymissä

Tässä on tärkeä ero PUT- ja POST-menetelmän välillä:

PUT POST
Tämä menetelmä on idempotentti. Tämä menetelmä ei ole idempotentti.
PUT-menetelmä on kutsu, kun joudut muokkaamaan yksittäistä resurssia, joka on jo osa resurssien keräämistä. POST-menetelmä on kutsu, kun sinun on lisättävä aliresurssi resurssien keräämiseen.
RFC-2616 kuvaa, että PUT-menetelmä lähettää pyynnön suljetulle entiteetille, joka on tallennettu toimitettuun pyyntö-URI:hen. Tämä menetelmä pyytää palvelinta hyväksymään pyyntöön sisältyvän entiteetin.
PUT-metodin syntaksi on PUT /questions/{question-id} POST-menetelmän syntaksi on POST /questions
Et voi tallentaa PUT-menetelmän vastauksia välimuistiin. POST-menetelmän vastaus voidaan tallentaa välimuistiin.
PUT /vi/juice/orders/1234 osoittaa, että olet päivittämässä resurssia, jonka tunniste on "1234". POST /vi/juice/orders osoittaa, että olet luomassa uutta resurssia ja palautat resurssia kuvaavan tunnisteen.
Jos lähetät saman pyynnön useita kertoja, tulos pysyy samana. Jos lähetät saman POST-pyynnön useammin kuin kerran, saat erilaiset tulokset.
PUT toimii spesifisesti. POST-työ abstraktina.
Käytämme UPDATE-kyselyä PUT:ssa. Käytämme luontikyselyä POSTissa.
PUT-menetelmässä asiakas päättää, minkä URI-resurssin tulee olla. POST-menetelmässä palvelin päättää, mikä URI-resurssi pitäisi olla.

Esimerkki PUT:sta

Tässä on verkkopalvelinesimerkki PUT-menetelmästä:

HTTP PUT http://www.google.com/users/234

HTTP PUT http://www.google.com/users/234/accounts/567

Pyydä

PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 20

<p>New File</p>

Vastaukset

Jos kohderesurssi, jolla on nykyinen esitys ja jota muutetaan suljetun esityksen tilassa, palvelimen tulee lähettää kaksi vastausta. Ensimmäinen vastauskoodi on 200 (OK) ja toinen vastauskoodi on 204 (ei sisältöä).

Jos kohderesurssilla ei ole esitystä, palvelimen tulee ilmoittaa siitä käyttäjälle lähettämällä 201-koodi (Luotu) vastaus.

 HTTP/1.1 201 Created
Content-Location: /new.html

Esimerkki POST:sta

Tässä on esimerkki POST-menetelmästä:

HTTP POST http://www.google.com/users

HTTP POST http://www.google.com/users/234/accounts

Lomake, joka käyttää oletussovellus-/x-www-lomake-urlencoded-sisältötyyppiä:

POST /test HTTP/1.1
Host: abc.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 40

field1=value1&field2=value2

API:n testaus PUT-pyynnöillä

Tässä ovat vaiheet API:n testaamiseen PUT-pyynnöillä:

API:n testaus PUT-pyynnöillä
API:n testaus PUT-pyynnöillä

Vaihe 1) Päivitä resurssit PUT-pyynnöllä.

Vaihe 2) Käytä resurssina GET-menetelmää. Jos PUT-pyyntö onnistuu, saat uusia tietoja. Tämä menetelmä epäonnistuu, jos pyynnössä annetut tiedot ovat virheellisiä. Siksi se ei päivitä mitään.

API:n testaus POST-pyynnöillä

Tässä ovat vaiheet API:n testaamiseksi POST-pyynnöillä:

API:n testaus POST-pyynnöillä

API:n testaus POST-pyynnöillä

Vaihe 1) Luo resurssi POST-pyynnöllä ja varmista, että se palauttaa 200 tilakoodin.

Vaihe 2) Tee GET-pyyntö kyseiselle resurssille ja tallenna tiedot oikeassa muodossa.

Vaihe 3) Sinun on lisättävä testejä, jotka varmistavat, että POST-pyynnöt epäonnistuvat virheellisillä tiedoilla.

PUT-menetelmän edut

Tässä on PUT-menetelmän käytön edut/edut:

  • Se auttaa sinua tallentamaan toimitetun entiteetin toimitetun URI:n alle
  • Jos toimitettu entiteetti on jo olemassa, voit suorittaa päivitystoiminnon tai luoda sen URI:n avulla.
  • Voit luoda resurssin niin monta kertaa kuin haluat.
  • Resurssin luominen PUT-menetelmällä on erittäin helppoa.
  • Sinun ei tarvitse tarkistaa, onko käyttäjä napsauttanut lähetä-painiketta useita kertoja vai ei.
  • Se voi tunnistaa pyynnön mukana olevan entiteetin.

POST-menetelmän edut

Tässä on POST-menetelmän käytön edut/edut:

  • Tämä menetelmä auttaa sinua määrittämään resurssin URI:n.
  • Uuden resurssin sijainnin otsikon määrittäminen on erittäin helppoa sijaintiotsikon avulla.
  • Voit lähettää pyynnön hyväksyä entiteetti URI:n tunnistaman resurssin uudeksi alisteeksi.
  • Voit lähettää käyttäjien luomia tietoja verkkopalvelimelle.
  • Se on erittäin hyödyllinen, kun et tiedä URL-osoitetta säilyttääksesi mitään resurssia.
  • Käytä POST-testiä, kun tarvitset palvelinta, joka ohjaa resurssien URL-osoitetta.
  • POST on turvallinen menetelmä, koska sen pyynnöt eivät jää selainhistoriaan.
  • Voit siirtää vaivattomasti suuren datamäärän postin avulla.
  • Voit pitää tiedot yksityisinä.
  • Tätä menetelmää voidaan käyttää sekä binääri- että ASCII-tietojen lähettämiseen.