Tämä viesti on vastaus kysymykseen, joka esitettiin yhden artikkelini kommentissa.
Tässä artikkelissa haluan kertoa sinulle, mitä HTTP-menetelmät GET/POST/PUT/DELETE ja muut ovat, miksi ne keksittiin ja kuinka niitä käytetään REST:n mukaisesti.
HTTP
Joten mikä on yksi Internetin tärkeimmistä protokollista? Lähetän pedantit RFC2616:een ja loput kerron inhimillisesti :)Tämä protokolla kuvaa kahden tietokoneen (asiakas ja palvelin) välistä vuorovaikutusta, joka on rakennettu pyyntö (Request) ja vastaus (Response) sanomien perusteella. Jokainen viesti koostuu kolmesta osasta: aloitusviivasta, otsikoista ja rungosta. Tässä tapauksessa tarvitaan vain lähtöviiva.
Pyynnön ja vastauksen aloitusrivit ovat eri muodoissa - meitä kiinnostaa vain pyynnön aloitusrivi, joka näyttää tältä:
MENETELMÄ URI HTTP/ VERSIO ,
Jos METHOD on HTTP-pyyntömenetelmä, URI on resurssin tunniste, VERSION on protokollaversio (nykyinen versio 1.1).
Otsikot ovat kokoelma nimi-arvo-pareja, jotka on erotettu kaksoispisteellä. Otsikoissa välitetään erilaisia palvelutietoja: viestin koodaus, selaimen nimi ja versio, osoite, josta asiakas tuli (Referrer) ja niin edelleen.
Viestin runko on todellista lähetettävää dataa. Vastauksessa lähetettävä data on pääsääntöisesti selain pyytämä HTML-sivu ja pyynnössä esimerkiksi viestin rungossa välitetään palvelimelle ladattujen tiedostojen sisältö. Mutta pääsääntöisesti pyynnössä ei ole viestitekstiä ollenkaan.
Esimerkki HTTP-vuorovaikutuksesta
Katsotaanpa esimerkkiä.Pyytää:
GET /index.php HTTP/1.1 Isäntä: example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Hyväksy: text/html Yhteys: sulje
Ensimmäinen rivi on kyselyrivi, loput ovat otsikoita; viestin runko puuttuu
Vastaus:
HTTP/1.0 200 OK Palvelin: nginx/0.6.31 Sisältö-kieli: ru Sisältötyyppi: text/html; charset=utf-8 Content-Length: 1234 Yhteys: sulje ... HTML-SIVU ITSE...
Resurssit ja menetelmät
Palataan pyynnön aloitusriville ja muistetaan, että se sisältää sellaisen parametrin kuin URI. Tämä tulee sanoista Uniform Resource Identifier - yhtenäinen resurssitunniste. Resurssi on pääsääntöisesti palvelimella oleva tiedosto (esimerkki-URI tässä tapauksessa on “/styles.css”), mutta yleensä resurssi voi olla myös jokin abstrakti objekti (“/blogs/webdev/” - pisteet "Web"-lohkon kehittämiseen" eikä tiettyyn tiedostoon).HTTP-pyyntötyyppi (kutsutaan myös HTTP-menetelmäksi) kertoo palvelimelle, mitä toimintoa haluamme suorittaa resurssille. Aluksi (90-luvun alussa) oletettiin, että asiakas voi haluta resurssilta vain yhtä asiaa - vastaanottaa sen, mutta nyt HTTP-protokollan avulla voit luoda viestejä, muokata profiilia, poistaa viestejä ja paljon muuta. Ja näitä toimia on vaikea yhdistää termiin "kuitti".
Toimintojen erottamiseksi resursseista HTTP-menetelmien tasolla keksittiin seuraavat vaihtoehdot:
- HANKI - resurssin hankkiminen
- POST - resurssien luominen
- PUT - resurssien päivitys
- DELETE - resurssin poisto
REST tulee peliin
REST (REpresentational State Transfer) on termi, jonka Roy Fielding, yksi HTTP-protokollan kehittäjistä, otti vuonna 2000 käyttöön verkkosovellusten rakentamisen periaateryhmän nimeksi. Yleensä REST kattaa laajemman alueen kuin HTTP - sitä voidaan käyttää myös muissa verkoissa muilla protokollilla. REST kuvaa asiakkaan ja palvelimen välisen vuorovaikutuksen periaatteita, jotka perustuvat käsitteisiin "resurssi" ja "verbi" (voidaan ymmärtää subjektina ja predikaattina). HTTP:n tapauksessa resurssi tunnistetaan sen URI:n perusteella, ja verbi on HTTP-menetelmä.REST ehdottaa luopumista saman URI:n käytöstä eri resursseille (eli kahden eri artikkelin osoitteet, kuten /index.php?article_id=10 ja /index.php?article_id=20 - tämä ei ole REST-tapa) ja käyttämällä erilaisia HTTP-menetelmiä eri toimiin. Eli REST-lähestymistavalla kirjoitettu verkkosovellus poistaa resurssin, kun sitä käytetään HTTP DELETE -menetelmällä (tämä ei tietenkään tarkoita, että on tarpeen antaa mahdollisuus poistaa kaikki ja kaikki, mutta mikä tahansa sovelluksen poistopyynnön on käytettävä HTTP DELETE -menetelmää).
REST antaa ohjelmoijille mahdollisuuden kirjoittaa standardoituja ja hieman kauniimpia web-sovelluksia kuin ennen. Käyttämällä RESTiä URI uuden käyttäjän lisäämiseen ei ole /user.php?action=create (GET/POST-menetelmä), vaan yksinkertaisesti /user.php (tarkka POST-menetelmä).
Tämän seurauksena yhdistämällä olemassa oleva HTTP-spesifikaatio ja REST-lähestymistapa, erilaiset HTTP-menetelmät ovat lopulta järkeviä. GET - palauttaa resurssin, POST - luo uuden, PUT - päivittää olemassa olevan, DELETE - poistaa sen.
Ongelmia?
Kyllä, RESTin käytössä on pieni ongelma käytännössä. Tätä ongelmaa kutsutaan HTML:ksi.PUT/DELETE-pyynnöt voidaan lähettää XMLHttpRequestillä, ottamalla yhteyttä palvelimeen manuaalisesti (esim. curlin tai vaikka telnetin kautta), mutta et voi tehdä HTML-lomaketta, joka lähettää täysimittaisen PUT/DELETE-pyynnön.
Asia on siinä, että HTML-määritys ei salli sinun luoda lomakkeita, jotka lähettävät tietoja muuten kuin GET- tai POST-protokollan kautta. Siksi, jotta voit työskennellä normaalisti muiden menetelmien kanssa, sinun on matkittava niitä keinotekoisesti. Esimerkiksi Rackissa (mekanismi, jonka perusteella Ruby on vuorovaikutuksessa verkkopalvelimen kanssa; Rails, Merb ja muut Ruby-kehykset tehdään Rackilla) voit lisätä lomakkeeseen piilotetun kentän nimellä "_method" ja määritä arvoksi menetelmän nimi (esim. "PUT") - tässä tapauksessa POST-pyyntö lähetetään, mutta Rack voi teeskennellä, että se sai PUT:n POSTin sijaan.
Kaikki Web-teknologian tiedot välitetään protokollan kautta HTTP. Poikkeuksena on Java-ohjelmointia käyttävä vaihto tai vaihto Plugin-sovelluksista. Ottaen huomioon todellisen liikenteen määrän, joka siirretään osana Web-vaihtoa HTTP:n kautta, otamme huomioon vain tämän protokollan. Tässä yhteydessä keskitymme seuraaviin asioihin:
- yleinen viestin rakenne;
- pääsytavat;
- vaihtojen optimointi.
Yleinen viestin rakenne
HTTP on sovelluskerroksen protokolla. Se keskittyy asiakas-palvelin-vaihtomalliin. Asiakas ja palvelin vaihtavat tietoja, joita kutsutaan HTTP-viesteiksi. Asiakkaan palvelimelle lähettämiä viestejä kutsutaan pyynnöiksi ja palvelimen asiakkaalle lähettämiä viestejä vastauksiksi. Viesti voi koostua kahdesta osasta: otsikosta ja tekstistä. Runko on erotettu otsikosta tyhjällä rivillä.
Otsikko sisältää palveluinformaatiota, jota tarvitaan sanoman rungon käsittelyyn tai vaihdon ohjaamiseen. Otsikko koostuu otsikkokäskyistä, jotka yleensä kirjoitetaan kukin uudelle riville.
Viestin runko on valinnainen, mutta viestin otsikko on. Se voi sisältää tekstiä, grafiikkaa, ääni- tai videotietoja.
Alla on HTTP-pyyntö:
GET / HTTP/1.0 Hyväksy: image/jpeg tyhjä merkkijono
Ja vastaus:
HTTP/1.0 200 OK Päivämäärä: pe, 24. heinäkuuta 1998 21:30:51 GMT Palvelin: Apache/1.2.5 Sisältötyyppi: text/html Sisällön pituus: 21345 tyhjä merkkijono ...
Teksti "tyhjä rivi" tarkoittaa yksinkertaisesti tyhjän rivin olemassaoloa, joka erottaa HTTP-viestin otsikon sen tekstistä.
Kun palvelin vastaanottaa pyynnön asiakkaalta, se muuntaa osan HTTP-pyynnön otsikkotiedoista ympäristömuuttujiksi, jotka ovat CGI-komentosarjan analysoitavissa. Jos pyynnöllä on runko, se tulee komentosarjan saataville tavallisen syöttövirran kautta.
Pääsymenetelmät
HTTP-pyynnön tärkein ohje on pääsytapa. Se ilmoitetaan ensimmäisenä sanana kyselyn ensimmäisellä rivillä. Esimerkissämme tämä on GET. Pääsymenetelmiä on neljä:
- PÄÄ;
- LÄHETTÄÄ;
Näiden neljän menetelmän lisäksi käytössä on noin viisi muuta pääsytapaa, mutta niitä käytetään harvoin.
GET-menetelmä
Asiakas käyttää GET-menetelmää tehdessään pyynnön palvelimelle oletuksena. Tässä tapauksessa asiakas ilmoittaa resurssiosoitteen (URL), jonka se haluaa vastaanottaa, HTTP-protokollan version, tukemat MIME-asiakirjatyypit sekä asiakasohjelmiston version ja nimen. Kaikki nämä parametrit on määritetty HTTP-pyynnön otsikossa. Kehoa ei lähetetä pyynnössä.
Palvelin raportoi vastauksena HTTP-protokollan version, palautuskoodin, viestin runkosisällön tyypin, viestin rungon koon ja joukon muita valinnaisia HTTP-otsikkokäskyjä. Itse resurssi, yleensä HTML-sivu, lähetetään vastauksen tekstiosassa.
PÄÄ menetelmä
HEAD-menetelmää käytetään vähentämään vaihtoa HTTP-protokollan yli työskennellessä. Se on samanlainen kuin GET-menetelmä, paitsi että viestin runkoa ei lähetetä vastauksessa. Tätä menetelmää käytetään tarkistamaan resurssin viimeinen muokkausaika ja välimuistissa olevien resurssien vanhenemispäivä sekä käytettäessä World Wide Web -resurssien tarkistusohjelmia. Lyhyesti sanottuna HEAD-menetelmä on suunniteltu vähentämään verkon yli osana HTTP-vaihtoa siirrettävän tiedon määrää.
POST-menetelmä
POST-menetelmä on vaihtoehto GET-menetelmälle. Kun tietoja vaihdetaan POST-menetelmällä, asiakaspyyntö sisältää HTTP-sanoman rungon. Tämä runko voidaan muodostaa HTML-lomakkeella syötetyistä tiedoista tai liitteenä olevasta ulkoisesta tiedostosta. Vastaus sisältää tyypillisesti sekä HTTP-viestin otsikon että rungon. Jos haluat aloittaa vaihdon POST-menetelmällä, FORM-säilön METHOD-attribuutiksi on asetettava "post".
PUT-menetelmä
PUT-menetelmää käytetään HTML-sivujen julkaisemiseen HTTP-palvelimen hakemistoon. Kun dataa siirretään asiakkaalta palvelimelle, viesti sisältää sekä viestin otsikon, joka osoittaa resurssin URL-osoitteen, että rungon - isännöidyn resurssin sisällön.
Vastaus ei yleensä lähetä resurssin runkoa, vaan viestin otsikko sisältää palautuskoodin, joka määrittää, oliko resurssien allokointi onnistunut vai epäonnistunut.
Exchangen optimointi
HTTP-protokollaa ei alun perin suunniteltu pysyville yhteyksille. Tämä tarkoittaa, että kun palvelin on hyväksynyt asiakkaan pyynnön ja vastannut siihen, yhteys asiakkaan ja palvelimen välillä katkeaa. Uutta tiedonvaihtoa varten on muodostettava uusi yhteys. Tällä lähestymistavalla on sekä etuja että haittoja.
Etuna on mahdollisuus palvella samanaikaisesti useita lyhyitä pyyntöjä. Jopa suosituilla palvelimilla avointen yhteyksien määrä ei saa ylittää satoja, kun palvellaan noin miljoonaa pyyntöä päivässä. Lisäksi yksi asiakas voi avata jopa 40 yhteyttä samanaikaisesti, ja palvelimen näkökulmasta ne ovat kaikki samanarvoisia. Nopeilla viestintälinjoilla tämä mahdollistaa lyhyen vasteajan asiakkaan pyynnöstä koko sivulle (teksti, grafiikka jne.).
Tämän vaihtojärjestelmän haittoja ovat: tarve muodostaa yhteys joka kerta ja kyvyttömyys ylläpitää istuntoa työskennellä tietoresurssin kanssa. Kun alustetaan yhteyttä TCP-siirtoprotokollan kautta ja tämä yhteys katkaistaan, on siirrettävä melko suuri määrä palveluinformaatiota. HTTP:n istunnon tuen puute vaikeuttaa resurssien, kuten tietokantojen tai todennusta vaativien resurssien, kanssa työskentelyä.
Avointen TCP-yhteyksien määrän optimoimiseksi HTTP-protokollan versiot 1.0 ja 1.1 tarjoavat säilytystilan. Tässä tilassa yhteys alustetaan vain kerran ja sen yli voidaan suorittaa useita HTTP-vaihtoja peräkkäin.
Istuntotuen tarjoamiseksi HTTP-otsikkosääntöihin on lisätty evästeitä. Niiden avulla voit simuloida yhteystukea, kun työskentelet HTTP-protokollan yli.
Verkkoteknologian käyttöliittymätyypit
World Wide Web -sivut voidaan jakaa useisiin tyyppeihin niiden toiminnallisen tarkoituksen mukaan: tietosivut, navigointisivut, tiedonvaihtosivut. Monissa tapauksissa nämä toiminnot voidaan yhdistää yhdelle sivulle.
Tietosivut ovat peräkkäinen tiedon esitys, jossa on mahdollisuus hypertekstin kontekstuaalisiin siirtymiin. Käyttäjä katselee niitä peräkkäin. Hypertekstilinkkejä käytetään yleensä luomaan alaviitteitä, huomautuksia tai viittauksia lähdeluetteloihin ja muihin niihin liittyviin materiaaleihin. Tyypillisiä esimerkkejä tällaisista sivuista ovat vinkit, oppaat, yrityskuvaukset, historialliset tiedot jne.
Navigointisivut ovat kokoelma hypertekstilinkkejä, joiden avulla voit selata Web-sivuston materiaaleja. Tyypillinen esimerkki tällaisesta sivusta on Kotisivu. Pääsääntöisesti se ei sisällä pitkiä tekstikuvauksia ja kuvituksia, se koostuu kokoelmasta erilaisia valikoita. Nämä valikot voidaan toteuttaa luetteloiden, linkkitaulukoiden tai kuvakarttojen avulla.
Tiedonvaihtosivuilla voit siirtää palvelimelle tietyn määrän tietoa, joka poikkeaa resurssin vakioosoitteesta (URL). Selatessaan ja navigoidessaan käyttäjä valitsee vain hypertekstilinkkejä, jotka lataavat uusia sivuja. Tietoja vaihdettaessa palvelimelle ei välitetä vain resurssin osoitetta, vaan myös käyttäjän syöttämiä lisätietoja.
Sivujen toiminnallisesta tarkoituksesta riippuen käyttäjän käsittelemän resurssirajapinnan ulkonäkö muuttuu. Kahdessa ensimmäisessä tapauksessa valitse hypertekstilinkki hiirellä ja uusi sivu latautuu välittömästi. Tiedonvaihtosivujen tapauksessa sinun on täytettävä HTML-lomakkeen kentät ja lähetettävä tiedot palvelimelle.
Lisäksi lomakkeet tarjoavat lähes kaikki tarvittavat syöttökentät ja valikot. Ainoa asia, jota HTML-lomakkeet eivät salli, ovat sisäkkäiset valikot. Lomakkeita voidaan käyttää muuhunkin kuin tiedonvaihtoon. JavaScriptissä on melko kehittyneitä lomakkeiden käsittelymekanismeja.
Hypertext Transfer Protocol (HTTP) on Internetin elämän perusta. Sitä käytetään aina, kun asiakirja lähetetään tai AJAX-pyynnössä. Mutta HTTP on yllättävän vähän tunnettu joillekin web-kehittäjille.
Tässä johdannossa tutkimme HTTP:n taustalla olevia REST-suunnitteluperiaatteita ja niiden voiman hyödyntämistä rajapintojen luomiseen, jotka voidaan suorittaa käytännössä miltä tahansa laitteelta tai käyttöjärjestelmältä.
Uudelleenjulkaistu oppitunti
Muutaman viikon välein käymme uudelleen joissakin lukijoidemme suosikkiviesteissä sivuston historiasta. Tämä oppitunti julkaistiin ensimmäisen kerran marraskuussa 2010.
Miksi REST?
REST on yksinkertainen tapa organisoida vuorovaikutus itsenäisten järjestelmien välillä.
REST on yksinkertainen tapa organisoida vuorovaikutus itsenäisten järjestelmien välillä. Se on ollut suosittu vuodesta 2005 ja inspiroi palveluiden, kuten Twitter API:n, suunnittelua. Koska REST mahdollistaa vuorovaikutuksen niinkin monipuolisten asiakkaiden kanssa kuin matkapuhelimet ja muut verkkosivut. Teoriassa REST ei ole web-pohjainen, mutta se on melkein aina toteutettu sellaisenaan ja se on saanut inspiraationsa HTTP:stä. Tämän seurauksena REST:tä voidaan käyttää kaikkialla, missä HTTP on mahdollista.
Vaihtoehtona on rakentaa suhteellisen monimutkaisia käytäntöjä HTTP:n päälle. Tämä tapahtuu usein uusien XML-kielien muodossa. Silmiinpistävin esimerkki on SOAP. Sinun on opittava kokonaan uudet käytännöt, mutta et koskaan käytä HTTP:tä täysimääräisesti. Koska REST on saanut inspiraationsa HTTP:stä ja käyttää sen vahvuuksia, se on paras tapa oppia kuinka HTTP toimii.
Ensimmäisen yleiskatsauksen jälkeen tarkastelemme kaikkia HTTP:n rakennuspalikoita: URL-osoitteita, HTTP-komentoja ja vastauskoodeja. Katsomme myös, kuinka niitä käytetään RESTfulissa. Matkan varrella havainnollistamme teoriaa esimerkkisovelluksella, joka simuloi yrityksen asiakkaisiin liittyvien tietojen seurantaprosessia verkkoliittymän kautta.
HTTP
HTTP on protokolla, jonka avulla voit lähettää asiakirjoja Internetissä.
HTTP on protokolla, jonka avulla voit lähettää asiakirjoja Internetissä. Protokolla on joukko sääntöjä, jotka määrittävät, mitä viestejä voidaan vaihtaa ja mitkä viestit ovat sopivia vastauksia muille. Toinen yleinen protokolla on POP3, jota voit käyttää sähköpostin hakemiseen kiintolevyltäsi.
HTTP:ssä on kaksi eri roolia: palvelin ja asiakas. Yleensä asiakas aloittaa keskustelun aina; palvelin vastaa. HTTP on tekstipohjainen; eli viestit ovat olennaisesti tekstinpätkiä, vaikka viestin runko voi sisältää myös muuta mediaa. Tekstin avulla on helppo seurata HTTP-liikennettä.
HTTP-viestit koostuvat otsikosta ja tekstistä. Ruumis voi usein jäädä tyhjäksi; se sisältää tietoja, jotka haluat siirtää verkon yli, jotta sitä voidaan käyttää otsikon ohjeiden mukaisesti. Otsikko sisältää metatietoja, kuten koodaustietoja; mutta pyynnön tapauksessa se sisältää myös tärkeitä HTTP-menetelmiä. REST-tyylissä huomaat, että otsikkotiedot ovat usein merkityksellisempiä kuin runkotiedot.
HTTP-vakoilu töissä
Jos käytät Chrome Developer Toolsia tai Firefoxia Firebug-laajennuksen kanssa, napsauta Net-paneelia ja aseta se käyttöön. Tämän jälkeen voit tarkastella HTTP-pyyntöjen tietoja hakua tehdessäsi. Esimerkiksi:
Toinen hyödyllinen tapa tutustua HTTP:hen on käyttää omistettua asiakasohjelmaa, kuten cURL.
SAADA
GET on yksinkertaisin HTTP-pyyntötyyppi; jota selaimesi käyttää aina, kun napsautat linkkiä tai kirjoitat URL-osoitteen osoitepalkkiin. Se kehottaa palvelinta välittämään URL-osoitteen tunnistamat tiedot asiakkaalle. GET-pyynnön seurauksena ei koskaan tapahdu palvelinpuolen tietoja. Tässä mielessä GET-pyyntö on vain luku, mutta tietysti kun asiakas vastaanottaa tiedot, se voi itsenäisesti suorittaa sille mitä tahansa toimintoja, esimerkiksi muotoilla sen näyttöä varten.
LAITTAA
PUT-pyyntöä käytetään, kun haluat luoda tai päivittää URL-osoitteen määrittämän resurssin. Esimerkiksi,
LAITA /clients/robin
voi luoda palvelimelle asiakkaan nimeltä Robin. Huomaat, että REST on täysin taustasta riippumaton; Pyynnössä ei ole mitään, mikä kertoisi palvelimelle kuinka tiedot tulisi luoda - sen täytyy vain olla niin. Näin voit helposti muuttaa taustalla olevaa tekniikkaa tarpeen mukaan. PUT-pyynnöt sisältävät tietoja, joita käytetään päivitettäessä tai luotaessa resurssia rungossa. cURL:ssä voit lisätä tietoja pyyntöön käyttämällä -d.
Curl -v -X PUT -d "jotain tekstiä"
POISTAA
DELETE tekee päinvastoin kuin PUT; sitä tulee käyttää, jos haluat poistaa pyynnön URL-osoitteen määrittämän resurssin.
Curl -v -X POISTA /asiakkaat/anne
Tämä poistaa kaikki tiedot, jotka liittyvät /clients/anne tunnistamaan resurssiin.
LÄHETTÄÄ
POST-testiä käytetään, kun käsittely, jonka haluat tehdä palvelimella, on toistettava, jos POST-pyyntö toistetaan (eli ne eivät ole idempotentti, tästä lisää alla). Lisäksi POST-pyyntöjen on saatava pyynnön runkoa käsittelemään lähettämäsi URL-osoitteen alaosana.
Yksinkertaisesti sanottuna:
POST /asiakkaat/
ei saa aiheuttaa resurssin muutosta /clients/ itse, mutta URL-resurssi alkaa häneltä/asiakkaat/ . Hän voi esimerkiksi lisätä luetteloon uuden asiakkaan palvelimen luomalla tunnuksella.
/asiakkaat/some-unique-id
PUT-pyyntöjä voidaan käyttää helposti POST-pyyntöjen sijaan ja päinvastoin. Jotkut järjestelmät käyttävät vain yhtä, jotkut käyttävät POST-testiä luomiseen ja PUT-päivitystoimintoihin (koska PUT-pyynnössä määrität aina täydellisen URL-osoitteen), jotkut käyttävät POST-testiä päivityksiin ja PUT-toimintoja luomiseen.
Usein POST-pyyntöjä käytetään käynnistämään palvelintoimintoja, jotka eivät sovi Luo/Päivitä/Poista-paradigmaan; mutta tämä ei kuitenkaan kuulu RESTin piiriin. Esimerkissämme pysymme täysin PUT:ssa.
HTTP-menetelmän luokitus
Turvalliset ja vaaralliset menetelmät:
Turvallisia menetelmiä ovat ne, jotka eivät koskaan muuta resursseja. Ainoat turvalliset menetelmät neljästä edellä mainitusta ovat GET. Toiset eivät ole turvallisia, koska ne voivat johtaa resurssien muuttamiseen.
Idempotentti menetelmät:Nämä menetelmät saavuttavat saman tuloksen riippumatta siitä, kuinka monta kertaa pyyntö toistetaan: ne ovat GET, PUT ja DELETE. Ainoa ei-idempotentti menetelmä on POST. PUT:n ja DELETE:n katsominen idempotenteiksi voi olla yllättävää, vaikka se on itse asiassa melko helppo selittää: PUT-menetelmän toistaminen täsmälleen samalla rungolla muuttaa resurssia niin, että se pysyy identtisenä edellisessä PUT-pyynnössä kuvatun kanssa: mikään ei muutu! Samoin ei ole mitään järkeä poistaa resurssia kahdesti. Tästä seuraa, että riippumatta siitä, kuinka monta kertaa PUT- tai DELETE-pyyntö toistetaan, tuloksen tulee olla sama kuin jos se olisi tehty vain kerran.
Muistaa: Sinä, ohjelmoija, päätät viime kädessä, mitä tapahtuu, kun tiettyä HTTP-menetelmää käytetään. HTTP-toteutuksissa ei ole mitään, mikä saa automaattisesti aikaan resurssien luomisen, luetteloimisen, poistamisen tai päivittämisen. Sinun on oltava varovainen, että käytät HTTP-protokollaa oikein ja esität nämä semantiikkat itse.
Edustustot
HTTP-asiakas ja HTTP-palvelin vaihtavat tietoja URL-osoitteiden tunnistamista resursseista.
Voimme tiivistää tähän mennessä oppimamme seuraavasti: HTTP-asiakas ja HTTP-palvelin vaihtavat tietoja URL-osoitteiden tunnistamista resursseista.
Sanomme, että pyyntö ja vastaus sisältävät esityksen resurssista. Esityksellä tarkoitamme tietyssä muodossa olevaa tietoa resurssin tilasta tai siitä, mikä tämän tilan tulisi olla tulevaisuudessa. Sekä otsikko että teksti ovat näkymän osia.
Metatietoja sisältävät HTTP-otsikot ovat tiukasti HTTP-määrittelyjen mukaisia. ne voivat sisältää vain pelkkää tekstiä, ja ne on muotoiltava tietyllä tavalla.
Runko voi sisältää tietoja missä tahansa muodossa, ja tässä HTTP:n voima tulee esiin. Tiedät, että voit lähettää pelkkää tekstiä, kuvia, HTML- ja XML-tiedostoja millä tahansa ihmiskielellä. Pyynnön metatietojen tai eri URL-osoitteiden avulla voit valita eri näkymien välillä samalle resurssille. Voit esimerkiksi lähettää verkkosivun selaimille ja JSON-tiedoston sovelluksille.
HTTP-vastauksessa on määritettävä runkosisällön tyyppi. Tämä tehdään otsikossa, kentässä Sisältö-tyyppi; Esimerkiksi:
Sisältö/tyyppi: sovellus/json
Yksinkertaisuuden vuoksi sovelluksemme lähettää JSONia vain edestakaisin, mutta sovellus tulee suunnitella siten, että voit helposti muuttaa tietomuotoa mukautumaan eri asiakkaiden tai käyttäjien mieltymyksiin.
HTTP-asiakaskirjastot
cURL on useimmiten PHP-kehittäjien HTTP-ratkaisu.
Jotta voit kokeilla erilaisia pyyntömenetelmiä, tarvitset asiakkaan, jonka avulla voit määrittää käytettävän menetelmän. Valitettavasti HTML-lomakkeet eivät sovellu laskuille, koska ne sallivat vain GET- ja POST-pyynnöt. Tosielämässä sovellusliittymiä käytetään ohjelmallisesti erillisen asiakassovelluksen tai selaimen JavaScriptin kautta.
Tästä syystä on tärkeää, että palvelimen lisäksi sinulla on hyvät HTTP-asiakasominaisuudet valitsemallasi ohjelmointikielellä.
Erittäin suosittu HTTP-asiakaskirjasto on jälleen cURL. Olet jo tutustunut cURL-komentoon aiemmin tässä opetusohjelmassa. CURL sisältää sekä erillisen komentoriviohjelman että kirjaston, jota useat ohjelmointikielet voivat käyttää. Erityisesti cURL on useimmiten ihanteellinen HTTP-asiakasratkaisu PHP-kehittäjille. Muut kielet, kuten Python, tarjoavat enemmän alkuperäisiä HTTP-asiakaskirjastoja.
Esimerkkisovelluksen määrittäminen
Haluan näyttää mahdollisimman alhaisen toiminnallisuuden.
Esimerkki PHP-sovelluksemme on erittäin laiha. Haluan paljastaa mahdollisimman matalan tason toiminnallisuudet, ilman kehystaikuutta. En myöskään halunnut käyttää todellista API:ta, kuten Twitteriä, koska ne voivat muuttua odottamatta, sinun on määritettävä todennus, joka voi olla vaivalloista ja et voi oppia toteutusta.
Esimerkkisovelluksen suorittamiseksi sinun on asennettava PHP5 ja web-palvelin, jossa on moottori PHP:n suorittamista varten. Nykyisen version on oltava vähintään versio 5.2, jotta se voi käyttää funktioita json_encode() ja json_decode().
Mitä tulee palvelimiin, yleisin vaihtoehto on Apache with mod_php, mutta voit käyttää mitä tahansa sinulle sopivia vaihtoehtoja. On olemassa Apache-määritysesimerkki, joka sisältää uudelleenkirjoitussäännöt, jotka auttavat sinua määrittämään sovelluksesi nopeasti. Kaikki pyynnöt mihin tahansa URL-osoitteeseen, joka alkaa /clients/, tulee ohjata tiedostoomme server.php.
Apachessa sinun on otettava se käyttöön mod_rewrite ja aseta liitteenä oleva kokoonpano mod_rewrite jossain Apache-kokoonpanossasi tai tiedostossasi .htacess. Siten, server.php vastaa kaikkiin palvelimelta tuleviin pyyntöihin. Sama pitäisi saavuttaa Nginxillä tai millä tahansa muulla palvelimella, jota päätät käyttää.
Kuinka mallisovellus toimii
REST-pyyntöjen käsittelyyn on kaksi avainta. Ensimmäinen avain on käynnistää erilainen käsittely HTTP-menetelmän mukaan, vaikka URL-osoitteet ovat samat. PHP:ssä globaalissa taulukossa $_SERVER on muuttuja, joka määrittää, mitä menetelmää pyynnön suorittamiseen käytettiin:
$_SERVER["REQUEST_METHOD"]
Tämä muuttuja sisältää menetelmän nimen merkkijonona, kuten "GET", "PUT" ja niin edelleen.
Toinen avain on selvittää, mitä URL-osoitetta pyydettiin. Käytämme tätä varten toista tavallista PHP-muuttujaa:
$_SERVER["REQUEST_URI"]
Tämä muuttuja sisältää URL-osoitteen, joka alkaa ensimmäisellä kauttaviivalla. Jos isäntänimi on esimerkiksi "example.com", "http://example.com/" palauttaa "/", kun taas "http://example.com/test/" palauttaa "/test/".
Yritetään ensin selvittää, mitä URL-osoitetta kutsuttiin. Otamme huomioon vain URL-osoitteet, jotka alkavat sanalla " clients ". Kaikki muut ovat virheellisiä.
$resurssi = array_shift($polut); if ($resurssi == "asiakkaat") ( $nimi = array_shift($polut); if (tyhjä($nimi)) ( $this->handle_base($method); ) else ( $this->handle_name($method) , $nimi ) ) else ( // Käsittelemme resursseja vain "asiakkaat"-otsikon alla ("HTTP/1.1 404 Not Found"); )
Meillä on kaksi mahdollista tulosta:
- Resurssi on asiakkaat, jolloin palautamme täydellisen luettelon
- On toinenkin tunnus
Jos on olemassa toinen tunniste, oletamme sen olevan asiakkaan nimi ja välitämme sen jälleen toiseen funktioon menetelmästä riippuen. Käytämme kytkinlausetta, jota tulee välttää todellisessa sovelluksessa:
Switch($method) ( kirjainkoko "PUT": $this->create_contact($name); break; kirjainkoko "DELETE": $this->delete_contact($name); break; kirjainkoko "GET": $this->display_contact ($nimi break oletus: header("HTTP/1.1 405 Method Not Allowed");
Vastauskoodit
HTTP-vastauskoodit standardoivat tavan, jolla asiakkaalle ilmoitetaan pyynnön tuloksesta.
Olet ehkä huomannut, että esimerkkisovellus käyttää PHP header() :tä ja välittää argumentteina outoja merkkijonoja. Toiminto otsikko() tulostaa HTTP-otsikot ja varmistaa, että ne on muotoiltu oikein. Otsikoiden tulee olla ensimmäisenä vastauksessa, joten älä tulosta mitään muuta ennen kuin olet valmis käsittelemään otsikot. Joskus HTTP-palvelimesi voidaan määrittää lisäämään muita otsikoita koodissa määrittämiesi otsikoiden lisäksi.
Palvelimen tulee palauttaa sopivin HTTP-vastauskoodi; Näin asiakas voi yrittää korjata mahdollisia virheitään. Useimmat ihmiset tuntevat yleisen 404 Not Found -vastauskoodin, mutta saatavilla on monia muitakin, jotka sopivat erilaisiin tilanteisiin.
Muista, että HTTP-vastauskoodin merkitys ei ole kovin tarkka; tämä on seurausta siitä, että HTTP itsessään on melko yleinen. Sinun tulee yrittää löytää vastauskoodi, joka vastaa parhaiten tilannetta. Mutta älä huoli liikaa, jos et löydä tarkkaa vastaavuutta.
Tässä on joitain HTTP-vastauskoodeja, joita käytetään usein REST:n kanssa:
200 OK
Tämä vastauskoodi osoittaa, että pyyntö onnistui.
201 Luotu
Tämä tarkoittaa, että pyyntö onnistui ja resurssi luotiin. Sitä käytetään, jos PUT- tai POST-pyyntö onnistuu.
400 Huono pyyntö
Pyyntö hävisi. Tämä tapahtuu erityisesti POST- ja PUT-pyynnöissä, kun tietoja ei ole vahvistettu tai ne ovat väärässä muodossa.
404 Ei löydy
Tämä vastaus osoittaa, että vaadittua resurssia ei löytynyt. Tämä koskee yleensä kaikkia pyyntöjä, jotka osoittavat URL-osoitteeseen ilman vastaavaa resurssia.
401 Luvaton
Tämä virhe tarkoittaa, että sinun täytyy todentaa ennen resurssin käyttöä.
405 Menetelmä ei ole sallittu
Käytettyä HTTP-menetelmää ei tueta tälle resurssille.
409 Konflikti
Tämä osoittaa konfliktia. Käytät esimerkiksi PUT-pyyntöä luodaksesi saman resurssin kahdesti.
500 Sisäinen palvelinvirhe
Kun kaikki muu epäonnistuu; Yleensä 500-vastausta käytetään, kun käsittely epäonnistuu palvelinpuolen odottamattomien olosuhteiden vuoksi, mikä aiheuttaa palvelinvirheen.
Esimerkkisovelluksen suorittaminen
Aloitetaan yksinkertaisesti poimimalla tiedot sovelluksesta. Tarvitsemme asiakkaan tiedot, "jim", joten lähetetään yksinkertainen GET-pyyntö tämän resurssin URL-osoitteeseen:
Curl -v http://localhost:80/clients/jim
Tämä näyttää täydelliset otsikot. Vastauksen viimeinen rivi on viestin runko; tässä tapauksessa se on JSON, joka sisältää Jimin osoitteen (muista, että menetelmän nimen pois jättäminen johtaa GET-pyyntöön, ja korvaa myös localhost:80 käyttämäsi palvelimen nimellä ja portilla).
Voimme sitten hakea kaikkien asiakkaiden tiedot kerralla:
Curl -v http://localhost:80/clients/
Luodaksesi uuden asiakkaan nimeltä Paul...
Curl -v -X PUT http://localhost:80/clients/paul -d "("osoite":"Sunset Boulevard" )
ja saat vahvistuksena luettelon kaikista asiakkaista, jotka sisältävät Paavalin.
Lopuksi asiakkaan poistaminen:
Curl -v -X DELETE http://localhost:80/clients/anne
Huomaat, että palautettu JSON ei enää sisällä tietoja Annesta.
Jos yrität saada olematonta asiakasta, esimerkiksi:
Curl -v http://localhost:80/clients/jerry
Saat 404-virheilmoituksen, kun yrität luoda jo olemassa olevan asiakkaan:
curl -v -X PUT http://localhost:80/clients/anne
saat sen sijaan 409-virheen.
Johtopäätös
Yleisesti ottaen mitä vähemmän oletuksia teet HTTP:n ulkopuolella, sitä parempi.
On tärkeää muistaa, että HTTP on suunniteltu kommunikointiin järjestelmien välillä, joilla ei ole muuta yhteistä kuin protokollan ymmärtäminen. Yleisesti ottaen mitä vähemmän olettamuksia teet HTTP:n ulkopuolella, sitä parempi: se mahdollistaa monenlaisten ohjelmien ja laitteiden pääsyn API:llesi.
Käytin PHP:tä tässä opetusohjelmassa, koska se on todennäköisesti Nettuts+-lukijoiden tutuin kieli. Vaikka PHP on suunniteltu verkkokäyttöön, se ei todennäköisesti ole paras kieli RESTful-työskentelyyn, koska se käsittelee PUT-pyynnöt hyvin eri tavalla kuin GET ja POST.
PHP:n lisäksi sinun kannattaa harkita seuraavia asioita:
- Erilaiset Ruby-kehykset (Rails ja Sinatra)
- Pythonilla on loistava tuki RESTille. Pelkän Djangon ja WebObin tai Werkzeugin pitäisi toimia.
- node.js tukee RESTiä erittäin hyvin
REST-periaatteita yrittävien sovellusten joukossa klassinen esimerkki on Atom Publishing Protocol, vaikka sitä ei käytännössä käytetä kovin usein. Apache CouchDB:stä löydät modernia sovellusta, joka perustuu HTTP:n täysimittaiseen käyttöön perustuvaan filosofiaan.
612
HTTP PUT:
PUT sijoittaa tiedoston tai resurssin tiettyyn URI:hen, ja se on kyseisessä URI:ssa. Jos tässä URI:ssa on jo tiedosto tai resurssi, PUT korvaa kyseisen tiedoston tai resurssin. Jos siellä ei ole tiedostoa tai resurssia, PUT luo sellaisen. PUT on idempotentti, mutta paradoksaalisesti PUT-vastaukset eivät ole välimuistissa.
HTTP POST:
POST lähettää tiedot tiettyyn URI:hen ja odottaa, että kyseisessä URI:ssa oleva resurssi käsittelee pyynnön. Web-palvelin voi tässä vaiheessa määrittää, mitä tiedoille tehdään määritetyn resurssin yhteydessä. POST-menetelmä ei ole idempotentti, mutta POST-vastaukset ovat : ovat välimuistissa, jos palvelin asettaa sopivat Cache-Control- ja Expires-otsikot.
Virallinen HTTP RFC määrittelee POST:n olevan:
- Tiivistelmä olemassa olevista resursseista;
- Viestin lähettäminen ilmoitustaululle, uutisryhmään, postituslistalle tai vastaavaan artikkeliryhmään;
- Tietolohkon, kuten lomakkeen lähettämisen tuloksen, tarjoaminen tietojenkäsittelyprosessiin;
- Tietokannan laajentaminen liittämistoiminnolla.
Ero POST:n ja PUT:n välillä:
RFC itse selittää ytimen eron:
Perimmäinen ero POST- ja PUT-pyyntöjen välillä näkyy erilaisessa Request-URI-arvossa. POST-pyynnön URI identifioi resurssin, joka käsittelee suljetun objektin. Tämä resurssi voi olla tietojen vastaanottava prosessi, yhdyskäytävä toiseen protokollaan tai erillinen kokonaisuus, joka vastaanottaa huomautukset. Sitä vastoin PUT-pyynnön URI identifioi pyyntöön sisältyvän entiteetin - käyttäjäagentti tietää, että URI on tarkoitettu, ja palvelimen EI SAA yrittää soveltaa pyyntöä johonkin muuhun resurssiin. Jos palvelin haluaa, että pyyntöä sovelletaan toiseen URI:hen, sen TÄYTYY lähettää 301 (siirretty pysyvä) vastaus; käyttäjäagentti VOI sitten tehdä oman päätöksensä siitä, ohjataanko pyyntö uudelleen vai ei.
Käyttämällä oikeaa menetelmää, jotka eivät liity asiaan:
Minua on viime aikoina ärsyttänyt verkkokehittäjien keskuudessa suosittu väärinkäsitys, että POST:ia käytetään resurssin luomiseen ja PUT:ia päivittämiseen/muutokseen.
Jos katsot RFC 2616:n ("HyperText Transfer Protocol - HTTP/1.1") osion 9.6 ("PUT") sivua 55, näet, että PUT on itse asiassa:
PUT-menetelmä pyytää yksityisen objektin tallentamista pyydettyyn Request-URI:iin.
Siellä on myös kätevä kohta selittää ero POST:n ja PUT:n välillä:
Perimmäinen ero POST- ja PUT-pyyntöjen välillä näkyy erilaisessa Request-URI-arvossa. POST-pyynnön URI identifioi resurssin, joka käsittelee suljetun objektin. Tämä resurssi voi olla tietojen hyväksymisprosessi, yhdyskäytävä toiseen protokollaan tai erillinen kokonaisuus, joka hyväksyy huomautuksia. Sitä vastoin PUT-pyynnön URI identifioi pyynnön sisältämän entiteetin – käyttäjäagentti tietää, mikä URI on, eikä palvelimen TULLIA yrittää soveltaa pyyntöä toiseen resurssiin.
Se ei kerro mitään päivityksestä/luomisesta, koska siitä ei ole kyse. Kyse on näiden eroista:
Obj.set_attribute(value) # POST-pyyntö.
Obj.attribute = arvo # PUT-pyyntö.
Joten lopeta tämän yleisen väärinkäsityksen levittäminen. Lue RFC:t.
9
Se näyttää turhalta töykeällä ja pedanttisella vähemmän hyödyllisellä tavalla. Lainaamasi PUT-esimerkissä RESTful-sovellusliittymän uusi objekti on "uusi" merkintä ja se on käytettävissä kyseisessä paikassa. Ei ole epäilystäkään siitä, onko hyvä suunnitteluvaihtoehto sallia alatyyppien olla tällaisia (mielestäni se ei ole ihanteellinen), mutta vaikka käyttäisit alatyyppiä hyökkäämään hyödyllisempään tietoon. Useimmissa tapauksissa kuvauksen sanotaan olevan erinomainen kuvaus RFC:n sisällöstä, tiivistettynä ja yleisen ja tavanomaisen käytännön lausuma. Lisäksi kohteliaisuus ei haittaa sinua. - työkalun käyttäjä 06 huhtikuuta 15 2015-04-06 23:49:56
60
1) GET: - Käytetään, kun asiakas pyytää resurssia verkkopalvelimelta.
2) HEAD: - Käytetään, kun asiakas pyytää tietoja resurssista, mutta ei pyydä itse resurssia.
3) POST: - Käytetään, kun asiakas lähettää tietoa tai dataa palvelimelle, esimerkiksi täyttämällä online-lomakkeen (eli lähettää suuren määrän monimutkaista dataa verkkopalvelimelle).
4) PUT: - Käytetään, kun asiakas lähettää korvaavan asiakirjan tai lataa uuden asiakirjan verkkopalvelimelle pyynnön URL-osoitteen alla.
5) DELETE: - Käytetään, kun asiakas yrittää poistaa asiakirjan pyynnön URL-osoitteen tunnistamasta verkkopalvelimesta.
6) TRACE: - Käytetään, kun asiakas pyytää käytettävissä olevia välityspalvelimia tai välipalvelimia muokkaamaan pyyntöä mainostaakseen itseään.
7) OPTIONS: - Käytetään, kun asiakas haluaa määrittää muita käytettävissä olevia menetelmiä asiakirjan noutamiseksi tai käsittelemiseksi web-palvelimella.
8) CONNECT: - Käytetään, kun asiakas haluaa muodostaa läpinäkyvän yhteyden etäisäntään, tyypillisesti tarjotakseen SSL-salattua viestintää (HTTPS) HTTP-välityspalvelimen kautta.
15
