REST API’s¶
REST web-API’s volgen een bepaalde stijl die aansluit bij de principes (architectuur) van het web. Als je deze stijl kent, kun je redelijk snel begrijpen hoe een bepaald API in deze stijl werkt.
Naast REST zijn er ook andere stijlen van web-API’s in gebruik, zoals RPC (remote procedure call) of SOAP (???). Tegenwoordig wint de GraphQL-stijl aan populariteit. Daarmee kun je wat preciezer aangeven welke data je wilt ophalen via de API.
REST¶
REST staat voor Representational State Transfer. (REF - wikipedia) Dit is gebaseerd op het volgende model van het web:
resource: dit is de web-term voor “ding”; dit kan zowel een concreet iets zijn, zoals een lamp; een persoon, zoals Rembrandt; of een abstract idee, zoals democratie.
URI en URL: een resource kun je identificeren met een URI (uniform resource identifier) of een URL (uniform resource locator). Deze identificaties zijn context-onafhankelijk: overal waar je deze gebruikt heeft deze dezelfde betekenis. Het voordeel van een URL is dat deze ook aangeeft waar je meer over de resource kunt vinden.
voor gewone namen is dat niet het geval: de betekenis daarvan hangt sterk af van de context.
toestand (state) van een resource: een resource heeft een toestand. Deze toestand kun je beschrijven (“representeren”) door middel van een document, bijvoorbeeld (in de context van het web) een HTML-document of een JSON-document. Bij een resource kun je verschillende documenten hebben die de toestand beschrijven, afhnakelijk van de wensen van de gebruiker (bijvoorbeeld: HTML, in het Engels of in het Nederladnds; of JSON).
door middel van een document (-aanpassing) kun je de toestand van de resource veranderen - als dat mogelijk is via dit interface.
HTTP-methods: met behulp van de verschillende HTTP-methods kun je de toestand van een resource opvragen, aanpassen, een resource aanmaken of verwijderen. Daarbij is het belangrijk dat je de recht doet aan de normale betekenis van de HTTP-methods, zoals
GET
voor het opvragen van de toestand.
Eigenschappen HTTP methods¶
In een REST API houd je rekening met de betekenis en eigenschappen van de HTTP-methods. (Er is niets dat dit gebruik afdwingt, maar dit zijn wel de aannames die overal in de web-infrastructuur gebruikt worden.)
GET: idempotent; geen verandering in toestand van de resource
POST: niet idempotent; (mogelijk) verandering in de toestand van de resource
PUT: idempotent; verandering in de toestand
DELETE: idempotent; verandering in de toestand
Eén van de gevolgen is dat je eenzelfde GET-operaties zonder problemen kunt herhalen.
Voor een POST is dat niet het geval: de browser vraagt daarom bijvoorbeeld of je de opdracht nog een keer wilt uitvoeren. Het nogmaals opsturen van een formulier kan bijvoorbeeld betekenen dat je het artkel nog een keer bestelt.
De PUT
en DELETE
operaties zijn wel idempotent.
idempotent: (tegen)voorbeelden
i := 10
is idempotent en verandert de waarde (toestand) vani
i := i + 1
verandert de waarde vani
op een niet-idempotente manier.op een afstandsbediening is het kiezen van NPO-1 idempotent,
en het zappen naar de volgende zender niet idempotent
Idempotente operaties zijn vooral handig is de communicatie niet volledig betrouwbaar is (zoals in het web): als je niet weet of een bericht overgekomen is, kun je dat zonder risico nog een keer sturen.
Nog een voorbeeld: een bediening van een lamp met twee knoppen, “aan” en “uit”, is idempotent. Dit soort knoppen vind je vaak bij IoT-apparaten, waarbij het niet altijd duidelijk is of een bericht niet aangekomen is, of dat de verwerking wat langer duurt dan je verwacht.
Collecties van resources¶
Vaak heb je te maken met een collectie van soortgelijke resources waarbinnen je de individuele resources wilt kunnen onderscheiden. Een gebruikelijke manier is om de verzameling een naam te geven, en de elementen daarin een nummer als identificatie.
We gebruiken hier als naam voor een verzameling het meervoud, dus bijvoorbeeld: lists
, of cards
.
Een bepaalde lijst geven we dan bijvoorbeeld aan als: lists/53
, een kaart als cards/92
. Een kaart als onderdeel van een lijst: lists/53/cards/11
. Dit laatste is een voorbeeld van een geneste resource.
Sommige web-API’s gebruiken enkelvoud in plaats van meervoud voor het benoemen van een collectie. Trello accepteert zowel meervoud (volgens de documentatie) als enkelvoud (als alternatief).
Voorbeeld: lamp aan- en uitschakelen¶
Voor het aansturen van een lamp kun je de volgende API gebruiken:
URL:
/lamps/17
- dit is de identificatie van de lamp (pad-gedeelte van de URL)
Opmerking: in dit geval is de URL van de lamp lokaal: je gebruikt immers een lokaal netwerkadres. Dit betekent dat je deze lamp niet wereldwijd op dezelfde manier kunt identificeren; maar misschien wil je dat ook niet.
CRUD¶
In de database-wereld staat CRUD voor: create, read, update, delete. Dit zijn de basisoperaties op de elementen in een database.
Met behulp van een REST API kun je dit als volgt uitvoeren, voor een collectie van things
.
method |
|
|
---|---|---|
GET |
get all things (ids) |
get state of thing |
POST |
create new thing |
- |
PUT |
- |
set/update thing |
DELETE |
- |
delete thing |