Overzicht van REST. Deel 1: Wat is RUST?

Hoi! Vandaag zullen we leren over een onderwerp dat erg interessant is en vooral waar veel vraag naar is op de arbeidsmarkt: REST. We zullen ons overzicht van REST in drie delen verdelen:

1. In het eerste deel behandelen we de geschiedenis van REST en beschrijven we de principes waarop REST is gebaseerd.

2. In de tweede zullen we bekijken hoe communicatie tussen een client en server plaatsvindt via het HTTP-protocol.

3. In de derde zullen we een kleine RESTful-applicatie schrijven die we zullen testen met behulp van een programma genaamd "Postman".

Het artikel is bedoeld voor lezers die bekend zijn met de volgende termen:

• HTTP
• URL en URI
• JSON en (in mindere mate) XML
• Injectie van afhankelijkheid

Deel 1. Wat is RUST?

REST is, zoals zoveel in de IT-wereld, een acroniem. Het is afgeleid van "REpresentational State Transfer" . Dit is een bouwstijl voor interactie tussen componenten van een gedistribueerd systeem in een computernetwerk. Simpel gezegd, REST bepaalt de stijl voor interactie (gegevens uitwisselen) tussen verschillende componenten van het systeem, die elk fysiek op verschillende plaatsen kunnen worden geplaatst. Deze architecturale stijl is een consistente reeks beperkingen waaraan moet worden voldaan bij het ontwerpen van een gedistribueerd systeem. Deze beperkingen worden soms de leidende principes van REST genoemd. Er zijn er niet veel, slechts 6. We zullen er later over praten.

Geschiedenis van REST

De term REST werd geïntroduceerd door Roy Fielding, een van de makers van het HTTP-protocol, in zijn Ph.D. thesis getiteld "Architectural Styles and the Design of Network-based Software Architectures" in 2000. Hoewel de term REST nog jong genoemd kan worden, vormt het concept dat het vertegenwoordigt de kern van het World Wide Web. We zullen niet diep in de geschiedenis van de term duiken. Als je in de primaire bronnen wilt duiken, bekijk dan het proefschrift van Fielding .

REST-beperkingen en -principes

Zoals hierboven vermeld, definieert REST hoe de componenten van een gedistribueerd systeem met elkaar moeten communiceren. Over het algemeen gebeurt dit via een verzoek-antwoordproces. Het onderdeel dat het verzoek verzendt, wordt de client genoemd en het onderdeel dat het verzoek verwerkt en een antwoord naar de client stuurt, wordt de server genoemd. Verzoeken en antwoorden worden meestal verzonden via het HTTP-protocol. HTTP staat voor HyperText Transfer Protocol. Meestal is een server een webtoepassing. De klant kan bijna alles zijn. Bijvoorbeeld een mobiele app die data opvraagt ​​bij een server. Of een browser die verzoeken van een webpagina naar een server stuurt om gegevens te downloaden. Applicatie A kan gegevens opvragen bij applicatie B. In dit geval is A een client ten opzichte van B, en B is een server ten opzichte van A. Tegelijkertijd kan A verzoeken verwerken van B, C, D, etc. In dit geval is applicatie A zowel een server als een client. Alles hangt af van de context. Eén ding is zeker: het onderdeel dat het verzoek verstuurt, is de client. Het onderdeel dat een verzoek ontvangt, verwerkt en beantwoordt, is de server. Echter, niet elk systeem waarvan de componenten communiceren via een verzoek-antwoordproces is een REST-systeem. Om als RESTful te worden beschouwd, moet een systeem voldoen aan de zes REST-beperkingen:

1. Client-server-architectuur

Deze beperking gaat over de scheiding van zorgen. Het is noodzakelijk om de vereisten van de clientinterface te scheiden van de vereisten van de server die de gegevens opslaat. Deze beperking maakt de clientcode meer overdraagbaar naar andere platforms, en het vereenvoudigen van de serverkant verbetert de schaalbaarheid van het systeem. Door een onderscheid te maken tussen de "client" en de "server" kunnen ze onafhankelijk van elkaar worden ontwikkeld.

2. Staatloos

Een RESTful-architectuur vereist dat aan de volgende voorwaarden wordt voldaan. In de periode tussen verzoeken mag de server geen informatie over de status van de client opslaan en vice versa. Alle verzoeken van de client moeten zo zijn samengesteld dat de server alle benodigde informatie krijgt om het verzoek te voltooien. Zo kunnen zowel de server als de client elk ontvangen bericht "begrijpen", zonder te vertrouwen op eerdere berichten.

3. Cachebaar

Clients kunnen serverantwoorden cachen. Deze moeten op hun beurt expliciet of impliciet worden aangemerkt als gecached of niet-gecachet, zodat klanten geen verouderde of onjuiste gegevens ontvangen als reactie op latere verzoeken. Correcte caching helpt sommige client-server-interacties geheel of gedeeltelijk te elimineren, waardoor de systeemprestaties en schaalbaarheid verder toenemen.

4. Uniforme interface

De fundamentele vereisten van een RESTful-architectuur omvatten een uniforme, uniforme interface. De client moet altijd het formaat en de adressen begrijpen die hij moet gebruiken bij het verzenden van een verzoek, en de server moet op zijn beurt ook het formaat begrijpen dat hij moet gebruiken bij het reageren op verzoeken van de klant. Deze consistente client-server-interactie die beschrijft wat, waar, in welke vorm en hoe gegevens moeten worden verzonden, is een uniforme interface.

5. Lagen

Met lagen bedoelen we de hiërarchische structuur van het netwerk. Soms kan een client rechtstreeks communiceren met de server, en soms communiceert het alleen met een tussenliggend knooppunt. Het gebruik van tussenliggende servers kan de schaalbaarheid vergroten dankzij loadbalancing en gedistribueerde caching. Laten we een voorbeeld geven. Stel je een mobiele app voor die over de hele wereld populair is. Een integraal onderdeel van de app is het laden van afbeeldingen. Het aantal gebruikers loopt in de miljoenen, dus een enkele server kan zo'n zware belasting niet aan. Door het systeem in lagen op te delen, wordt dit probleem opgelost. Als de client een afbeelding opvraagt ​​bij een tussenknooppunt, dan vraagt ​​het tussenknooppunt de afbeelding op bij de server die op dat moment het minst is geladen en stuurt de afbeelding terug naar de client. Als caching correct wordt toegepast op elk niveau van de hiërarchie,

6. Code op aanvraag (optioneel)

Deze beperking houdt in dat de client zijn functionaliteit kan uitbreiden door code van de server te downloaden in de vorm van applets of scripts.

Voordelen van een RESTful architectuur

Applicaties die voldoen aan alle bovengenoemde beperkingen hebben de volgende voordelen: betrouwbaarheid (het is niet nodig om de status van de client op te slaan, die verloren kan gaan)

• prestaties (door het gebruik van een cache)
• schaalbaarheid
• transparante communicatie
• eenvoudige interfaces
• draagbaarheid
• mogelijkheid om gemakkelijk wijzigingen door te voeren
• vermogen om te evolueren en zich aan te passen aan nieuwe vereisten

Overzicht van REST. Deel 2: Communicatie tussen een client en server Overzicht van REST. Deel 3: Een RESTful-service bouwen op Spring Boot