Wat is een REST API?

REST of RESTful API design (Representational State Transfer) is ontworpen om gebruik te maken van bestaande protocollen. Terwijl REST kan worden gebruikt over bijna elk protocol, het maakt meestal gebruik van HTTP wanneer gebruikt voor Web API ‘ s. Dit betekent dat ontwikkelaars geen bibliotheken of extra software hoeven te installeren om te profiteren van een REST API-ontwerp. REST API ontwerp werd gedefinieerd door Dr.Roy Fielding in zijn 2000 doctoraat proefschrift. Het is opmerkelijk voor zijn ongelooflijke laag van flexibiliteit., Omdat gegevens niet gebonden zijn aan methoden en bronnen, heeft REST de mogelijkheid om meerdere soorten oproepen te behandelen, verschillende dataformaten te retourneren en zelfs structureel te veranderen met de juiste implementatie van hypermedia.

deze vrijheid en flexibiliteit inherent aan REST API ontwerp kunt u een API die voldoet aan uw behoeften, terwijl ook voldoen aan de behoeften van zeer diverse klanten te bouwen. In tegenstelling tot SOAP, REST is niet beperkt tot XML, maar in plaats daarvan kan terugkeren XML, JSON, YAML of een ander formaat, afhankelijk van wat de client verzoekt., En in tegenstelling tot RPC, gebruikers zijn niet verplicht om te weten procedure namen of specifieke parameters in een specifieke volgorde.

Er zijn echter nadelen aan REST API ontwerp. U kunt de mogelijkheid verliezen om de status in rust te behouden, zoals in sessies, en het kan moeilijker zijn voor nieuwere ontwikkelaars om te gebruiken. Het is ook belangrijk om te begrijpen wat maakt een REST API RESTful, en waarom deze beperkingen bestaan voordat het bouwen van uw API. Immers, als je niet begrijpt waarom iets is ontworpen op de manier die het is, kun je je inspanningen belemmeren zonder het zelfs te beseffen.,

Understanding REST API Design

hoewel de meeste API ‘ s claimen rustgevend te zijn, voldoen ze niet aan de vereisten en beperkingen die Dr.Fielding stelt. Er zijn zes belangrijke beperkingen om API ontwerp rust om zich bewust te zijn van bij de beslissing of dit de juiste API type voor uw project.

Client-Server

de client-server beperking werkt op het concept dat de client en de server van elkaar gescheiden moeten zijn en individueel en onafhankelijk mogen evolueren., Met andere woorden, Ik moet in staat zijn om wijzigingen aan te brengen in mijn mobiele applicatie zonder invloed op de gegevensstructuur of het database ontwerp op de server. Tegelijkertijd moet ik in staat zijn om de database te wijzigen of wijzigingen aan te brengen in mijn serverapplicatie zonder dat dit gevolgen heeft voor de mobiele client. Dit zorgt voor een scheiding van zorgen, waardoor elke applicatie onafhankelijk van de andere kan groeien en opschalen en uw organisatie snel en efficiënt kan groeien.,

Stateless

REST API ‘ s zijn stateless, wat betekent dat oproepen onafhankelijk van elkaar kunnen worden gemaakt, en elke oproep bevat alle gegevens die nodig zijn om zichzelf succesvol te voltooien. Een REST API moet niet vertrouwen op gegevens die worden opgeslagen op de server of sessies om te bepalen wat te doen met een oproep, maar alleen vertrouwen op de gegevens die wordt verstrekt in die oproep zelf. Identificerende informatie wordt niet opgeslagen op de server bij het maken van gesprekken. In plaats daarvan heeft elke oproep de nodige gegevens op zich, zoals de API-sleutel, toegangstoken, gebruikers-ID, enz., Dit helpt ook de betrouwbaarheid van de API te verhogen door alle gegevens te hebben die nodig zijn om de oproep te doen, in plaats van te vertrouwen op een reeks oproepen met serverstatus om een object te maken, wat kan leiden tot gedeeltelijke mislukkingen. In plaats daarvan, om de geheugenvereisten te verminderen en uw toepassing zo schaalbaar mogelijk te houden, vereist een RESTful API dat elke toestand op de client wordt opgeslagen—niet op de server.

Cache

omdat een stateless API de overhead van aanvragen kan verhogen door het verwerken van grote ladingen inkomende en uitgaande oproepen, moet een REST API worden ontworpen om de opslag van cachebare gegevens aan te moedigen., Dit betekent dat wanneer gegevens cacheeerbaar zijn, de reactie moet aangeven dat de gegevens kunnen worden opgeslagen tot een bepaalde tijd (verloopt-at), of in gevallen waarin gegevens real-time moeten zijn, dat de reactie niet door de client in de cache moet worden geplaatst. Door deze kritische beperking in te schakelen, zult u niet alleen het aantal interacties met uw API aanzienlijk verminderen, waardoor het interne servergebruik wordt verminderd, maar ook uw API-gebruikers voorzien van de tools die nodig zijn om de snelste en meest efficiënte apps mogelijk te maken. Houd er rekening mee dat caching wordt gedaan aan de kant van de klant., Terwijl u in staat zijn om een aantal gegevens in uw architectuur cache om algemene prestaties uit te voeren, de bedoeling is om de client te instrueren over hoe het moet gaan en of de client de gegevens Tijdelijk kan opslaan of niet.

uniforme Interface

de sleutel tot het loskoppelen van client van server is het hebben van een uniforme interface die onafhankelijke evolutie van de toepassing mogelijk maakt zonder dat de services, modellen of acties van de toepassing nauw gekoppeld zijn aan de API-laag zelf., De uniforme interface laat de client praten met de server in een enkele taal, onafhankelijk van de architecturale backend van beide. Deze interface moet een onveranderlijke, gestandaardiseerde manier van communiceren tussen de client en de server bieden, zoals het gebruik van HTTP met URI resources, CRUD (Create, Read, Update, Delete), en JSON.

gelaagd systeem

zoals de naam al aangeeft, is een gelaagd systeem een systeem dat bestaat uit lagen, waarbij elke laag een specifieke functionaliteit en verantwoordelijkheid heeft., Als we denken aan een Model View Controller framework, elke laag heeft zijn eigen verantwoordelijkheden, met de modellen bestaande uit hoe de gegevens moeten worden gevormd, de controller gericht op de inkomende acties en de view gericht op de output. Elke laag is apart maar interageert ook met de andere. In REST API ontwerp, hetzelfde principe geldt, met verschillende lagen van de architectuur samen te werken aan een hiërarchie die helpt bij het creëren van een meer schaalbare en modulaire applicatie te bouwen.,

met een gelaagd systeem kunt u ook oudere systemen inkapselen en minder algemeen toegankelijke functionaliteit verplaatsen naar een gedeeld intermediair, terwijl u ook modernere en veelgebruikte componenten ervan kunt afschermen. Bovendien biedt het gelaagde systeem u de vrijheid om systemen in en uit uw architectuur te verplaatsen naarmate technologieën en diensten evolueren, waardoor de flexibiliteit en levensduur toenemen zolang u de verschillende modules zo losjes mogelijk koppelt., Er zijn aanzienlijke beveiligingsvoordelen van het hebben van een gelaagd systeem, omdat u hiermee aanvallen kunt stoppen op de proxy-laag of binnen andere lagen, waardoor ze niet naar uw werkelijke serverarchitectuur kunnen. Door gebruik te maken van een gelaagd systeem met een proxy, of het creëren van een enkel toegangspunt, bent u in staat om kritische en meer kwetsbare aspecten van uw architectuur achter een firewall te houden, waardoor directe interactie met hen door de client wordt voorkomen., Houd er rekening mee dat beveiliging niet gebaseerd is op een enkele “stop all” – oplossing, maar eerder op het hebben van meerdere lagen met het begrip dat bepaalde beveiligingscontroles kunnen mislukken of worden omzeild. Als zodanig, hoe meer beveiliging je in staat bent om te implementeren in uw systeem, hoe groter de kans dat je schadelijke aanvallen te voorkomen.

Code on Demand

misschien wel de minst bekende van de zes beperkingen, en de enige optionele beperking, Code on Demand maakt het mogelijk dat code of applets worden verzonden via de API voor gebruik binnen de applicatie., In wezen creëert het een slimme applicatie die niet langer alleen afhankelijk is van zijn eigen codestructuur. Echter, misschien omdat het zijn tijd vooruit, Code on Demand heeft moeite voor de goedkeuring als Web API ‘ s worden geconsumeerd in meerdere talen en de overdracht van de code roept veiligheidsvragen en zorgen. (Bijvoorbeeld, de directory zou beschrijfbaar moeten zijn, en de firewall zou moeten laten wat normaal beperkt inhoud kan zijn.)

samen vormen deze beperkingen de theorie van Representationele Staatoverdracht, of rust., Als u terugkijkt door deze kunt u zien hoe elke opeenvolgende beperking bouwt op de top van de vorige, uiteindelijk het creëren van een vrij complexe—maar krachtige en flexibele—applicatie programma-interface. Maar het belangrijkste is dat deze beperkingen een ontwerp vormen dat op dezelfde manier werkt als hoe we toegang krijgen tot pagina ‘ s in onze browsers op het World Wide Web. Het creëert een API die niet wordt gedicteerd door de architectuur, maar door de representaties die het retourneert, en een API die—hoewel architectonisch staatloos—vertrouwt op de representatie om de status van de toepassing te dicteren.,

voor meer informatie over het ontwerp van de REST API, kijk op het eBook Undisturbed REST: A Guide to Designing the Perfect API.