Share
Hvis du har brukt mye tid med moderne webutvikling, har du kommet over betingelser som REST og API. Hvis du har hørt om disse vilkårene eller jobbet med APIer, men ikke har full forståelse av hvordan de fungerer eller hvordan du bygger din egen API, er denne serien for deg.
I denne opplæringsserien starter vi med en oversikt over REST-prinsipper og konsepter. Da fortsetter vi å lage vår egen fullverdige API som kjører på en Node.js Express-server og kobles til en MySQL-database. Etter at du har fullført denne serien, bør du føle deg trygg på å bygge din egen API eller delve i dokumentasjonen for en eksisterende API.
For å få mest mulig ut av denne opplæringen, bør du allerede ha noen grunnleggende kommandolinje kunnskap, kjennskap til grunnleggende for JavaScript, og ha Node.js installert globalt.
Representativ statlig overføring, eller HVILE, beskriver en arkitektonisk stil for webtjenester. REST består av et sett med standarder eller begrensninger for å dele data mellom forskjellige systemer, og systemer som implementerer REST kalles RESTful. REST er et abstrakt konsept, ikke et språk, rammeverk eller type programvare.
En løs analogi for REST ville være å holde en samling av vinyl vs å bruke en streaming musikk tjeneste. Med den fysiske vinylinnsamlingen må hver plate dupliseres i sin helhet for å dele og distribuere kopier. Med en streamingtjeneste kan imidlertid samme musikk deles i evighet via en referanse til noen data som en sangtittel. I dette tilfellet er streaming musikk en RESTful tjeneste, og vinyl samlingen er en ikke-RESTful tjeneste.
en API er et applikasjonsprogrammeringsgrensesnitt, som er et grensesnitt som gjør at programvarene kan kommunisere med hverandre. EN RESTful API er bare en API som overholder RESTs prinsipper og begrensninger. I en web-API mottar en server en be om gjennom et URL-endepunkt og sender en respons i retur, som ofte er data i et format som JSON.
Seks ledende begrensninger definerer REST-arkitekturen, skissert nedenfor.
Du vil allerede være kjent med det faktum at alle nettsteder har nettadresser som begynner med http (eller https for den sikre versjonen). HyperText Transfer Protocol, eller HTTP, er metoden for kommunikasjon mellom klienter og servere på internett.
Vi ser det tydeligst i nettleserens nettleser, men HTTP kan brukes til mer enn bare å be om nettsteder fra servere. Når du går til en nettadresse på nettet, gjør du faktisk en FÅ forespørsel om den spesifikke ressursen, og nettstedet du ser er svarets kropp. Vi vil gå over FÅ og andre typer forespørsler kort tid.
HTTP fungerer ved å åpne en TCP (Transmission Control Protocol) tilkobling til en serverport (80 til http, 443 til https) for å gjøre en forespørsel, og lytteren reagerer med en status og en kropp.
En forespørsel må bestå av en nettadresse, en metode, headerinformasjon og en kropp.
Det er fire store HTTP-metoder, også referert til som HTTP-verb, som ofte brukes til å samhandle med web-APIer. Disse metodene definerer handlingen som skal utføres med en gitt ressurs.
HTTP-forespørselsmetoder samsvarer løst med paradigmet til CRUD, som står for Opprett, oppdater, les, slett. Selv om CRUD refererer til funksjoner som brukes i databaseoperasjoner, kan vi bruke disse designprinsippene til HTTP-verb i en RESTful API.
| Handling | Forespørselsmetode | Definisjon |
|---|---|---|
| Lese | FÅ | Henter en ressurs |
| Skape | POST | Oppretter en ny ressurs |
| Oppdater | SETTE | Oppdaterer en eksisterende ressurs |
| Slett | SLETT | Slette en ressurs |
FÅ er en sikker, skrivebeskyttet operasjon som ikke vil endre tilstanden til en server. Hver gang du treffer en URL i nettleseren din, for eksempel https://www.google.com, du sender en FÅ forespørsel til Googles servere.
POST brukes til å opprette en ny ressurs. Et kjent eksempel på POST Registrerer deg som bruker på et nettsted eller en app. Etter å ha sendt skjemaet, a POST forespørsel med brukerdata kan sendes til serveren, som deretter vil skrive den informasjonen i en database.
SETTE oppdaterer en eksisterende ressurs, som kan brukes til å redigere innstillingene til en eksisterende bruker. I motsetning til POST, SETTE er idempotent, Det betyr at det samme samtalen kan gjøres flere ganger uten å produsere et annet resultat. For eksempel, hvis du sendte det samme POST be om å opprette en ny bruker i en database flere ganger, ville det opprette en ny bruker med samme data for hver forespørsel du har laget. Men bruker det samme SETTE forespørsel på samme bruker vil kontinuerlig produsere det samme resultatet.
SLETT, som navnet antyder, vil bare slette en eksisterende ressurs.
Når en forespørsel går gjennom fra klienten til serveren, sender serveren tilbake et HTTP-svar, som inkluderer metadata om svaret som er kjent som overskrifter, samt kroppen. Den første og viktigste delen av svaret er statuskode, som indikerer om en forespørsel var vellykket, hvis det oppsto en feil, eller om det skulle treffes en annen handling.
Den mest kjente svarkoden du vil bli kjent med er 404, som betyr Ikke funnet. 404 er en del av 4xx klasse av statuskoder, som indikerer klientfeil. Det er fem klasser av statuskoder som hver inneholder en rekke svar.
Accentsconagua
1xx: Informasjon2xx: Suksess3xx: Omdirigering4xx: Klientfeil5xx: ServerfeilAndre vanlige svar du kanskje er kjent med er 301 Flyttet permanent, som brukes til å omdirigere nettsteder til nye nettadresser, og 500 intern serverfeil, som er en feil som kommer opp ofte når noe uventet har skjedd på en server som gjør det umulig å oppfylle ønsket forespørsel.
Med hensyn til RESTful APIs og deres tilsvarende HTTP-verb, bør alle svarene være i 2xx område.
| Be om | Respons |
|---|---|
FÅ | 200 (OK) |
POST | 201 (Laget) |
SETTE | 200 (OK) |
SLETT | 200 (OK), 202 (Godkjent), eller 204 (Ikke noe innhold) |
200 OK er svaret som indikerer at en forespørsel er vellykket. Det brukes som svar når du sender en FÅ eller SETTE be om. POST vil returnere a 201 Opprettet for å indikere at en ny ressurs er opprettet, og SLETT har noen akseptable svar, som formidler at enten forespørselen er akseptert (202), eller det er ikke noe innhold å returnere fordi ressursen ikke lenger eksisterer (204).
Vi kan teste statuskoden til en ressursforespørsel ved bruk av cURL, som er et kommandolinjeværktøy som brukes til å overføre data via nettadresser. Ved hjelp av curl, etterfulgt av -Jeg eller --inkludere flagg, vil sende en FÅ Be om en URL og vis topptekstene og kroppen. Vi kan teste dette ved å åpne kommandolinjeprogrammet og teste cURL med Google.
krølle -i https://www.google.com Googles server vil svare med følgende.
HTTP / 2 200 dato: Tue, 14 Aug 2018 05:15:40 GMT utløper: -1 cache-kontroll: privat, maks-alder = 0 innholdstype: tekst / html; charset = ISO-8859-1 ...
Som vi kan se, er curl forespørsel returnerer flere overskrifter og hele HTML-kroppen av svaret. Siden forespørselen gikk gjennom, er den første delen av svaret den 200 statuskode, sammen med versjonen av HTTP (dette vil enten være HTTP / 1.1 eller HTTP / 2).
Siden denne forespørselen returnerer et nettsted, er det innholdstype (MIME type) som returneres er text / html. I en RESTful API, vil du sannsynligvis se application / json for å indikere svaret er JSON.
Interessant, vi kan se en annen type svar ved å legge inn en litt annen URL. Gjør a curl på Google uten www.
krølle -i https://google.com HTTP / 2 301 plassering: https://www.google.com/ innholdstype: text / html; charset = UTF-8
Google omdirigeringer google.com til www.google.com, og bruker a 301 svar for å indikere at ressursen skal omdirigeres.
Når en API er opprettet på en server, er dataene den er tilgjengelig via endepunkter. en endepunkt er nettadressen til forespørselen som kan godta og behandle FÅ, POST, SETTE, eller SLETT be om.
En API-nettadresse vil bestå av roten, banen og valgfri spørringsstrengen.
https://api.example.com eller https://api.example.com/v2: Roten til API-en, som kan bestå av protokollen, domenet og versjonen./ brukere /eller / brukere / 5: Unik lokalisering av den spesifikke ressursen.?plassering = chicago & alder = 29: Valgfrie nøkkelverdierpar som brukes til sortering, filtrering og paginering.grense å filtrere svarene til bare å inkludere ti resultater.https://api.example.com/users?limit=10
Generelt, når folk henviser til en API som en RESTful API, refererer de til navngivningskonvensjonene som går inn i å bygge API-URL-endepunkter. Noen viktige konvensjoner for en standard RESTful API er som følger:
5, vi ville bruke / brukere / 5, ikke / Bruker / 5..json.Legg til og slette bør ikke vises i en REST URL. For å legge til en ny bruker, vil du bare sende en POST forespørsel til / brukere, ikke noe som helst / brukere / add. API-en skal utvikles for å håndtere flere typer forespørsler til samme nettadresse.Alle disse konvensjonene er retningslinjer, da det ikke er noen strenge REST-standarder som skal følges. Bruk av disse retningslinjene vil imidlertid gjøre APIen din konsistent, kjent og lett å lese og forstå.
I denne artikkelen lærte vi hvilke REST og RESTful APIer, hvordan HTTP-forespørselsmetoder og svarkoder fungerer, strukturen av en API-nettadresse og vanlige RESTful API-konvensjoner. I den neste opplæringen lærer vi hvordan du bruker all denne teorien ved å sette opp en Express-server med Node.js og bygge vår egen API.
