Grunnleggende om REST og RESTful API Development

Webutviklere snakker ofte om REST-prinsipper og RESTful dataarkitektur, da det er et viktig aspekt ved moderne utvikling, men noen ganger kan det være utrolig forvirrende. REST er ikke en teknologi i seg selv, men heller en metode for å lage APIer med visse organisatoriske prinsipper . Disse prinsippene er å veilede utviklere, og skape et mer universelt miljø for behandling av API-forespørsler.

I dette innlegget vil jeg gjerne forklare RESTful utviklingspraksis fra en fugleperspektiv. Jeg vil takle det i stedet for hvordan . Selv om jeg kommer til å berøre begge områder, er dette innlegget laget for alle som er med i webutvikling, men kan ikke forstå begrepet REST APIs.

REST For Webutviklere

Akronymet REST står for Representasjonsoverføring . Dette kan høres litt forvirrende, og wiki-inngangen gjør det enda mer forvirrende. Men det er mulig å forenkle terminologien.

REST er bare en rekke retningslinjer og arkitektoniske stiler som brukes til dataoverføring . Det brukes vanligvis til webapplikasjoner, men kan også overføre data til programvare.

Akronym-API står for Application Programming Interface, som er metoder for tilkobling med andre biblioteker eller applikasjoner . Windows har flere APIer, og Twitter har også en web-API, selv om de utfører forskjellige oppgaver med forskjellige mål.

Kombinere alt sammen, er RESTful APIer APIer som følger REST-arkitekturen.

Hva er REST-arkitekturen?

Dette er hvor det er vanskelig å legge ned detaljer. Men det er noen arkitektoniske konstanter, for eksempel:

• Konsistens over hele APIen
• Statsløs eksistens, det vil si ingen server-side økter
• Bruk av HTTP-statuskoder der det er aktuelt
• Bruk av URL-endepunkter med et logisk hierarki
• Versjonering i nettadressen i stedet for i HTTP-overskrifter

Det finnes ikke altfor spesifikke retningslinjer som W3C HTML5-spesifikasjonen som kan føre til forvirring, og en usikkerhet rundt REST-terminologi.

Også listen ovenfor bør ikke betraktes som raske og raske regler, selv om de er sanne for de fleste moderne RESTful APIer.

REST er en lettvektsmetodikk som gjør den perfekt til HTTP-data. Det er derfor REST ble så populært på nettet, og hvorfor det er allment ansett som det beste valget for API-utvikling.

Som Vinay Sahni sier det, er en API en utviklerens brukergrensesnitt. Alt skal være enkelt å bruke, og gi en god brukeropplevelse. RESTful APIs tar sikte på å gjøre nettopp det.

Nøkkelfunksjoner for RESTful APIs

Disse tipsene er i sammenheng med APIer strengt for webapplikasjoner . Dette betyr at HTTP er et krav, og det betyr ofte at API-dataene er vert på en ekstern server . La oss undersøke hvordan RESTful APIs fungerer på siden av API-brukeren.

API-brukeren er nettutvikleren som kan bygge et skript som kobles til en ekstern API-server, og de nødvendige dataene sendes over HTTP. Utvikleren kan da vise data på deres nettside uten å ha personlig tilgang til den eksterne serveren (som å trekke Twitter-data).

Generelt er det fire kommandoer som brukes til å få tilgang til RESTful APIs :

1. GET for å hente en gjenstand
2. POST for å opprette en ny gjenstand
3. PUT for å endre eller erstatte et objekt
4. DELETE for å fjerne en gjenstand

Hver av disse metodene bør sendes med API-anropet for å fortelle serveren hva han skal gjøre.

De aller fleste web-APIer tillater bare GET forespørsler for å trekke data ut fra en ekstern server. Autentisering er valgfri, men absolutt en god ide når du tillater potensielt skadelige kommandoer som PUT eller DELETE .

Men ikke mange RESTful APIer går selv så langt. Vurder Pokéapi som er en gratis Pokémon API-database. Den er åpen for publikum med anstendig takstbegrensning (begrenser brukerne til et bestemt antall API-forespørsler over en tidsperiode), men tillater bare GET metoden for tilgang til ressurser. Dette kan kalles kollokvivalent en API for forbruk .

Returtyper er også viktige, og skal beholde homogenitet for alle ressurser. JSON er en populær returtype med elektroniske spesifikasjoner som forklarer riktig datastrukturer.

RESTful APIs bruker substantiver for API objekter, og verb for å utføre handlinger på disse objektene. Godkjenning kan være en del av dette, takstbegrensning kan også være en del av dette. Men en veldig enkel API kan komme uten stor bekymring for brukerbegrensninger.

Få tilgang til API-ressurser

Offentlige APIer er vanligvis tilgjengelige fra direkte nettadresser . Dette betyr at nettadressestrukturen er viktig, og bør bare brukes til API-forespørsler.

Enkelte nettadresser kan inneholde et prefiks katalog som /v2/ for en oppdatert versjon 2 av en tidligere API. Dette er vanlig for utviklere som ikke vil avskrive sin 1.x API, men vil fortsatt tilby den nyeste strukturen.

Jeg nøt virkelig dette innlegget som dekker grunnleggende nettadressestrukturer og eksempler fra andre tjenester.

Merk at sluttpunktets returdata vil endres dramatisk basert på HTTP-metoden . For eksempel henter GET innhold, mens POST oppretter nytt innhold. Forespørselen kan peke på det samme endepunktet, men resultatet kan være svært forskjellig.

Å se på eksempler på nettet kan hjelpe deg med å forstå konsepter klarere. Vi har allerede sett Pokeapi, men her er noen andre virkelige API-eksempler for å lese:

• Reddit API
• GitHub API
• Flickr API
• Pinterest API

Bygg din egen API

Prosessen med å lage din egen API bør ikke tas lett, men det er heller ikke så komplisert som du kanskje tror. Det tar en forståelse av API-mønster og beste praksis for å bygge noe av ekte verdi.

Hver API må koble til serveren din for å returnere data av noe slag. Ikke bare trenger du å skrive kode for å gjøre det, men du må også formatere returdataene. Andre potensielle krav inkluderer autentisering og hastighetsbegrensning, så det er ikke sikkert å bygge en API for svakhet i hjertet.

Men la oss ta en titt på noen grunnleggende prinsipper for API-arkitekturen.

Bygg Endpoints

Et aspekt av API-utviklingen er å bygge endepunkter . Når du lager ressurser du vil bruke substantiver, ikke verb. Dette betyr at API-data skal returnere en person, sted eller ting, oftest er det en ting med bestemte attributter (for eksempel en tweet og alle dens metadata).

Det kan være vanskelig å lære å navngi substantiver, men dette er et viktig aspekt ved API-utvikling. Forenkling er best når det er mulig.

En stor debatt er singular vs plural substantiv. Hvis du lager en Twitter API, kan du ha objektgruppen først (dvs. tweet), så objektet elementet andre (dvs. tweet ID).

 $ / tweet / 15032934882934 $ / tweets / 15032934882934 

I dette tilfellet ville jeg argumentere for at det ensomme skjemaet ser bedre ut. Dette gjelder spesielt når bare én ressurs blir returnert. Men det er ingen dokumentert 100% korrekt svar, så gjør det som passer best for prosjektet ditt.

Angi returtype

En annen vurdering er retur type data . De fleste nettbrukere forventer JSON-innhold, så det er sannsynligvis det beste alternativet. XML er et annet valg hvis du ønsker å tilby begge. Men JSON er den grunnleggende API-returtypen blant webutviklere.

Det er mye mer som går inn i API-utviklingen, så jeg anbefaler å spille med APIer først. På denne måten kan du se hvordan andre utviklere bygger deres APIer, og forhåpentligvis vil du bli kjent med de typiske kravene.

Hvis du bare er i gang, vær så snill å vurdere å skumme disse dev-opplæringene:

• REST API Tutorial Site
• Skrive en enkel REST API
• Bygg en RESTful Web Service

Ytterligere ressurser

Den beste måten å lære på webapputvikling er gjennom praksis. Gitt teori er alltid verdt å studere, fordi det lar deg snakke med utviklere og forstå hvordan ting fungerer.

Men et godt sted å begynne med API-utvikling, kobler seg først til andre APIer . Lær det grunnleggende om klient-side-tilkoblinger, og derfra kan du flytte på API-utviklingen på serveren ved å lage din egen API fra begynnelsen.

Hvis det er målet ditt, kan du vurdere følgende ressurser for å hjelpe deg med reisen din.

bøker

• REST API Design Regelbok
• RESTful Web APIs
• RESTful Web Services Cookbook
• Forstyrret REST: En guide til utforming av den perfekte API

artikler

• En nybegynners guide til HTTP og REST
• Oppretter en RESTful API
• RESTful Resource Naming Guide
• Opprette en REST API ved hjelp av MEAN Stack