8.1 Remote API-benadering
Alle programmeurs maken dezelfde fout bij het bouwen van een client-serverarchitectuur. Ze beginnen verzoeken aan de server te behandelen als methodeaanroepen .
U wilt het proces voor het genereren van rapporten op de server starten, waarom stuurt u deze dan geen verzoek zoals:
http://server.com/startDocumentGeneration?paramsEn hoe het rapport te downloaden nadat het is voltooid? Om dit te doen, zullen we een andere methode schrijven:
http://server.com/getDocumentDe server slaat HttpSessioninformatie over ons document op en zodra het document is gegenereerd, geeft de server het terug.
Geweldige aanpak. Of niet?
De aanpak is echt verschrikkelijk. Het punt is dat de server het documentnummer moet onthouden. Met andere woorden, om nieuwe methodeaanroepen goed te kunnen verwerken, moet de server de resultaten onthouden van het aanroepen van eerdere methoden.
Op internet is dit een groot probleem. Het internet kan verdwijnen, de browser kan sluiten. De pagina kan opnieuw worden geladen of er kan per ongeluk op een link worden geklikt, enzovoort. En de server zal doorgaan met het opslaan van megabytes aan gegevens van eerdere gebruikersverzoeken ...
Om comfortabel met de server te werken, kunt u niet verwachten dat u altijd de gegevens van eerdere verzoeken aan de server bij de hand hebt.
Hoe dan methoden van de server aanroepen? Het juiste antwoord zou verschrikkelijk zijn: echt niet!
8.2 REST-aanpak
De programmeurs gingen terug naar de basis en herinnerden zich dat het verzoek aanvankelijk het pad naar het bestand op de server bevatte:
http://server.com/path?paramsEn we besloten om deze aanpak maximaal te gebruiken.
Nu wordt de server beschouwd als een opslagplaats van gegevens die voor de buitenwereld zichtbaar is in de vorm van een boom .
Als u een lijst van alle gebruikers wilt krijgen, roept u de query aan:
http://server.com/usersAls u gegevens over gebruiker 113 wilt krijgen, voert u de query uit:
http://server.com/users/113En zo verder, allemaal in dezelfde geest.
Wederom wordt de server gezien als een opslagplaats van data die voor de buitenwereld zichtbaar is in de vorm van een boom.
Gegevens kunnen worden ontvangen - GET- verzoeken , gewijzigd - POST- verzoek en verwijderd - VERWIJDER- verzoek .
8.3 Geen staat
Het REST-protocol van interactie tussen de client en de server vereist de volgende voorwaarde: gedurende de periode tussen verzoeken van de client wordt er geen informatie over de status van de client op de server opgeslagen.
Alle verzoeken van de client moeten zo worden opgesteld dat de server elke keer alle informatie ontvangt die nodig is om aan het verzoek te voldoen . De sessiestatus wordt aan de clientzijde opgeslagen.
Tijdens de verwerking van klantverzoeken wordt de klant geacht zich in een overgangstoestand te bevinden. Elke afzonderlijke toepassingsstatus wordt weergegeven door koppelingen die kunnen worden aangeroepen de volgende keer dat de client toeslaat.
8.4 Interface-uniformiteit
Alle paden die worden gebruikt om objecten van de server op te halen, zijn gestandaardiseerd. Dit is erg handig, vooral als u gegevens van andere REST-servers ontvangt.
Alle objectinterfaces moeten aan drie voorwaarden voldoen:
Identificatie van bronnen
Alle resources worden geïdentificeerd in aanvragen met behulp van een URI. De bronnen binnen de server staan los van de weergaven die worden teruggestuurd naar de clients. Een server kan bijvoorbeeld gegevens uit een database verzenden als HTML, XML of JSON, die geen van beide een opslagtype zijn binnen de server.
Bronnen manipuleren via een weergave
Als de client een representatie van de bron opslaat, inclusief metadata, heeft deze voldoende informatie om de bron op de server te wijzigen of te verwijderen.
"Zelfbeschrijvende" berichten
Elk bericht bevat voldoende informatie om te begrijpen hoe het moet worden verwerkt. Als u bijvoorbeeld informatie over de gebruiker nodig heeft, retourneert de server u een JSON-object met naam- en adresvelden.
Er mag geen situatie zijn waarin de cliënt moet weten dat het eerste cijfer in het antwoord de leeftijd is en het tweede de geboortedatum.
8.5 Caching
De REST-benadering gaat ervan uit dat gegevensverzoeken worden gedaan via het HTTP-protocol. Daarom worden objecten verkregen door een GET-verzoek aan te roepen. Dit betekent dat ze, net als alle bronnen die via een GET-verzoek worden ontvangen, onderworpen zijn aan alle regels voor het cachen van HTTP-bronnen.
Dat wil zeggen, gegevens die via de REST API worden ontvangen, worden op dezelfde manier in de cache opgeslagen als statische bronnen op webservers. Schoonheid :)