REST
REST
REST står för REpresentational State Transfer.
Solklart eller hur?
REST som koncept introducerades via en doktorsavhandling av Roy Fielding år 2000. Konceptet användes sedan för designen av HTTP 1.1 och URI:er.
Även om REST "uppfanns" redan år 2000 så är det först nu de senaste ca fem åren som teknologin har blivit populär och utspridd.
REST-arkitekturen
Även om implementationerna skiljer sig åt så finns det några grundprinciper inom REST som i princip alla följer.
Strikt uppdelning mellan server och klient
Ett REST-API skall inte veta någonting om vad som händer i din frontend utan levererar bara data.
REST-arkitekturen
Statelessness
Precis som att http är stateless (se http-lektionen) så skall ett system som implementerar REST också vara det.
Detta innebär att vissa teknologier som tex sessioner inte får användas i REST. Själva förfrågningen får alltså inte påverkas av andra saker som cookies eller sessionsdata utan all nödvändig information måste finnas med i http-headers och själva innehållet i förfrågningen.
REST-arkitekturen
Cacheability
REST måste vara stateless vilket underlättar cache:ning av olika resurser och data. Eftersom all information måste finnas med i själva förfrågningen så kommer alltid all information med som behövs för att bedöma om en cache:ad resurs skall levereras eller inte.
Detta betyder dock inte att cache:ning i sig är ett enkelt ämne.
REST utnyttjar http
En stor del av REST-revolutionen är att vi äntligen börjat använda hela http-specifikationen. Trots att möjligheten har funnits länge så använder äldre system ofta bara en väldigt liten del av de verktyg som finns i http-protokollet.
REST har förändrat detta och för att kunna göra REST på riktigt så krävs det en förståelse av statuskoder och de olika http-metoderna.
REST och statuskoder
Som vi har gått igenom så finns det en mängd olika statuskoder och inom REST så används många av dem flitigt.
Den stora anledningen till detta är dels att det är effektivt men också att du bara genom en statuskod ofta kan berätta för en användare vad som har hänt.
Exempel
404 - Resursen du letar efter finns inte
403 - Tillgång nekad (access denied)
500 - Någonting gick väldig fel på servern
REST och http-metoder
REST utökar användningen av http-metoderna från GET och POST till GET, POST, PUT och DELETE. Inte nog med det, varje metod får också en specifik betydelse.
GET - Hämta en eller flera resurser
POST - Skapa en ny resurs
PUT - Uppdatera en resurs
DELETE - Radera en eller flera resurser
URL-strukturer
Eftersom vi pratar om resurser inom REST så byggs URL-strukturen i REST upp runt resurser.
Om vi tex har ett kundhanteringssystem så kan en resurs vara Customer. Praxis är då att ha URL:er centrerade runt detta enligt följande:
GET kundsystem.dev/customers
Hämta alla kunder.
POST kundsystem.dev/customers
Skapa en ny kund.
DELETE kundsystem.dev/customers
Radera alla kunder.
URL-strukturer
GET kundsystem.dev/customers/1
Hämta kund med id 1.
PUT kundsystem.dev/customers/1
Uppdatera kund med id 1.
DELETE kundsystem.dev/customers/1
Radera kund med id 1.
Nästlade resurser
Resurser kan även vara nästlade under varandra. Tex så kan det vara så att varje kund har en adress och adresserna är lagrade separat.
Då blir adresser också en resurs men det är då en resurs som tillhör kunder och ligger därmed under kunder i url:en.
GET kundsystem.dev/customers/1/address
Hämta adress från kund med id 1.
PUT kundsystem.dev/customers/1/address
Uppdatera adress från kund med id 1.
DELETE kundsystem.dev/customers/1/address
Radera adress från kund med id 1.
Dataformat
Ett annat koncept inom REST är att dataformatet kan styras via http-headers. De format som brukar användas inom REST är json, xml och html.
Detta styrs då genom att skicka med tex
Accept: application/json som http-header för att deklarera att man vill ha datan i json-format.
Observera att systemet måste implementera de olika dataformaten för att detta skall vara meningsfullt.
Json dominerar numera väldigt som dataformat och är ofta det enda formatet som implementeras.
Dataformat - JSON
JavaScript Object Notation
Är ett dataformat som först skapades för javascript och därav namnet. Json är kortfattat och enkelt jämfört med många andra dataformat.
[{
"id":876,
"username":"myname",
"email":"user@example.com",
"created_at":"2012-11-05 09:25:45",
"updated_at":"2012-11-05 09:25:45"
},
{
"id":876,
"username":"myname",
"email":"user@example.com",
"created_at":"2012-11-05 09:25:45",
"updated_at":"2012-11-05 09:25:45"
}]Dataformat - XML
eXtensible Markup Language
Länge standardformatet på webben och html är en implementation av XML. XML innehåller fler möjligheter än json men XML är mycket långrandigare.
Eftersom storleken på en förfrågning spelar stor roll för hur lång tid förfrågningen tar så har XML övergetts mer och mer inom de områden där XML inte är absolut nödvändigt.
Dataformat - XML
<?xml version="1.0" encoding="UTF-8"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>REST
By marcusdalgren
REST
- 258