Gränssnitt för tillämpningsprogrammering, API: er, är ett sätt för datorprogram eller tjänster att kommunicera med varandra. Kommunikationen sker vanligtvis via en API-slutpunkt som exponeras av en applikation som en klient använder.

I den här artikeln så jämförs två populära metoder för att bygga API: er: REST API (Representational State Transfer) och Web API.

Vad är ett REST API?

I motsats till vad många tror så är REST API inte ett protokoll. Det är en arkitektur, och den mest populära arkitekturen för att utveckla API: er. Som vi förklarar i GraphQL vs REST: Everything You Need To Know så är REST statuslös, så inga data eller status lagras mellan begäranden.

REST definierar dessutom flera arkitektoniska begränsningar för att bygga applikationer som kommunicerar via HTTP:

  • Klientserver-arkitektur
  • Tillståndslöshet
  • Enhetligt gränssnitt
  • Cachelagringsbarhet
  • Skiktad systemarkitektur
  • Kod på begäran

Lättare att använda

REST är lättare att använda än andra API-protokoll eller arkitekturer. Den erbjuder dessutom många andra fördelar som gör den till förstahandsvalet för många utvecklare som bygger API: er:

  • Olika meddelandeformat: REST-API: er används oftast med JSON för serialisering av data, men fungerar med flera meddelandeformat. Detta inkluderar exempelvis JSON, HTTP, vanlig text och XML. Utbudet av alternativ ger en fördel jämfört med protokoll som SOAP (Service Object Access Protocol) som främst arbetar med XML via HTTP. Där är alternativ som JSON betydligt lättare, mer flexibla med stöd för matriser och lättare att analysera jämfört med XML.
  • HTTP-metoder: REST används vanligtvis med någon av metoderna GET, POST, PATCH, DELETE eller PUT för att hämta data och göra begäranden. Detta är beroende av tjänstens genomförande. Dessa metoder returnerar vanliga HTTP-koder för framgång och misslyckande. Andra metoder är OPTIONS, HEAD och TRACE. De är inkonsekventa bland tjänsterna eftersom vissa leverantörer kanske bara tillämpar en enda metod beroende på deras behov.
  • Avkopplad arkitektur: REST har en klientserver-arkitektur. Som ett resultat så är logiken separerad från presentationen – flera delar kan bearbetas samtidigt utan störningar.
  • Skalbarhet: REST API: er är enkla, och är därför okomplicerade att använda. Men om du behöver skala upp så kan du skapa nya slutpunkter för att införliva en mer komplex logik.
  • Cachelagring: Även om REST är tillståndslös så kan serversvaret på klienten cachelagras för att undvika att upprepa överflödiga begäranden. Serversvaret ger vanligtvis information om hur cachelagring ska utföras – och klienten cachelagrar begäranden under en viss period.
  • Säkerhet: I de flesta fall så exponeras REST-slutpunkter via HTTPS-slutpunkter. Som ett resultat så garanteras det att all API-kommunikation är säkrad med TLS/SSL. REST stöder dessutom andra auktoriserings- och autentiseringsscheman, som OAuth2 och JSON Web Tokens (JWT).

Vad är ett webb-API?

Ett webb-API är helt enkelt ett gränssnitt för att få tillgång till serverresurser via HTTP. Termen hänvisar till konceptet snarare än till någon specifik teknik. Ett webb-API kan nämligen byggas med olika tekniker, som Java och ASP.NET. Webb-API: er använder ett gränssnitt med öppen källkod och utnyttjar många klientenheter som webbläsare, smarttelefoner, surfplattor och bärbara datorer.

Webb-API: er genomför protokollspecifikationer med koncept som cachelagring, versionshantering och olika innehållsformat. Ett webb-API kan vara ett REST-API eller inte, beroende på hur det är uppbyggt. Webb-API: er används vanligtvis i ett distribuerat system för att tillhandahålla tjänster på olika enheter. Detta inkluderar exempelvis smartphones och bärbara datorer, och är begränsade till webbapplikationens klientsida.

Här är två exempel på allmänt använda webb-API: er:

  • Google API: Dessa inkluderar YouTube API: er. Som ett resultat så blir det möjligt för utvecklare att bädda in YouTube-videor i sina tillämpningar, exempelvis webbplatser, och Google Maps API. Det senare gör det möjligt för utvecklare att använda eller bädda in Google Maps på webbsidor med hjälp av JavaScript- eller Flash-gränssnitt.
  • Twitter API: er: Dessa inkluderar Twitter search API, som tillhandahåller metoder för att interagera med Twitter search, och REST API, som gör det möjligt att få tillgång till centrala Twitter-data.

Interaktion mellan system till system

Ett webb-API utförs som en interaktion mellan system till system. Så här kan data inom ett sådant API flöda:

  1. Klientenheten skickar begäranden till webbservern.
  2. Webbservern tar emot begärandet, bearbetar detta och skickar sedan tillbaka det till klientenheten för att utföras.
  3. Resultatet visas för användaren.

De fördelaktiga funktionerna hos webbaserade API: er är bland annat följande:

  • Lättviktsarkitektur: Web-API: er är utmärkta på enheter med begränsad bandbredd, t.ex. smarttelefoner.
  • Beskrivande meddelandehuvuden: Web-API: er har beskrivande meddelandehuvuden, som kan innehålla information om innehållstyp, säkerhetsschema eller hur cachelagring ska hanteras.
  • Stöd för alla datatyper: En webb API-kropp kan användas för vad som helst, inklusive binära filer (videor, bilder, dokument), vanlig XML, JSON och HTML.
  • Resursorienterad tjänst: Ett webb-API kan exponera resurser på ett sätt som överensstämmer med REST-arkitekturen.
  • Enkel konfiguration och installation: Webb-API: er är lätta att konfigurera och köra.

Webb-API jämfört med REST-API

Låt oss nu jämföra dessa två API: er mer i detalj.

Likheter i arkitekturen

Webb- och REST-API: er har vissa arkitektoniska likheter – låt oss ta en titt på dem.

  • Tillståndslöshet: HTTP-förfrågningar sker isolerat och är i grunden tillståndslösa. Varje begäran innehåller nämligen tillräckligt med information för att slutföra den. Flera begäranden är endast kopplade till varandra genom delad information, exempelvis cookies eller ett sessions-ID. Avsaknaden av tillståndssynkronisering minskar komplexiteten och ökar prestandan. Servern behöver nämligen inte hålla reda på klient-begäranden. Samtida begäranden kan dessuom skalas över flera servrar.
  • Arkitektur i lager: Båda stöder en skiktad arkitekturdesign där API-utplacering, autentisering av förfrågningar och lagring kan ske på flera servrar.
  • Resursorienterad: I resursorienterade arkitekturer så mappas resurser till URI:er (Uniform Resource Identifiers). Både webb- och REST-API: er är resursorienterade eftersom de exponerar resurser via URI: er.
  • cachelagringsbarhet: I REST- och webb-API: er lagras begäranden som ger samma information varje gång som de anropas. Ett OPTION-anrop på en slutpunkt kommer exempelvis att lagras i cacheminnet eftersom resultatet är detsamma oavsett hur många gånger det anropas. Den här egenskapen, känd som idempotens, är en bra grund för att avgöra när data kan cachelagras. Idempotence beaktas alltid i REST, men inte lika mycket i webb-API: er. Ett idempotent API-anrop är ett anrop där resultaten aldrig kommer att ändras – oavsett hur många gånger som det anropas. Detta gäller även om det finns en möjlighet att något ändras på servern. Exempel på idempotenta metoder är GET, HEAD och OPTIONS.

Skillnader i arkitekturen

Web-API: er och REST-API: er har liknande arkitekturmönster, men de har även några viktiga skillnader.

  • Samordning på klient- och serversidan: REST-API: er har en löst kopplad arkitektur som möjliggör oberoende utveckling på klient- och serversidan. Med webbaserade API: er så är ändringarna mellan klient och server exempelvis mer noggrant samordnade.
  • Gränssnitt: Beroende på detaljerna i genomförandet så tenderar REST-API: er att använda branschstandardgränssnitt. Web-API: er använder istället anpassade gränssnitt, beroende på API-leverantören.

Kommunikation

Webb-API: er är tillräckligt flexibla för att utnyttja alla kommunikationsstilar, medan REST-API: er främst används med JSON, XML och klartext. Dessa alternativ innebär att REST-API: er fungerar bra för överföring av textdata. Det inkluderar exempelvis skapande, läsning, uppdatering och radering (CRUD) mot en databas. De är dock mer restriktiva när det gäller binära data.

Webb-API: er ger en mycket bättre upplevelse för tjänster som kräver binära data – som exempelvis musik- eller videostreamingtjänster. De stöder nämligen fler meddelandeformat.

Användningsområden

Även om dessa API-format är utbytbara i många fall så finns det några scenarier där det ena är bättre än det andra:

  • Molntjänster och applikationer: På grund av sin tillståndslösa natur så används REST API: er i molntjänster. Tillståndslösa komponenter kan nämligen skalas och omdisponeras för att ta hänsyn till förändringar. Molntjänster och mätvärden exponeras vanligtvis bäst som REST API: er eftersom det finns ett litet behov av anpassad kod.
  • Strömningstjänster: Webb-API: er har bättre stöd och låg overhead för tillämpning av binära data på enheter med begränsat minne eller begränsad bandbredd. Som ett resultat så är de bäst för tjänster som kräver streaming.
  • Databashantering (CRUD): Det är enklare och lättare att exponera CRUD-funktioner via ett REST API än ett webb API.

REST API: er är svåra att hantera för komplexa begäranden som behöver få tillgång till resurser som inte är ordnade i en enkel hierarki. Detta beror på att dess URI: er hänvisar till resurser, vilket innebär att hanteringen av denna typ av situation innebär att man måste manipulera URI-router, begärande-parametrar och begärande-kroppen. Som ett resultat så motverkas syftet med REST. I det här fallet så är ett webb-API att föredra eftersom det tillåter anpassning och har omfattande stöd för URI-svar och begärande-huvuden.

Med stöd för tekniker som asynkrona anrop – som inte är lätta att implementera med hjälp av REST-arkitekturen – är webb-API: er det bästa alternativet för komplexa API-behov.

Sammanfattning

Webb- och REST-API: er används för att bygga applikationer som tillhandahåller resurser och som kommunicerar via HTTP. Medan REST beskriver arkitektoniska begränsningar över ett enhetligt gränssnitt, så är webb-API: er generellt ett koncept som kan vara RESTful, beroende på genomförandet.

Både webb- och REST-API: er är lättviktiga format som är utbytbara i många situationer. Jämfört med REST-API: er så ger dock webb-API: er en mer anpassad upplevelse och stöd för fler meddelandetyper. De stöder dessutom komplexa interaktioner mellan servrar och klienter som hanterar binära data.

Och med Kinsta’s tjänster för applikationshosting så kan du bygga, testa och skicka dina API-projekt till molnet snabbare och effektivare.

Salman Ravoof

Salman Ravoof är en självlärd webbutvecklare, författare, skapare och en stor beundrare av fri och öppen källkod (FOSS). Förutom teknik är han intresserad av vetenskap, filosofi, fotografi, konst, katter och mat. Lär dig mer om honom på hans hemsida och kontakta Salman på X.