Share
Hypertext Transfer Protocol (HTTP) er livet til nettet. Den brukes hver gang du overfører et dokument, eller lager en AJAX be om. Men HTTP er overraskende en relativt ukjent blant noen webutviklere.
Denne introduksjonen vil demonstrere hvordan settet med designprinsipper, kjent som REST, støtter HTTP, og lar deg omfavne sin fulle kraft ved å bygge grensesnitt, som kan brukes fra nesten hvilken som helst enhet eller operativsystem.
Envato Market har også tusenvis av nyttige kodekser, programtillegg og programmer for å hjelpe deg med webutvikling, for eksempel HTTP Assistant, en app som hjelper deg med å teste online webtjenester.
HTTP-assistent-appen på Envato Market Publisert opplæring Noen få uker besøker vi noen av våre leseres favorittinnlegg fra hele historien til nettstedet. Denne opplæringen ble først publisert i november 2010.
REST er en enkel måte å organisere samspill mellom uavhengige systemer på.
REST er en enkel måte å organisere samspill mellom uavhengige systemer på. Det har vokst i popularitet siden 2005, og inspirerer utformingen av tjenester, for eksempel Twitter API. Dette skyldes at REST gjør at du kan samhandle med minimal overhead med klienter som er like forskjellige som mobiltelefoner og andre nettsteder. I teorien er REST ikke knyttet til nettet, men det er nesten alltid implementert som sådan, og ble inspirert av HTTP. Som et resultat kan REST brukes hvor som helst HTTP kan.
Alternativet bygger relativt komplekse konvensjoner på toppen av HTTP. Ofte tar dette formen av helt nye XML-baserte språk. Det mest illustrerende eksempelet er SOAP. Du må lære et helt nytt sett med konvensjoner, men du bruker aldri HTTP til sin fulle kraft. Fordi REST har blitt inspirert av HTTP og spiller til dets sterke sider, er det den beste måten å lære hvordan HTTP fungerer.
Etter en innledende oversikt vil vi undersøke hver av HTTP-byggeblokkene: nettadresser, HTTP-verker og svarkoder. Vi vurderer også hvordan du bruker dem på en RESTful måte. Underveis illustrerer vi teorien med et eksempelprogram som simulerer prosessen med å holde oversikt over data knyttet til selskapets kunder gjennom et webgrensesnitt.
HTTP er protokollen som gjør det mulig å sende dokumenter frem og tilbake på nettet.
HTTP er protokollen som gjør det mulig å sende dokumenter frem og tilbake på nettet. En protokoll er et sett med regler som bestemmer hvilke meldinger som kan utveksles, og hvilke meldinger er passende svar til andre. En annen vanlig protokoll er POP3, som du kanskje bruker til å hente e-post på harddisken din.
I HTTP er det to forskjellige roller: server og klient. Generelt starter klienten alltid samtalen; serveren svarer. HTTP er tekstbasert; det vil si meldinger er egentlig biter av tekst, selv om meldingslegemet også kan inneholde andre medier. Tekstbruk gjør det enkelt å overvåke en HTTP-utveksling.
HTTP-meldinger er laget av en header og en kropp. Kroppen kan ofte forbli tom; den inneholder data som du vil overføre over nettverket, for å bruke det i henhold til instruksjonene i overskriften. Overskriften inneholder metadata, for eksempel kodingsinformasjon; men i tilfelle av en forespørsel inneholder den også de viktige HTTP-metodene. I REST-stilen vil du finne at headerdata ofte er mer signifikante enn kroppen.
Hvis du bruker Chrome Developer Tools, eller Firefox med Firebug-utvidelsen installert, klikker du på Nett panelet, og sett det til aktivert. Du vil da kunne se detaljene for HTTP-forespørslene mens du surfer. For eksempel:
En annen nyttig måte å gjøre deg kjent med HTTP, er å bruke en dedikert klient, for eksempel cURL.
cURL er et kommandolinjeverktøy som er tilgjengelig på alle større operativsystemer.
Når du har installert cURL, skriver du:
krølle -v google.com
Dette vil vise hele HTTP-samtalen. Forespørsler foregår av >, mens svarene foregår av <.
Nettadresser er hvordan du identifiserer de tingene du vil operere på. Vi sier at hver nettadresse identifiserer en ressurs. Disse er nøyaktig de samme nettadressene som er tilordnet websider. Faktisk er en nettside en type ressurs. La oss ta et eksotisk eksempel, og se på vårt utvalgsprogram, som styrer listen over selskapets kunder:
/ klienter
vil identifisere alle klienter, mens
/ Klienter / jim
vil identifisere klienten, kalt 'jim', forutsatt at han er den eneste med det navnet.
I disse eksemplene inkluderer vi vanligvis ikke vertsnavnet i nettadressen, da det er irrelevant i forhold til hvordan grensesnittet er organisert. Likevel er vertsnavnet viktig for å sikre at ressursidentifikatoren er unik over hele nettet. Vi sier ofte at du sender forespørselen til en ressurs til en vert. Verten er inkludert i overskriften separat fra ressursbanen, som kommer rett oppe på forespørselhodet:
GET / klienter / jim HTTP / 1.1 Host: example.com
Ressurser anses best som substantiver. For eksempel er følgende ikke RESTful:
/ klienter / add
Dette skyldes at det bruker en nettadresse for å beskrive en handling. Dette er et ganske grunnleggende punkt i å skille RESTful fra ikke-RESTful systemer.
Endelig bør nettadresser være så nøyaktige som nødvendig; alt som trengs for å unikt identifisere en ressurs burde være i nettadressen. Du bør ikke inkludere data som identifiserer ressursen i forespørselen. På denne måten fungerer nettadresser som et komplett kart over alle dataene dine håndterer.
Men hvordan spesifiserer du en handling? For eksempel, hvordan forteller du at du vil ha en ny klientoppføring opprettet i stedet for å hentes? Det er her HTTP-verbene kommer inn i spill.
Hver forespørsel spesifiserer et bestemt HTTP-verb, eller en metode, i forespørselsoverskriften. Dette er det første alle caps-uttrykket i forespørselsoverskriften. For eksempel,
GET / HTTP / 1.1
betyr at GET-metoden blir brukt, mens
SLETT / klienter / anne HTTP / 1.1
betyr SLETT Metoden blir brukt.
HTTP-verker forteller serveren hva de skal gjøre med dataene som er identifisert av nettadressen.
HTTP-verker forteller serveren hva de skal gjøre med dataene som er identifisert av nettadressen. Forespørselen kan eventuelt inneholde tilleggsinformasjon i kroppen, noe som kan være nødvendig for å utføre operasjonen - for eksempel data du vil lagre med ressursen. Du kan levere disse dataene i cURL med -d alternativ.
Hvis du noen gang har opprettet HTML-skjemaer, vil du være kjent med to av de viktigste HTTP-verbene: FÅ og POST. Men det er langt flere HTTP-verker tilgjengelig. De viktigste for å bygge RESTful API er FÅ, POST, SETTE og SLETT. Andre metoder er tilgjengelige, for eksempel HODE og ALTERNATIVER, men de er mer sjeldne (hvis du vil vite om alle andre HTTP-metoder, er den offisielle kilden IETF).
FÅ er den enkleste typen HTTP-forespørselsmetode; den som nettlesere bruker hver gang du klikker en kobling eller skriver inn en nettadresse i adressefeltet. Den instruerer serveren om å overføre dataene identifisert av nettadressen til klienten. Data bør aldri endres på server siden som følge av a FÅ be om. I denne forstand a FÅ forespørsel er skrivebeskyttet, men selvfølgelig, når klienten mottar dataene, er det selvsagt gratis å gjøre noe med det på egen side - for eksempel formatere det for visning.
EN SETTE forespørsel brukes når du ønsker å opprette eller oppdatere ressursen identifisert av nettadressen. For eksempel,
PUT / klienter / robin
kan opprette en klient, kalt Robin på serveren. Du vil legge merke til det HVILE er helt backend agnostisk; Det er ingenting i forespørselen som informerer serveren om hvordan dataene skal opprettes - akkurat det det skal. Dette lar deg enkelt bytte backend-teknologien hvis behovet skulle oppstå. SETTE forespørsler inneholder dataene som skal brukes til å oppdatere eller opprette ressursen i kroppen. I cURL kan du legge til data på forespørselen med -d bytte om.
curl -v -X PUT -d "litt tekst"
SLETT bør gjøre det motsatte SETTE; den skal brukes når du vil slette ressursen som er identifisert av nettadressen til forespørselen.
curl -v -X DELETE / clients / anne
Dette vil slette alle data knyttet til ressursen, identifisert av / Klienter / anne.
POST brukes når behandlingen du ønsker å skje på serveren, skal gjentas, hvis POST forespørsel gjentas (det vil si, de er ikke idempotent; mer på det nedenfor). I tillegg, POST Forespørsler bør føre til behandling av forespørselsorganet som en underordnet nettadresse du sender inn til.
I enkle ord:
POST / klienter /
bør ikke forårsake ressursen på / klienter /, i seg selv, for å bli endret, men en ressurs hvis URL begynner med /klienter /. For eksempel kan det legge til en ny klient til listen, med en id generert av serveren.
/ Klienter / noen-unique-id
SETTE forespørsler brukes lett i stedet for POST forespørsler, og omvendt. Noen systemer bruker bare en, noen bruk POST for å opprette operasjoner, og SETTE for oppdateringsoperasjoner (siden med a SETTE be om at du alltid leverer den komplette nettadressen), noen til og med bruker POST for oppdateringer og SETTE for skaper.
Ofte, POST forespørsler brukes til å utløse operasjoner på serveren, som ikke passer inn i Lag / oppdater / Slett paradigmet; men dette er imidlertid utenfor omfanget av HVILE. I vårt eksempel holder vi oss til SETTE hele veien.
Accentsconagua
FÅ. De andre er usikre, fordi de kan føre til endring av ressursene. Idempotent metoder: Disse metodene oppnår det samme resultatet, uansett hvor mange ganger forespørselen gjentas: de er FÅ, SETTE, og SLETT. Den eneste ikke idempotente metoden er POST. SETTE og SLETT å bli ansett idempotent kan være overraskende, men det er faktisk ganske enkelt å forklare: gjenta en SETTE Metode med nøyaktig samme kropp bør endre en ressurs på en måte som forblir identisk med den som er beskrevet i det forrige SETTE forespørsel: ingenting vil forandre seg! På samme måte er det ikke fornuftig å slette en ressurs to ganger. Det følger at uansett hvor mange ganger a SETTE eller SLETT forespørselen gjentas, resultatet skal være det samme som om det bare hadde blitt gjort en gang. Huske: Det er deg, programmøren, som i siste instans bestemmer hva som skjer når en bestemt HTTP-metode brukes. Det er ingenting som er iboende for HTTP-implementeringer som automatisk vil føre til at ressurser blir opprettet, oppført, slettet eller oppdatert. Du må være forsiktig med å bruke HTTP-protokollen riktig og håndheve disse semantikkene selv.
HTTP-klienten og HTTP-serveren utveksler informasjon om ressurser identifisert av nettadresser.
Vi kan oppsummere hva vi har lært så langt på følgende måte: HTTP-klienten og HTTP-serveren utveksler informasjon om ressurser identifisert av nettadresser.
Vi sier at forespørselen og svaret inneholder en representasjon av ressursen. Ved representasjon mener vi informasjon, i et bestemt format, om ressursens tilstand eller hvordan den staten burde være i fremtiden. Både topptekst og kropp er deler av representasjonen.
HTTP-overskriftene, som inneholder metadata, er stramt definert av HTTP-spesifikasjonen; de kan bare inneholde ren tekst, og må formateres på en bestemt måte.
Kroppen kan inneholde data i et hvilket som helst format, og dette er hvor kraften til HTTP virkelig skinner. Du vet at du kan sende vanlig tekst, bilder, HTML og XML på et hvilket som helst menneskespråk. Via forespørselsmetadata eller forskjellige nettadresser kan du velge mellom forskjellige representasjoner for samme ressurs. For eksempel kan du sende en nettside til nettlesere og JSON til programmer.
HTTP-responsen bør spesifisere kroppstypen for innholdet. Dette gjøres i overskriften, i Innholdstype felt; for eksempel:
Innhold / Type: søknad / json
For enkelhets skyld sender vår eksempelsøknad bare JSON frem og tilbake, men søknaden skal være arkitektur slik at du enkelt kan endre formatet på dataene, skreddersy for ulike klienter eller brukerpreferanser.
cURL er oftere enn ikke HTTP-klientløsningen for PHP-utviklere.
For å eksperimentere med de ulike forespørselsmetodene, trenger du en klient, som lar deg spesifisere hvilken metode som skal brukes. Dessverre passer ikke HTML-skjemaene til regningen, da de bare tillater deg å gjøre GET- og POST-forespørsler. I virkeligheten blir APIer programmert gjennom et eget klientprogram, eller via JavaScript i nettleseren.
Dette er grunnen til at, i tillegg til serveren, er det viktig å ha gode HTTP-klientegenskaper tilgjengelig på ditt programmerte språk..
Et veldig populært HTTP-klientbibliotek er igjen, cURL. Du har allerede blitt kjent med cURL-kommandoen fra tidligere i denne opplæringen. cURL inneholder både et frittstående kommandolinjeprogram og et bibliotek som kan brukes av ulike programmeringsspråk. Spesielt er cURL oftere enn ikke HTTP-klientløsningen for PHP-utviklere. Andre språk, som Python, tilbyr flere innfødte HTTP-klientbiblioteker.
Jeg vil utsette lavnivåfunksjonaliteten så mye som mulig.
Vårt eksempel på PHP-applikasjonen er ekstremt barebones. Jeg vil utsette lavnivåfunksjonaliteten så mye som mulig uten rammekunst. Jeg ville heller ikke bruke en ekte API, for eksempel Twitter, fordi de kan endres uventet, du må konfigurere autentisering, noe som kan være et problem, og selvfølgelig kan du ikke studere gjennomføringen.
For å kjøre eksempelprogrammet, må du installere PHP5 og en webserver, med noen mekanisme for å kjøre PHP. Den nåværende versjonen må være minst versjon 5.2 for å få tilgang til json_encode () og json_decode () funksjoner.
Når det gjelder servere, er det vanligste valget fortsatt Apache med mod_php, men du er fri til å bruke alternativer du er komfortabel med. Det er en prøve Apache-konfigurasjon, som inneholder omskrivningsregler for å hjelpe deg med å sette opp programmet raskt. Alle forespørsler til en hvilken som helst URL, som starter med / klienter /, må sendes til vår server.php fil.
I Apache må du aktivere mod_rewrite og sett den medfølgende mod_rewrite konfigurasjon et sted i din Apache-konfigurasjon, eller din .htacess fil. Denne måten, server.php vil svare på alle forespørsler som kommer fra serveren. Det samme må oppnås med Nginx, eller hvilken alternativ server du bestemmer deg for å bruke.
Det er to nøkler for å behandle forespørsler REST-måten. Den første nøkkelen er å starte en annen behandling, avhengig av HTTP-metoden - selv når nettadressene er de samme. I PHP er det en variabel i $ _SERVER global array, som bestemmer hvilken metode som har blitt brukt til å gjøre forespørselen:
$ _SERVER [ 'REQUEST_METHOD']
Denne variabelen inneholder metodenavnet som en streng, for eksempel 'FÅ','SETTE', og så videre.
Den andre nøkkelen er å vite hvilken URL som er blitt forespurt. For å gjøre dette bruker vi en annen standard PHP-variabel:
$ _SERVER [ 'REQUEST_URI']
Denne variabelen inneholder nettadressen som starter fra den første spissen forover. For eksempel, hvis vertsnavnet er 'example.com','http://example.com/'ville returnere'/', samtidig som 'http://example.com/test/'ville returnere'/test/'.
La oss først prøve å bestemme hvilken URL som er blitt kalt. Vi vurderer bare nettadresser som begynner med 'klienter'. Alle andre er ugyldige.
$ ressurs = array_shift ($ baner); hvis ($ resource == 'klienter') $ name = array_shift ($ paths); hvis (tomt ($ navn)) $ this-> handle_base ($ metode); ellers $ this-> handle_name ($ metode, $ navn); else // Vi håndterer bare ressursene under "klientens overskrift" ("HTTP / 1.1 404 ikke funnet"); Vi har to mulige utfall:
Hvis det er en ytterligere identifikator, antar vi at det er klientens navn, og send det videre til en annen funksjon, avhengig av metode. Vi bruker en bytte om uttalelse, som bør unngås i en reell applikasjon:
bytte ($ metode) case 'PUT': $ this-> create_contact ($ navn); gå i stykker; saken 'DELETE': $ this-> delete_contact ($ navn); gå i stykker; tilfelle 'GET': $ this-> display_contact ($ navn); gå i stykker; standard: header ('HTTP / 1.1 405 metode ikke tillatt'); header ('Tillat: GET, PUT, DELETE'); gå i stykker; HTTP-responskoder standardiserer en måte å informere klienten om resultatet av sin forespørsel.
Du har kanskje lagt merke til at eksempelprogrammet bruker PHP Overskrift(), passerer noen merkelige utseende strenger som argumenter. De Overskrift() funksjonen skriver ut HTTP overskrifter og sikrer at de er formatert på riktig måte. Overskrifter bør være den første på svaret, så du bør ikke skrive ut noe annet før du er ferdig med overskriftene. Noen ganger kan HTTP-serveren din konfigureres for å legge til andre overskrifter, i tillegg til de du angir i koden din.
Headers inneholder all slags meta informasjon; for eksempel tekstkodingen som brukes i meldingslegemet eller MIME-typen av kroppens innhold. I dette tilfellet spesifiserer vi eksplisitt HTTP-responskoder. HTTP-responskoder standardiserer en måte å informere klienten om resultatet av sin forespørsel. Som standard returnerer PHP a 200 svarkoden, som betyr at svaret er vellykket.
Serveren skal returnere den mest hensiktsmessige HTTP-responskoden; På denne måten kan klienten forsøke å reparere sine feil, forutsatt at det er noen. De fleste er kjent med det vanlige 404 ikke funnet svarskode, men det er mye mer tilgjengelig for å passe et bredt spekter av situasjoner.
Husk at betydningen av en HTTP-responskode ikke er ekstremt presis; Dette er en konsekvens av at HTTP selv er ganske generisk. Du bør prøve å bruke svarkoden som passer best til situasjonen ved hånden. Når det er sagt, ikke bekymre deg for mye hvis du ikke finner en nøyaktig passform.
Her er noen HTTP-responskoder, som ofte brukes med REST:
Denne svarkoden indikerer at forespørselen var vellykket.
Dette indikerer at forespørselen var vellykket og en ressurs ble opprettet. Det brukes til å bekrefte suksess av a SETTE eller POST be om.
Forespørselen ble misdannet. Dette skjer spesielt med POST og SETTE forespørsler, når dataene ikke bestått validering, eller er i feil format.
Dette svaret indikerer at den nødvendige ressursen ikke kunne bli funnet. Dette returneres vanligvis til alle forespørsler som peker på en nettadresse uten tilsvarende ressurs.
Denne feilen indikerer at du må utføre godkjenning før du får tilgang til ressursen.
HTTP-metoden som brukes, støttes ikke for denne ressursen.
Dette indikerer en konflikt. For eksempel bruker du en SETTE Be om å opprette samme ressurs to ganger.
Når alt annet svikter; Generelt brukes en 500 respons når behandlingen mislykkes på grunn av uventede omstendigheter på serversiden, noe som forårsaker at serveren feiler ut.
La oss begynne med å bare hente informasjon fra applikasjonen. Vi vil ha detaljer om klienten, 'jim', så la oss sende en enkel FÅ forespørsel til nettadressen for denne ressursen:
krølle -v http: // localhost: 80 / clients / jim
Dette vil vise de komplette meldingshodene. Den siste linjen i svaret vil være meldingslegemet; i dette tilfellet vil det være JSON som inneholder Jims adresse (husk at utelatelse av metodenavn vil resultere i a FÅ be om; også erstatte localhost: 80 med servernavnet og porten du bruker).
Deretter kan vi få informasjonen til alle klientene samtidig:
krølle -v http: // localhost: 80 / klienter /
Å opprette en ny klient, kalt Paul ...
curl -v -X PUT http: // localhost: 80 / klienter / paul -d '"adresse": "Sunset Boulevard"
og du vil motta listen over alle klienter som nå inneholder Paul som en bekreftelse.
Endelig, for å slette en klient:
krølle -v -X SLETT http: // localhost: 80 / clients / anne
Du vil finne at den returnerte JSON ikke lenger inneholder noen data om Anne.
Hvis du prøver å hente en ikke eksisterende klient, for eksempel:
curl -v http: // localhost: 80 / clients / jerry
Du får en 404-feil, mens du prøver å opprette en klient som allerede eksisterer:
curl -v -X PUT http: // localhost: 80 / clients / anne
Du får i stedet en 409-feil.
Generelt, jo mindre antagelser utover HTTP du gjør, jo bedre.
Det er viktig å huske at HTTP ble utformet for å kommunisere mellom systemer, som bare deler en forståelse av protokollen. Generelt, jo mindre antagelser utover HTTP du gjør, desto bedre: dette gir det bredeste spekteret av programmer og enheter tilgang til API-en din.
Jeg brukte PHP i denne opplæringen, fordi det mest sannsynlig er språket mest kjent for Nettuts + lesere. Når det er sagt, er PHP, selv om det er designet for nettet, sannsynligvis ikke det beste språket som skal brukes når man arbeider på en REST måte, da den håndterer SETTE forespørsler på en helt annen måte enn FÅ og POST.
Utover PHP kan du vurdere følgende:
Blant programmene som forsøker å overholde REST-prinsippene, er det klassiske eksempel Atom Publishing Protocol, men det er ærlig ikke brukt for ofte i praksis. For en moderne applikasjon, som er bygget på filosofien om å bruke HTTP i sin helhet, se Apache CouchDB.
Og ikke glem å sjekke ut valg av kode skript, plugins og apps på Envato Market.
Ha det gøy!
Vi har bygget en komplett guide for å hjelpe deg med å lære JavaScript, enten du er bare i gang som webutvikler eller du vil utforske mer avanserte emner.
