Wat is een REST API?

API's zijn tegenwoordig in modern computergebruik de meest gebruikelijke manier voor programma's en apparaten om met elkaar te communiceren. Een API is een verzameling regels die beschrijft hoe één programma verbinding kan leggen en kan communiceren met een ander. Zoals de naam suggereert, geeft een REST API bij elk verzoek de status van de transactie door. Dit biedt voordelen op het gebied van ontwerp, prestaties en resources ten opzichte van andere benaderingen. REST heeft zich in meer dan twee decennia verder ontwikkeld en is een zeer gebruikelijke benadering voor gedistribueerde en op services gebaseerde architecturen.

Een fundamenteel concept voor REST API’s is de resource. Een resource is een object met een type, bijbehorende gegevens, relaties tot andere resources en een verzameling methoden die met het object werken. Het lijkt veel op het idee van objecten bij programmeren, hoewel maar een paar standaardmethoden zijn gedefinieerd, zoals HTTP GET, POST, PUT en DELETE. Resources kunnen alleen bestaan of in verzamelingen, die zelf weer resources zijn.

In modern computergebruik is een gebruikelijk model – ook fundamenteel voor REST API's – het client-servermodel, waarbij een cliënt die een resource nodig heeft, zich identificeert en communiceert met een server die het kan leveren. Bijna al het cloudverkeer wordt op deze manier beheerd, omdat het maximale flexibiliteit biedt voor meerdere klanten om meerdere servers te bereiken. Het principe werkt ook goed voor zogenaamde ‘serverless’-architecturen, waarbij een servicemakelaar de plaats inneemt van een server die de klant kent.

De REST API-architectuur begon zich in 1993 te ontwikkelen, toen algemene websites gepubliceerd begonnen te worden.

De snelle uitbreiding van het Web leidde tot concurrerende voorstellen voor uitbreidingen van het originele HyperText Transfer Protocol (HTTP). Het World Wide Web Consortium (W3C) en de Internet Engineering Task Force (IETF) begonnen nieuwe versies van HTTP, HyperText Transfer Language (HTML) en URI-standaarden te beoordelen en te formaliseren.

Na zes jaar aan de standaardisatie van HTTP en URI gewerkt te hebben, definieerde de onderzoeker Roy Fielding in 2000 REST. Hiermee bepaalde hij de architectuurstijl om toekomstige ontwikkelingen van de protocollen van het Web te verifiëren en om uitbreidingen te identificeren die niet voldeden aan de gedrags- en prestatiedoelstellingen van het Web.

Later bleken REST-concepten in hoge mate flexibel bij de opkomst van connected computing. Sinds 2015 creëert het OpenAPI Initiative, gesponsord door de Linux Foundation met leden als Google, IBM, Microsoft en PayPal, de OpenAPI-specificatie op basis van RESTful regels. Dit zorgt voor de publicatie van interfacebestanden die machines kunnen lezen en die RESTful webservices beschrijven, produceren, gebruiken en visualiseren.

Toepassingen die op basis van de OpenAPI-interfacebestanden zijn geïmplementeerd, kunnen automatisch documentatie van methoden, parameters en modellen genereren. Het OpenAPI-initiatief biedt niet alleen een gecentraliseerde aanpak binnen de sector voor gestandaardiseerde headers, codes, resource-beschrijvingen en toekomstige innovaties, maar ook tools, documentatie en best practices. Deze zijn vooral belangrijk voor het creëren, verifiëren en correct gebruiken van authenticatie en databeveiliging op een RESTful manier. Dit is een specifiek aandachtspunt van het OpenAPI Initiative.

1. Uniforme interface

Alle verzoeken die via een REST API worden ingediend, moeten aan de formatregels van die API voldoen. Het maakt niet uit welke cliënt het verzoek indient. Elk stuk informatie moet daar staan waar elke andere cliënt het zou zetten. Een voorbeeld is de URL (Uniform Resource Locator) die voor het identificeren van resources via HTTP wordt gebruikt. Dit is maar één voorbeeld van een Uniform Resource Identifier (URI) die veel breder toepasbaar is.

2. Scheiding tussen client en server

REST API’s vereisen dat client- en serverapplicaties volledig onafhankelijk van elkaar zijn. De client hoeft alleen de volledige naam van de gewenste resource te kennen in de virtuele ruimte die de API toestaat. Verder weten de client en de server alleen van elkaar wat via API-transacties wordt uitgewisseld.

3. Stateless verzoeken

Elk verzoek van een client moet alle informatie bevatten die nodig is om het te verwerken en de server hoeft geen informatie over dat verzoek te onthouden zodra het is ontvangen. Het concept van een sessie bestaat niet in het ontwerp van een REST API en de server is stateless naar iedere client.

4. Mogelijkheid tot cachen

Hoewel de server per client stateless is, moeten resources daarentegen wel op een of meer punten in of tussen client en server kunnen worden gecachet. Als de server een bepaalde resource heeft geleverd en het waarschijnlijk is dat deze binnen een bepaalde tijd opnieuw zal worden gevraagd, dan moet deze gecachet worden, zodat een volgend antwoord sneller kan worden gegeven. De client zou een soortgelijk besluit over ontvangen resources moeten nemen. De server moet via de API aangeven of een resource veilig lokaal bij de client kan worden gecachet, inclusief de levensduur van de gegevens, indien van toepassing. Het ontwerp van een cache, hoewel het geen deel uitmaakt van de specificatie van een RESTful API, is essentieel voor de prestaties en API-ontwerpers moeten zich ervan bewust zijn hoe dit in de praktijk kan worden toegepast.

5. Gelaagde systeemarchitectuur

Een gevolg van de scheiding tussen client en server, stateless verzoeken en de mogelijkheid tot cachen is dat een cliënt geen aannames kan maken over of hij direct met een server communiceert die een bepaalde resource bezit, of dat deze wordt geleverd door een intermediair, zoals een servicemakelaar, een load balancer, een CDN (content delivery network) of een ander subsysteem dat zich dichter bij de cliënt bevindt dan de server. Dit geeft systeem- en infrastructuurontwerpers aanzienlijke flexibiliteit om de efficiency en de betrouwbaarheid van de afhandeling van verzoeken over de wereldwijde bedrade en draadloze infrastructuur te maximaliseren. Het ligt ten grondslag aan de functionaliteit van edge computing.

6. Code op aanvraag

Terwijl REST API’s vaak alleen gegevens voor gebruik door de cliënt leveren, is het steeds gebruikelijker om code te leveren, die op de cliënt kan draaien, zoals Java objects of Javascript web-apps. Als dit wordt geïmplementeerd, dan kan zo’n code door de cliënt alleen op aanvraag worden uitgevoerd.

REST API’s kunnen vrijwel elk verzoek tot toegang, elk gegevensformaat, elke controle van resources of elk statusbericht afhandelen, maar de statelessness-regel heeft wel tot gevolg dat elk verzoek alle authentificatie moet bevatten die nodig is om het verzoek te verifiëren, maar ook de nauwkeurige definitie van de vereiste resource en de precieze vereiste actie.

Een bestandssysteem-API die niet RESTful is, kan bijvoorbeeld een verzoek om een bestand te lezen beantwoorden door een “file handle” terug te sturen, een klein token dat aan een sessie wordt toegewezen, zodat de cliënt herhaald stukken kan lezen door alleen naar de file handle te verwijzen. Een REST API zou in plaats daarvan elke keer de autorisatie van de client moeten sturen, maar ook de volledige nauwkeurige resource-identifier samen met de precieze plaats in het bestand van de te lezen gegevens. Het is aan de klant om dit bij te houden.

REST API's geven al deze informatie door via een combinatie van headers en parametervelden en kunnen de feitelijke gegevens in elk formaat uitwisselen. Een zeer gebruikelijke standaard is JSON, het Javascript Object Notation-format, dat ondanks zijn naam door zowel mensen als machines leesbaar is, zowel optisch of door om het even welke populaire programmeertaal.

Bij het ontwerpen van een REST API moet rekening worden gehouden met de efficiëntie, met name als grote gegevensoverdrachten of tijdkritische streams moeten worden verwerkt, of omgekeerd als kleine hoeveelheden gegevens uit bronnen met beperkte resources, zoals IoT-systemen, worden verwerkt.

OVHcloud API is een webservice waarmee OVHcloud-klanten producten van OVHcloud kunnen kopen, managen, upgraden en configureren zonder de grafische gebruikersinterface te hoeven gebruiken. Het is gebaseerd op de nieuwste RESTful API om bijna alles in het OVHcloud-universum te beheren. De API is ontworpen om eenvoudig en gemakkelijk in gebruik te zijn en de codefragmenten worden geleverd in veel verschillende talen.

OVHcloud Manager (V6) is nu toegankelijk via de OVHcloud API. Elke nieuw product en elke nieuwe productversie zal compatibel zijn met de API. Met de API Explorer-console kan men door de API bladeren om alle beschikbare functies van OVHcloud-producten te ontdekken, zelfs iemand die niet als ontwikkelaar is geregistreerd. U kunt ook een product selecteren en de dedicated API bekijken om verwante acties te ontdekken.

Met de OVHcloud RESTful API kunt u snel en eenvoudig scripts ontwikkelen voor eigengemaakte functies, automatisering, meerdere gelijktijdige taken en het maken van IaaS-/PaaS- implementatie- en managementtools. Expliciete taalondersteuning is aanwezig voor C, C++, C#, Java, Perl, PHP, Python en Ruby en nog veel meer.