API 3 är ett REST API, men vad menar vi med det?

REST står för REpresentational State Transfer. Begreppet myntades av Roy Fielding, en av författarna bakom HTTP-specifikationen, det vill säga den som utgör grunden för all trafik på webben. API står för Application Programming Interface och är en generell benämning på gränssnitt som är främst tänkt för datorer att interagera mot snarare än ett gränssnitt ämnat för människor.

Ett REST API är ett sätt på vilket man bygger ett API som baseras på de funktioner som finns i HTTP (Hyper Text Transfer Protocol). Det finns många smarta funktioner i HTTP som gör att webben fungerar så bra som den gör. Tanken med REST är att utnyttja så mycket av detta som möjligt istället för att hitta på nya sätt att hantera överföringen på.

Fördelar med REST

Fördelarna med ett REST-baserat API är många. Dels så kan ett REST-API använda sig av den grundläggande strukturen för webben. Då denna struktur är välkänd för de flesta utvecklare betyder det att den är både lätt att bygga efter samt lätt att förstå.

En av grundstenarna i REST är att varje anrop ska vara ”stateless” (det är svårt att översätta men tillståndslöst beskriver det bäst) från servern. Vad det innebär är att servern ska vara helt ovetandes om tillståndet som gäller vid anropet. All information om tillståndet ska lagras på klienten. När ett anrop kommer till servern ska det utvärderas endast utifrån innehållet i anropet och utan vetskap om tidigare kommunikation. Eventuell sessions-nyckel ska finnas med i anropet. Fördelen med detta är att där kan vara många olika servrar som svarar på anropen. Klienten behöver inte veta vilken server det är som svarar så länge den får ett svar. Det är främst denna egenskap som gör det möjligt att skapa en skalbar tjänst som kan hantera tusentals samtidiga användare.

HTTP är byggt för att en rad servrar ska kunna hjälpas åt att tillhandahålla allt innehåll. I HTTP finns det inbyggt en mekanism för att ”minnas” data som överförs i olika skeden, detta kallas en cache. Det finns cache på flera olika nivåer. Servern som skapar innehållet har ibland en cache, sedan utnyttjas det mellanlagrande servrar i ett så kallat CDN (Content Delivery Network, ett innehållsleveransnätverk). På mottagarsidan kan det finnas proxy-servrar och till sist har även webbläsaren en egen cache. Dessa cache-funktioner gör det möjligt för webben att fungera på en global nivå. Genom att bygga ett REST-API gör man det möjligt att utnyttja samma cache-funktioner även för program. Detta kan mångfaldigt förbättra prestanda för både server och klient.

Teknisk beskrivning av REST

Rent tekniskt baseras REST på samma grund som HTTP. Det vill säga en URI (Uniform Resource Identifier, eller webbadress som man ofta kallar dem) och ett verb. URI:n anger vad det är som ska behandlas och verbet vad som ska utföras. Det vanligaste verbet är GET som hämtar informationen om en resurs.

Ett exempel på ett enkelt REST-API:

URI Verb Beskrivning
/produkter GET Hämtar en lista över alla produkter
/produkter POST Skapar en ny produkt
/produkter/{id} GET Hämtar en produkt med ett visst ID
/produkter/{id} PUT Ersätter all information om produkten
/produkter/{id} DELETE Raderar produkten

Trots sin enkelhet – eller kanske på grund av den – finns där dock många fallgropar. Ska man ange resursnamn i plural eller singular? Hur hanteras en sökning? Hur ska gruppering av resurser hanteras? Oftast finns det en överenskommen praxis för hur dessa löses på bästa sätt. Ett API blir lättare att förstå om det är byggt på samma sätt som andra liknande API:er.

REST är inte bundet till något specifikt programmeringsspråk, det går att skriva i vilket språk som helst. På TimeWave har vi exempelvis utvecklat i bland annat Java och PHP. Innehållsverktyget WordPress har exempelvis ett REST-API som är inbyggt.

Innehållet som överförs via REST är ofta JSON eller XML. Dessa är båda text-filer i ett speciellt format. Det som utbytes mellan server och klient är rådata som ska behandlas. Det finns ingen begränsning i format så även andra format kan användas. Det går även att bygga API:er som tar emot och hanterar bilder eller annan binär-data.

Sammanfattning

Genom att bygga REST-API:er utnyttjar man den grundstruktur som finns och som driver hela webben. Detta ger fördelar med skalbarhet då den befintliga infrastrukturen kan utnyttjas. Ett REST-API är också enkelt att förstå då alla är uppbyggda på ungefär samma sätt. Varje resurs har en URI och behandlas med hjälp av olika verb. De fördelar som finns kan även upplevas som nackdelar – detta gäller framförallt enkelheten.

Gemensam struktur baserad på HTTP
Tillståndslöst, varje anrop är komplett och kan behandlas av vilken server som helst.
Kan utnyttja den cache som hela webben bygger på.
Vilket programmeringsspråk som helst kan användas.