Grundlæggende om REST og RESTful API Development

Webudviklere taler ofte om REST principper og RESTful data arkitektur, da det er et afgørende aspekt af moderne udvikling, men det kan nogle gange være utroligt forvirrende. REST er ikke en teknologi i sig selv, men snarere en metode til oprettelse af API'er med bestemte organisatoriske principper. Disse principper er at guide udviklere og skabe et mere universelt miljø til behandling af API-anmodninger.

I dette indlæg vil jeg gerne forklare RESTful udviklingspraksis fra en fugleperspektiv. Jeg vil tackle det hvad snarere end hvordan. Selv om jeg kommer på begge områder, er dette indlæg lavet til alle, der er involveret i webudvikling, men kan bare ikke forstå begrebet REST API'er.

REST For Webudviklere

Akronymet REST står for Repræsentativ statsoverførsel. Dette kan måske være lidt forvirrende, og wiki-indgangen gør det lyst endnu mere forvirrende. Men det er muligt at forenkle terminologien.

REST er bare en serie af retningslinjer og arkitektoniske stilarter til dataoverførsel. Det er almindeligt anvendt til webapplikationer, men kan også overføre data til software.

Akronym API står for Application Programming Interface, som er metoder til forbinder med andre biblioteker eller applikationer. Windows har flere API'er, og Twitter har også en web-API, selvom de udfører forskellige opgaver med forskellige mål.

Kombinerer det hele sammen, er RESTful API'er API'er, der følger REST-arkitekturen.

Hvad er det nøjagtigt REST-arkitekturen?

Det er her, hvor det er svært at fastsætte specifikationer. Men der er nogle arkitektoniske konstanter, såsom:

• Konsistens på tværs af hele API'en
• Statsløs eksistens, dvs. ingen server-side sessioner
• Anvendelse af HTTP-statuskoder Hvor det er passende
• Anvendelse af URL-endepunkter med et logisk hierarki
• Versioning i webadressen snarere end i HTTP-overskrifter

Der er ikke nogen alt for specifikke retningslinjer som W3C HTML5 spec, som kan føre til forvirring og en usikkerhed omkring REST-terminologi.

Også ovenstående liste bør ikke betragtes som hårde og hurtige regler, selv om de er sande for de fleste moderne RESTful API'er.

REST er en letvægtsmetode hvilket gør den perfekt til HTTP-data. Det er derfor, REST blev så populært på internettet, og hvorfor det er bredt betragtet som det bedste valg til API-udvikling.

Som Vinay Sahni sætter det, “en API er en udviklerens brugergrænseflade.” Alt skal være nemt at bruge, og give en god brugeroplevelse. RESTful API'er sigter mod at gøre netop det.

Nøgleaktioner til RESTful API'er

Disse tip er i forbindelse med API'er strengt for webapplikationer. Det betyder at HTTP er et krav, og det betyder ofte det API-dataene er hostet på en ekstern server. Lad os undersøge, hvordan RESTful API'er arbejder på siden af ​​API-brugeren.

API-brugeren er webudvikleren, som kan opbygge et script, der forbinder til en ekstern API-server, så de nødvendige data sendes over HTTP. Udvikleren kan derefter vise data på deres hjemmeside uden at have personlig adgang til den eksterne server (som at trække Twitter-data).

Generelt er der fire kommandoer plejede Få adgang til RESTful API'er:

1. FÅ for at hente et objekt
2. STOLPE for at oprette en ny genstand
3. SÆTTE til ændring eller udskiftning af et objekt
4. SLET for at fjerne et objekt

Hver af disse metoder bør være bestået med API-opkaldet at fortælle serveren, hvad de skal gøre.

Langt de fleste web-API'er Tillad kun FÅ anmodninger at trække data ud fra en ekstern server. Autentificering er valgfri, men bestemt en god ide, når man tillader potentielt skadelige kommandoer som SÆTTE eller SLET.

Men ikke mange RESTful API'er går selv så langt. Overvej Pokéapi, som er en gratis Pokémon API-database. Den er åben for offentligheden med anstændig takstbegrænsning (begrænser brugerne til et vist antal API-anmodninger over en periode), men tillader kun FÅ metode til adgang til ressourcer. Dette kan i dagligdagen betegnes a API-forbrug alene.

Returtyper er også vigtige, og bør bibeholde homogenitet for alle ressourcer. JSON er en populær returtype med online-specifikationer, der forklarer korrekte datastrukturer.

RESTful API'er bruger navneord for API objekter, og verb for at udføre handlinger på disse genstande. Autentificering kan være en del af dette, takstbegrænsning kan også være en del af dette. Men en meget enkel API kan komme uden meget bekymring for brugerbegrænsninger.

Adgang til API-ressourcer

Offentlige API'er er typisk tilgængelig fra direkte webadresser. Det betyder URL-strukturen er vigtig, og bør kun bruges til API-anmodninger.

Nogle webadresser kan indeholde en præfiks mappe som / V2 / for en opdateret version 2 af en tidligere API. Dette er almindeligt for udviklere, der ikke vil afskrive deres 1.x API, men vil stadig tilbyde den nyeste struktur.

Jeg nød virkelig denne postdækning grundlæggende URL strukturer og eksempler fra andre tjenester.

Bemærk at endepunktet er Returdata ændres dramatisk baseret på HTTP-metode. For eksempel, FÅ henter indhold, mens STOLPE skaber nyt indhold. Forespørgslen kan pege på det samme endepunkt, men resultatet kan være meget anderledes.

Hvis du ser på eksempler online, kan du hjælpe dig med at forstå begreber klarere. Vi har allerede set Pokeapi, men her er nogle andre real-world API eksempler at gennemgå:

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

Opbyg din egen API

Processen med at opbygge din egen API bør ikke tages let, men det er heller ikke så kompliceret, som du måske tror. Det tager en forståelse af API design mønstre og bedste praksis at bygge noget af reel værdi.

Hver API skal Opret forbindelse til din server at returnere data af en eller anden art. Ikke alene skal du skrive kode for at gøre det, men du skal også formatere returdataene. Andre potentielle krav omfatter Godkendelse og satsbegrænsning, så at opbygge en API er bestemt ikke for svag af hjertet.

Men lad os tage et kig på nogle grundlæggende principper af API-arkitekturen.

Byg endepunkter

Et aspekt af API udvikling er bygge endepunkter. Hvornår skabe ressourcer du vil bruge navneord, ikke verb. Dette betyder, at API-data skal returnere en person, sted eller ting, oftest er det en ting med specifikke attributter (for eksempel en tweet og alle dens metadata).

Det kan være svært at lære at navngive navneord, men dette er et afgørende aspekt af API-udvikling. Forenkling er bedst, når det er muligt.

En stor debat er singular vs plural substantiver. Hvis du lavede et Twitter API, kan du have objektgruppen først (dvs. tweet), så objektobjektet andet (dvs. tweet ID).

 $ / tweet / 15032934882934 $ / tweets / 15032934882934 

I dette tilfælde vil jeg argumentere for den entalform, der ser bedre ud. Dette gælder især når kun en ressource bliver returneret. Men der er ikke dokumenteret 100% korrekt svar, så gør det, der passer bedst til dit projekt.

Indstil Returtype

En anden overvejelse er returnere type data. De fleste webbrugere forventer JSON-indhold, så det er sandsynligvis den bedste løsning. XML er et andet valg, hvis du vil tilbyde begge. Men JSON er den grundlæggende API-returtype blandt webudviklere.

Der er meget mere, der går ind i API-udvikling, så jeg anbefaler først at spille med API'er. På denne måde kan du se, hvordan andre udviklere bygger deres API'er, og forhåbentlig bliver du fortrolig med de typiske krav.

Hvis du lige er begyndt, skal du overveje at skumme disse dev tutorials:

• REST API Tutorial Site
• Skrive en enkel REST API
• Opbygning af en RESTful Web Service

Yderligere ressourcer

Den bedste måde at lære webappudvikling på er via praksis. Bevilget teori er altid værd at studere, fordi det giver dig mulighed for at snakke med udviklere og forstå, hvordan tingene virker.

Men et godt sted at starte med API udvikling er forbinder til andre API'er først. Lær det grundlæggende ved klient-side-forbindelser, og derfra kan du flytte til API-udvikling på server-side ved at oprette din egen API fra bunden.

Hvis det er dit mål, skal du overveje følgende ressourcer for at hjælpe med på din rejse.

Bøger

• REST API Design Regelbog
• RESTful Web APIs
• RESTful Web Services Cookbook
• Uforstyrret REST: En guide til design af den perfekte API

Artikler

• En nybegyndervejledning til HTTP og REST
• Oprettelse af en RESTful API
• RESTful Ressource Naming Guide
• Oprettelse af en REST API ved hjælp af MEAN Stack