Vad är ett REST-API?

Av Weapp · Uppdaterad

Ett REST-API är det vanligaste sättet att bygga API:er för webben. Data ses som resurser som nås via webbadresser, och man arbetar med dem via standardverben hämta, skapa, uppdatera och ta bort. REST blev standard för att det är enkelt, cachebart och språkoberoende – vilket API som helst kan prata med det.

Öppnar du en offert eller lyssnar på ett teknikmöte dyker “REST-API” upp gång på gång, ofta som om alla redan visste vad det var. I själva verket är idén enklare än förkortningen antyder, och den är värd att förstå: REST är det överlägset vanligaste sättet att bygga API:er för webben, och nästan alla integrationer ni möter kommer att tala just det. Här är förklaringen utan onödig teknik.

Resurser och verb

Grundidén i REST är att se på data som resurser, och en resurs är helt enkelt en sak API:et hanterar: en kund, en order, en produkt. Varje resurs får en egen webbadress, på samma sätt som varje sida på en webbplats har sin adress.

För att arbeta med resurserna används ett litet, fast antal standardverb – webbens egna: hämta, skapa, uppdatera och ta bort. Kombinationen av en adress och ett verb säger allt som behövs. Hämta kunden på den här adressen. Skapa en ny order. Uppdatera den här produkten. Ta bort den där posten.

Det fina är att mönstret är så förutsägbart. Har du förstått hur en resurs fungerar har du i princip förstått alla, för de följer samma logik. Det är en stor del av varför REST känns lätt att arbeta med.

Ett läsbart exempel

Säg att ni har ett system med kunder. För att hämta en viss kund gör appen ett anrop med verbet “hämta” mot kundens adress, ungefär “hämta kund nummer 42”. Servern svarar med data om just den kunden, oftast i formatet JSON, som är läsbart även för en människa:

Vill appen i stället lägga till en ny kund använder den verbet “skapa” mot adressen för kunder och skickar med de nya uppgifterna. Vill den uppdatera en kund använder den “uppdatera” mot just den kundens adress. Samma enkla mönster hela vägen: en adress som pekar ut vad, ett verb som säger vad som ska göras, och ett svar i ett format både system och människor kan läsa.

En egenskap som gör REST förutsägbart är att varje anrop står på egna ben. Servern behöver inte minnas vad klienten frågade om förra gången – all information som behövs finns i själva anropet. Det gör att anropen kan hanteras oberoende av varandra, fördelas över flera servrar och skalas upp utan krångel. Samma egenskap är en del av varför REST-svar är lätta att spara och återanvända: ett givet anrop mot en given adress ger ett förutsägbart svar.

Varför REST blev standard

REST är inte den enda tänkbara formen, men den blev den dominerande. Tre egenskaper förklarar varför.

  • Enkelt. Mönstret med resurser, adresser och verb är litet och lätt att lära. Utvecklare känner igen det direkt, och det gör API:er snabbare och billigare att både bygga och koppla mot.
  • Cachebart. REST vilar på webbens egen infrastruktur, och den kan spara svar för att slippa hämta samma sak om och om igen. Det gör lösningar snabbare och billigare att driva, utan extra arbete.
  • Språkoberoende. Ett REST-API bryr sig inte om vilket programmeringsspråk klienten är byggd i. En app, en webb och ett annat system kan alla prata med samma API. Det gör REST till en gemensam nämnare som binder ihop olika teknik.

Tillsammans gjorde de egenskaperna REST till det naturliga förvalet för webben. När något “bara ska prata med ett API” är det oftast ett REST-API som avses.

Alternativen, kort

Det finns andra sätt att bygga API:er. GraphQL låter klienten fråga efter exakt de fält den vill ha i ett enda anrop, vilket är användbart när många olika klienter behöver olika vyer av samma data. gRPC är gjort för snabb kommunikation mellan tjänster internt, mer än mot vanliga appar.

Båda har sina lägen, men inget har trängt undan REST för vanliga webb-API:er. För de allra flesta behov är REST fortfarande både förvalet och det som räcker.

Vi på Weapp bygger REST-API:er och de integrationer som använder dem, och hjälper till att bedöma vad ett systems API betyder för era möjligheter. Vill ni förstå hur era system kan kopplas ihop? Titta på våra tjänster eller hör av dig.

Vanliga frågor

Vad står REST för?

REST står för Representational State Transfer, men namnet säger mindre än principen. Det är en stil för att bygga API:er där data behandlas som resurser man når via webbadresser och arbetar med genom webbens egna verb. Du behöver inte kunna den fullständiga termen för att förstå idén: adresser för saker, standardåtgärder för att jobba med dem.

Vad menas med resurser och verb i ett REST-API?

En resurs är en sak API:et hanterar, till exempel en kund eller en order, och varje resurs har en egen webbadress. Verben är standardåtgärderna: hämta, skapa, uppdatera och ta bort. Kombinationen av en adress och ett verb säger allt – hämta den här kunden, skapa en ny order. Det är ett litet, förutsägbart mönster som återkommer överallt.

Vad är skillnaden mellan REST och JSON?

De hör ihop men är olika saker. REST är sättet att strukturera API:et – resurser, adresser och verb. JSON är formatet datan oftast skickas i, ett läsbart sätt att skriva ner information. Ett REST-API använder nästan alltid JSON för svaren, men JSON kan användas i många andra sammanhang också. REST är strukturen, JSON är förpackningen.

Vad är alternativen till REST?

De vanligaste är GraphQL och gRPC. GraphQL låter klienten fråga efter exakt de fält den vill ha i ett anrop, vilket passar när många olika klienter behöver olika datavyer. gRPC är byggt för snabb kommunikation mellan tjänster internt. Båda har sina fall, men REST är fortfarande förvalet för de flesta webb-API:er tack vare sin enkelhet.

Behöver jag ett REST-API för min produkt?

Nästan alltid, om produkten har en app eller webb som hämtar data från en server. REST är standardsättet att låta den kommunikationen ske, och det mesta ni kopplar mot kommer att erbjuda ett REST-API. Ni behöver inte kunna bygga det själva, men det är bra att veta att det oftast är den form era integrationer kommer att tala.