Aftonbladet & Schibsted på väg

Omvärldsbevakning och direktrapportering från fältet

Startsida / Inlägg

Time to REST!

av Erik Fried

Under onsdagen var jag på ett par bra dragningar om REST (REpresentational State Transfer) som är det sätt som ”alla” bygger sina API:er på idag. Eller åtminstone påstår att man bygger sina API:er på. Nåväl jag ska inte orera om missuppfattningar om REST.

Vad jag dock kan konstatera är att ett centralt begrepp, som jag knappast sett ”in the wild” är HATEOAS (Hypermedia As The Engine Of Application State). Jim Webber förklarar dock föredömligt pedagogiskt vad det handlar om. Utgående från det självklara i hur vi som människor genom vår browser navigerar genom ett checkout-flöde på typ amazon. När vi börjar vår utcheckning gör vi det genom att följa en hyperlänk. Vi vet i det läget inte vart vi senare kommer navigera, men vi får hjälp från applikationen genom att vi förses med länkar genom t ex anchor-taggar eller form targets som för oss människor (förhoppningsvis) har en uppenbar semantik. Typ vi ser våra varor och när vi klickar på knappen ”betala” förväntar vi oss att komma till en sida där vi… betalar. Inget konstigt – HATEOAS. Samma tankesätt kan generaliseras till att även omfatta maskin-till-maskin kommunikation, där dock länkarnas semantiska innebörd måste formaliseras.

En annan sak som Jim Webber uppenbarligen brinner för är att omfamna HTTP som det applikationsprotokoll det faktiskt är. Mer specifikt ett applikationsprotokoll inom domänen att skyffla runt dokument på internet.

Det vi gör när vi då navigerar mellan dessa resurser som pekas ut av länkar är att vi skickar och tar emot dokument. Allt som verkligen händer med våra domänobjekt är sidoeffekter av att dokumenten skyfflas runt. Det behöver INTE råda en ett-till-ett relation mellan resurser och domänobjekt!

Ian Robinson pratar senare om Test-Driven Rest. Inte helt förvånande använder han i mycket samma analogier som Jim Webber (de har skrivit boken Rest in Practice tillsammans).

Ian har dock en kort lista på saker som kan vara bra att testa isolerat när man testar sitt REST API:

  • Att HTTP interaktionen går som den ska. Att man får rätt responskoder och headers etc.
  • Att interaktionen med underliggande domänrepresentationer sker som den ska.
  • Att rätt responser ges på rätt format.
  • Och att hypermedia dyker upp som det ska, ledtrådar till vad som kan göras härnäst.
En sak att se upp med är att man lätt kan hamna i att man har en mass URI:er eller fragment av URI:er spridda på massa ställen i sin kod -> Svårt att genomföra ändringar av URI mönster.

Information

Denna blogg är inte längre aktiv. För en lista på aktiva bloggar, gå till bloggar.aftonbladet.se.

Sök

Arkiv

Kategorier

  • Tjänstgörande redaktörer: Love Isakson Svensén, Filip Elofsson och Fred Balke
  • Chefredaktör, vd och ansvarig utgivare: Lotta Folcker
  • Stf ansvarig utgivare: Martin Schori
  • Redaktionschef: Karin Schmidt
  • Besöksadress: Västra Järnvägsgatan 21, Stockholm
  • Org.nr: 556100-1123
  • Momsregistreringsnr: SE 556100-112301
  • Kontakt: förnamn.efternamn@aftonbladet.se
  • Aftonbladet Plus Kundcenter: tipsa@aftonbladet.se
  • Telefon växel: 08 725 20 00
  • FÖLJ OSS

© Aftonbladet Hierta AB