RESTREST is ontwikkeld als methode om webservices met elkaar te laten communiceren. verder lezen is ontwikkeld als methode om webservices met elkaar te laten communiceren. Kenmerkend is de flexibele opzet waarmee data kan worden gedefinieerd. In dit artikel zoomen we dieper in op de technische aspecten van deze methode.
Wat is Representational State Transfer (REST)?
Dit is een methodiek die is bedoeld om de communicatie tussen webservices te faciliteren. Een webservice is als het ware een bouwsteen voor een webapplicatie. Vanuit die webservice worden gegevens beschikbaar gemaakt aan andere programma-onderdelen. Dat gebeurt via de API, oftewel de Application Programming Interface. Via die API openbaart de webservice de functies die de ‘buitenwereld’ mag benaderen om informatie uit de webservice te ontsluiten of om functionaliteit uit te voeren. Platforms als Instagram en Gmail bieden bijvoorbeeld API’s om met hun systemen te koppelen. REST is daarbij het protocol voor de communicatie tussen de webservice en de applicatie.
In het verleden moesten die API-functies meestal via een speciaal protocol worden benaderd: SOAP. Met REST is dat een stuk eenvoudiger geworden. Bij REST kan de webservice worden benaderd door eenvoudigweg een URL aan te roepen, net als dat je dat doet wanneer je naar een website navigeert.
Wat zijn de spelregels
REST is een uniforme API-architectuur die niet is gebonden aan methodes en resources. De REST API is hiermee een abstracte, client-server toegang die allerlei bronnen en platforms aan elkaar kan verbinden, los van de technologie die op die platforms wordt gebruikt. In de praktijk wordt het voornamelijk ingezet voor het HTTP-protocol, maar deze webgebaseerde architectuur kan ook prima overweg met bijvoorbeeld FTP.
Ondanks dat REST geen data contracten kent, zijn er een aantal spelregels verbonden aan het gebruik ervan om het zo uniform mogelijk te houden.
- Toestandloos (stateless)
Services die de REST-architectuur implementeren moeten toestandloos worden ontworpen. Dat wil zeggen dat iedere service aanroep los moet kunnen staan van een volgende. Het is dus niet noodzakelijk om iets door te geven van de ene naar de andere aanroep. In het verlengde hiervan mogen geen (sessie)cookies worden gebruikt.
- Bronstructuur
De bronnen worden gestructureerd ontsloten door Uniform Resource Identifiers (URI). Deze bronnen zijn dus benaderbaar middels een publiek internetadres.
Dit wordt duidelijk middels het volgende voorbeeld:
/klanten (alle klanten)
/klanten/12323/facturen (alle facturen van klant 12323)
/klanten/12323/facturen/15 (factuur 15 van klant 12323) - Zelfbeschrijvend
Bij het toepassen van REST over HTTP dienen de HTTP-methodes zo zuiver mogelijk te worden ingezet. Hieronder is een overzicht van methodes weergegeven. Consumenten van de API weten dan intuïtief welke methode op welke bron aangesproken moet worden.
GET /klanten/12323/facturen (geef alle facturen van klant 12323) POST /klanten/12323/facturen (maak een nieuwe factuur aan voor klant 12323) DELETE /klanten/12323/facturen/15 (verwijder factuur 15 van klant 12323)
- Logisch antwoord
De consument kan middels HTTP-headers aangeven in welke vorm het antwoord wordt verwacht. Dat dient gerespecteerd te worden door de API op de server.
Daarnaast is het van wezenlijk belang om de juiste statuscode terug te geven. Bij bijvoorbeeld het aanmaken van een nieuw object wordt de statuscode 201 teruggegeven. Als een bron niet gevonden kan worden, dan is de statuscode 404 logisch. - Cache
De REST API op de server geeft in het antwoord aan of een bron in het tijdelijke geheugen bewaard kan worden.
Ontwikkeling van een REST API
De ontwikkeling van een REST API is relatief eenvoudig: dat is waar de ontwikkeling van het protocol ook om begonnen is. Wel is het vereist dat de programmeur binnen het ontwerp van de technische architectuur aandacht heeft voor datastructuren, veiligheid en privacy-aspecten. Wil je meer weten over de ontwikkeling van een REST API? Neem dan contact met ons op via het onderstaande formulier.