Inleiding REST API

De eerste module eindigde met het maken van een HTTP-verzoek, het versturen ervan, en het krijgen van een antwoord.

We zullen dit in de toekomst nog vele malen doen. We zullen verzoeken sturen naar servers van derden. We zullen toepassingen maken die zelf zulke verzoeken accepteren en een antwoord terugsturen. We zullen complexe logica creëren voor het verwerken van verzoeken.

Daarom zou het goed zijn om alles wat met deze verzoeken te maken heeft grondig te bestuderen, in detail te analyseren. Zodat je het verzoek niet gewoon ergens kunt kopiëren en herhalen, maar echt kunt uitzoeken hoe het allemaal werkt.

Dit is wat we gaan doen in de tweede module. Laten we beginnen!

Algemene informatie

Laten we beginnen met algemene informatie.

Als je je huiswerk in de eerste module hebt gedaan en de documentatie hebt bestudeerd, moet je de afkorting API hebben opgemerkt. Eigenlijk is de API documentatie het eerste wat ontwikkelaars moeten bestuderen als ze de interactie met een dienst of toepassing op het netwerk willen begrijpen.

API

API - Application Programming Interface. Dit is een beschrijving van de manieren waarop de client en de server met elkaar kunnen communiceren. We openen de API-documentatie en leren daaruit hoe we de nodige gegevens van de server kunnen krijgen.

We willen altijd dat deze interactie eenvoudig en begrijpelijk is. Dit vereenvoudigt de taak voor zowel ontwikkelaars (geen noodzaak om het wiel opnieuw uit te vinden bij het ontwerpen van een nieuwe dienst) als gebruikers (een dienst is veel gemakkelijker te leren als hij volgens hetzelfde principe werkt als eerder bekende diensten). En hier is het de moeite waard een nieuwe term in herinnering te brengen - REST.

REST

REST - acroniem voor Representational State Transfer. Het klinkt misschien niet erg duidelijk, maar eenvoudig gezegd is REST een stijl van interactie (uitwisseling van informatie) tussen een client en een server.

Dit is geen starre reeks regels en eisen. REST dwingt niet tot het gebruik van een bepaalde programmeertaal, noch legt het strikte richtlijnen op. REST wordt een architectuurstijl genoemd en definieert 6 principes waaraan een systeemarchitectuur moet voldoen.

Bijgevolg wordt een API die ontwikkeld is met inachtneming van de principes van REST een REST API genoemd, en worden de toepassingen zelf RESTful genoemd.

Wij zullen juist zulke RESTful-toepassingen maken, dus het is de moeite waard om meteen de principes te bespreken waaraan ze moeten voldoen.

RESTful principes

Client-Server-Model. Dit principe definieert de scheiding tussen de client en de server, de differentiatie van hun behoeften. De client hoeft zich geen zorgen te maken over hoe de gegevens worden opgeslagen, het belangrijkste is dat ze op verzoek worden verstrekt. De server maakt zich op zijn beurt niet druk over wat de client met deze gegevens doet, hoe hij ze verder verwerkt en weergeeft. Hierdoor kunnen zij zich onafhankelijk van elkaar ontwikkelen, en wordt de schaalbaarheid van het systeem verbeterd.

Staatloosheid. Dit principe houdt in dat de server het antwoord niet mag "uitdenken" op basis van eerdere ervaringen met deze cliënt. Elk verzoek wordt zo gedaan dat het alle nodige informatie bevat voor de verwerking ervan, ongeacht eerdere verzoeken.

Caching. Om de verzonden gegevens te minimaliseren, is er een cachingmechanisme. Als bijvoorbeeld een logo wordt weergegeven op een bepaalde pagina, dan heeft het geen zin om het elke keer op te vragen bij de server. Het verandert niet zo vaak, het is voldoende om het één keer op te vragen en het op te slaan op de computer van de client, in de cache. Maar als we informatie moeten krijgen over de huidige snelheid van de auto, dan zal de cache op geen enkele manier helpen. Dit principe bepaalt dat de gegevens die door de server worden doorgegeven al dan niet in de cache moeten worden opgeslagen.

Uniforme interface. Dit beginsel definieert één enkel formaat van client-server interactie. De structuur van alle verzoeken moet hetzelfde zijn. Gegevens moeten in dezelfde vorm worden verzonden, ongeacht wie erom vraagt.

Gelaagd systeem. Client en server communiceren niet noodzakelijkerwijs rechtstreeks. De gegevensoverdracht kan via verschillende intermediaire knooppunten verlopen. In dit geval is het systeem zo ontworpen dat noch de client noch de server weet of ze met de uiteindelijke toepassing of met een tussenliggend knooppunt communiceren. Hierdoor kan de belasting van de servers worden gebalanceerd, waardoor de schaalbaarheid toeneemt.

Code on demand (optioneel). Het enige principe dat niet verplicht is. Volgens dit principe kan de client zijn functionaliteit uitbreiden door uitvoerbare code van de server te downloaden (bijvoorbeeld scripts). In dit geval moet de code alleen op verzoek worden uitgevoerd.