Programmeringsgrænseflader (API’er) er en måde, hvorpå computerprogrammer eller tjenester kan kommunikere med hinanden. Denne kommunikation foregår normalt via et API-endpoint, der udstilles af et program, som en klient bruger.

I denne artikel sammenlignes to populære tilgange til opbygning af API’er: REST API (Representational State Transfer) og Web API.

Hvad er en REST API?

I modsætning til hvad mange tror, er REST API ikke en protokol. Det er en arkitektur, og det er den mest populære arkitektur til udvikling af API’er. Som vi forklarer i GraphQL vs REST: Everything You Need To Know, er REST stateless, så der gemmes ingen data eller status mellem anmodninger.

REST definerer også flere arkitektoniske begrænsninger for opbygning af applikationer, der kommunikerer via HTTP:

  • Klient-server-arkitektur
  • Statelessness
  • Ensartet grænseflade
  • Cachelagring
  • Systemarkitektur i flere lag
  • Kode efter behov

REST er lettere at bruge end andre API-protokoller eller -arkitekturer. Den har også mange andre fordele, der gør den til det første valg for mange udviklere, der udvikler API’er:

  • Forskellige beskedformater: REST-API’er anvendes oftest med JSON til serialisering af data, men fungerer med flere beskedformater, herunder JSON, HTTP, almindelig tekst og XML. Denne vifte af muligheder giver den en fordel i forhold til protokoller som SOAP (Service Object Access Protocol), der primært arbejder med XML over HTTP, idet muligheder som JSON er betydeligt lettere, mere fleksible med understøttelse af arrays og lettere at analysere sammenlignet med XML.
  • HTTP-metoder: REST anvendes typisk med en af metoderne GET, POST, PATCH, DELETE eller PUT til at hente data og foretage anmodninger, afhængigt af tjenesteimplementeringen. Disse metoder returnerer almindelige HTTP-succes- og fejlkoder. Andre metoder omfatter OPTIONS, HEAD og TRACE. Disse metoder er inkonsekvente blandt tjenesterne, da nogle udbydere måske kun implementerer en enkelt metode efter deres behov.
  • Afkoblet arkitektur: REST har en klient-server-arkitektur, så logikken er adskilt fra præsentationen – der kan arbejdes på flere dele samtidig uden at det griber ind i hinanden.
  • Skalerbarhed: REST API’er er enkle, hvilket gør dem ukomplicerede at bruge. Men hvis du har brug for at skalere op, kan du oprette nye endpoints for at inkorporere mere kompleks logik.
  • Cachelagbarhed: REST er stateless, men serverens svar på klienten kan lagres i cachen for at undgå gentagelse af overflødige anmodninger. Serverresponset giver normalt oplysninger om, hvordan caching skal udføres – med klienten, der cacher anmodninger i en given periode.
  • Sikkerhed: I de fleste tilfælde er REST-endpoints eksponeret via HTTPS-endpoints, hvilket sikrer, at al API-kommunikation er sikret ved hjælp af TLS/SSL. REST understøtter også andre autorisations- og godkendelsesordninger, såsom OAuth2 og JSON Web Tokens (JWT).

Hvad er et web-API?

Et web-API er ganske enkelt en grænseflade til at få adgang til serverressourcer via HTTP. Udtrykket henviser til konceptet snarere end til en specifik teknologi – et web-API kan opbygges med forskellige teknologier, f.eks. Java og ASP.NET. Web-API’er anvender en grænseflade med åben kildekode og udnytter mange klientenheder som browsere, smartphones, tablets og bærbare computere.

Web-API’er implementerer protokolspecifikationer med koncepter som caching, versionering og forskellige indholdsformater. Et web-API kan være et REST-API eller ej, afhængigt af hvordan det er opbygget. Web-API’er bruges normalt på et distribueret system til at levere tjenester på forskellige enheder, f.eks. smartphones og bærbare computere, og er begrænset til webapplikationens klientside.

Her er to eksempler på meget anvendte web-API’er:

  • Google API’er: Disse omfatter YouTube API’er, som gør det muligt for udviklere at integrere YouTube-videoer i deres applikationer, f.eks. websteder, og Google Maps API, som gør det muligt for udviklere at bruge eller integrere Google Maps på websider ved hjælp af JavaScript- eller Flash-grænseflader.
  • Twitter API’er: Disse omfatter Twitter-søge-API’en, som giver metoder til at interagere med Twitter-søgning, og REST-API’en, som giver adgang til centrale Twitter-data.

En web-API udføres som en interaktion mellem systemer. Sådan kan dataene i et sådant API flyde:

  1. Klientenheden sender anmodninger til webserveren.
  2. Webserveren modtager anmodningen, behandler den og sender den derefter tilbage til klientenheden, så den kan blive udført.
  3. Output vises til brugeren.

De fordelagtige funktioner ved web-API’er omfatter:

  • Letvægtsarkitektur: Web-API’er udmærker sig på enheder med begrænset båndbredde, f.eks. smartphones.
  • Beskrivende meddelelsesoverskrifter: Web-API’er har beskrivende meddelelsesoverskrifter, som kan indeholde oplysninger om indholdstype, sikkerhedsordning eller hvordan caching skal håndteres.
  • Understøtter alle datatyper: Kroppen af et web-API kan bruges til alt, herunder binære filer (videoer, billeder, dokumenter), almindelig XML, JSON og HTML.
  • Ressourceorienteret tjeneste: En web-API kan udstille ressourcer på en måde, der er i overensstemmelse med REST-arkitekturen.
  • Nem konfiguration og opsætning: Web-API’er er nemme at konfigurere og køre.

Web-API vs. REST-API

Lad os nu sammenligne disse to API’er mere detaljeret.

Ligheder i arkitekturen

Web- og REST-API’er har nogle arkitektoniske ligheder – lad os se nærmere på dem.

  • Statelessness: HTTP-forespørgsler sker isoleret og er grundlæggende stateless, da hver forespørgsel indeholder tilstrækkelige oplysninger til at gennemføre den. Flere anmodninger er kun forbundet med hinanden via delte oplysninger, f.eks. cookies eller et sessions-id. Fraværet af tilstandssynkronisering reducerer kompleksiteten og øger ydelsen, da serveren ikke behøver at holde styr på klientforespørgsler. Samtidige anmodninger kan også skaleres på tværs af flere servere.
  • Lagdelt arkitektur: De understøtter begge et lagdelt arkitekturdesign, hvor API-implementering, anmodningsautentificering og lagring kan ske på tværs af flere servere.
  • Ressourceorienteret: I ressourceorienterede arkitekturer er ressourcerne afbildet til URI’er (Uniform Resource Identifiers). Både web- og REST-API’er er ressourceorienterede, da de eksponerer ressourcer via URI’er.
  • Cachelagring: I REST- og web-API’er lagres forespørgsler, der returnerer de samme oplysninger hver gang de kaldes, i cache. F.eks. vil et OPTION-opkald på et endpoint blive lagret i cachen, da resultatet er det samme, uanset hvor mange gange det kaldes. Denne egenskab, kendt som idempotens, er et godt grundlag for at bestemme, hvornår data kan cachelagres. Idempotence tages altid i betragtning i REST, men ikke nær så meget i web-API’er. Et idempotent API-kald er et kald, hvor resultaterne aldrig vil ændre sig – uanset hvor mange gange det kaldes – selv med muligheden for at noget ændres på serveren. Eksempler på idempotente metoder omfatter GET, HEAD og OPTIONS.

Forskelle i arkitekturen

Selv om web-API’er og REST-API’er har lignende arkitektoniske mønstre, har de også nogle vigtige forskelle.

  • Koordinering på klient- og serversiden: REST-API’er har en løst koblet arkitektur, der giver mulighed for uafhængig udvikling på klient- og serversiden. Med web-API’er er ændringer mellem klient og server mere fint koordineret.
  • Grænseflade: Afhængigt af implementeringsdetaljerne har REST-API’er tendens til at anvende industristandardgrænseflader. Web-API’er bruger tilpassede grænseflader, afhængigt af API-udbyderen.

Kommunikation

Web-API’er er fleksible nok til at udnytte enhver kommunikationsstil, mens REST-API’er primært anvendes med JSON, XML og almindelig tekst. Disse muligheder betyder, at REST-API’er fungerer godt til tekstdataoverførsel, f.eks. oprettelse, læsning, opdatering og sletning (CRUD-operationer) mod en database, men er mere restriktive, når det drejer sig om binære data.

Web-API’er giver en langt bedre oplevelse for tjenester, der kræver binære data – som f.eks. musik- eller videostreaming-tjenester – da de understøtter flere beskedformater.

Anvendelsestilfælde

Selv om disse API-formater er indbyrdes udskiftelige i mange tilfælde, er der nogle få scenarier, hvor det ene er bedre end det andet:

  • Cloud-tjenester og -applikationer: På grund af deres tilstandsløse karakter anvendes REST API’er i cloud-tjenester, da tilstandsløse komponenter kan skaleres og omdisponeres for at imødekomme ændringer. Cloud-tjenester og -metrikker eksponeres normalt bedst som REST API’er, da der er begrænset behov for brugerdefineret kode.
  • Streaming-tjenester: Web-API’er har bedre understøttelse og lavt overhead for anvendelse af binære data på enheder med begrænset hukommelse eller båndbredde, så de er bedst til tjenester, der kræver streaming.
  • Databasemanipulation (CRUD): Det er enklere og nemmere at udsætte CRUD-funktionalitet over et REST API end et web API.

REST API’er er vanskelige at administrere for komplekse anmodninger, der skal have adgang til ressourcer, der ikke er arrangeret i et simpelt hierarki. Dette skyldes, at det er URI’er, der henviser til ressourcer, hvilket betyder, at håndtering af denne slags situationer indebærer manipulation af URI-stier, forespørgselsparametre og forespørgselskroppen, hvilket modvirker formålet med REST. I dette tilfælde foretrækkes et web-API, fordi det giver mulighed for tilpasning og har omfattende understøttelse af URI-svar og response headers.

Med understøttelse af teknikker som asynkrone opkald – som ikke let kan implementeres ved hjælp af REST-arkitekturen – er web-API’er den rette løsning til komplekse API-behov.

Opsummering

Web- og REST-API’er bruges til at opbygge applikationer, der leverer ressourcer og kommunikerer via HTTP. Mens REST beskriver arkitektoniske begrænsninger over en ensartet grænseflade, er web-API’er generelt et koncept, der kan være RESTful, afhængigt af implementeringen.

Både web- og REST-API’er er lette formater, som kan udskiftes i mange situationer. I forhold til REST-API’er giver web-API’er imidlertid en mere tilpasset oplevelse og understøttelse af flere meddelelsestyper, og de understøtter komplekse interaktioner mellem servere og klienter, der håndterer binære data.

Og med Kinstas applikationshostingtjenester kan du bygge, teste og sende dine API-projekter til skyen hurtigere og mere effektivt.

Salman Ravoof

Han er en selvlært webudvikler, skribent, skaber og en stor beundrer af Free and Open Source Software (FOSS). Udover teknologi, er han begejstret for videnskab, filosofi, fotografi, kunst, katte og mad. Lær mere om ham på hans hjemmeside, og kontakt Salman på X.