Grunnleggende om REST og RESTful API Development

Webutviklere snakker ofte om REST prinsipper og RESTful data arkitektur, som 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 de hva snarere enn hvordan. Selv om jeg kommer til å berøre begge områdene, er dette innlegget gjort for alle som er med i webutvikling, men kan ikke forstå begrepet REST APIs.

REST For Webutviklere

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

REST er bare en serie av retningslinjer og arkitektoniske stiler som brukes til dataoverføring. Den brukes vanligvis til webapplikasjoner, men kan også sende data til programvare.

Akronym-API står for Application Programming Interface, som er metoder for koble til 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, RESTful APIs er APIer som følger REST-arkitekturen.

Hva er REST-arkitekturen??

Det er her 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
• Bruken av HTTP-statuskoder hvor det er aktuelt
• Bruken av URL-endepunkter med et logisk hierarki
• Versjonering i nettadressen heller enn 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å ovenfor listen bør ikke betraktes som raske og raske regler, selv om de er sanne for de mest moderne RESTful APIs.

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 legger det, “en API er 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 APIer

Disse tipsene er i sammenheng med APIer strengt for webapplikasjoner. Dette betyr at HTTP er et krav, og det betyr det ofte 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 hjemmeside uten personlig tilgang til den eksterne serveren (som å trekke Twitter-data).

Generelt sett er det fire kommandoer pleide å få tilgang til RESTful APIer:

1. FÅ for å hente en gjenstand
2. POST for å lage et nytt objekt
3. SETTE for å endre eller erstatte et objekt
4. SLETT for å fjerne et objekt

Hver av disse metodene skal være bestått med API-anropet å fortelle serveren hva han skal gjøre.

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

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 at FÅ metode for tilgang til ressurser. Dette kan kalles sammendrag a forbruks-bare API.

Returtyper er også viktig, og bør 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 tilgjengelig fra direkte nettadresser. Dette betyr URL-strukturen 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 likte dette innlegget grunnleggende URL-strukturer og eksempler fra andre tjenester.

Vær oppmerksom på at endepunktet er returdata vil endres dramatisk basert på HTTP-metode. For eksempel, FÅ henter innhold, mens POST skaper nytt innhold. Forespørselen kan peke til det samme endepunktet, men resultatet kan være svært forskjellig.

Å se på eksempler på nettet kan hjelpe deg med å forstå konsepter klarere. Vi så allerede Pokeapi, men her er noen andre virkelige API-eksempler å 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 å bygge noe av ekte verdi.

Hver API må Koble til serveren din å 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 godkjenning og rate begrensning, så å bygge en API er absolutt ikke for svak av hjertet.

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

Bygg Endpoints

Et aspekt av API-utviklingen er bygge endepunkter. Når skaper 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 spesifikke 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 flertall substantiver. Hvis du lager en Twitter API, kan du ha objektgruppen først (dvs. tweet), så objektobjektet andre (dvs. tweet ID).

 $ / tweet / 15032934882934 $ / tweets / 15032934882934 

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

Angi returtype

En annen vurdering er returnere type data. De fleste nettbrukere forventer JSON-innhold, så det er sannsynligvis det beste alternativet. XML er et annet valg hvis du vil 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
• Skriver en enkel REST API
• Bygg en RESTful Web Service

Ytterligere ressurser

Den beste måten å lære webapputvikling på, 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 er kobler til andre APIer først. Lær det grunnleggende om klient-side-tilkoblinger, og derfra kan du flytte på API-utviklingen på serveren ved å lage din egen API fra grunnen av.

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
• Uforstyrret 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