Overzicht van REST. Deel 2: Communicatie tussen een client en server

Overzicht van REST. Deel 1: Wat is RUST? In dit deel gaan we dieper in op hoe communicatie plaatsvindt tussen een client en server. Onderweg zullen we nieuwe termen ontdekken en uitleggen. Om er zeker van te zijn dat alles duidelijk is, analyseren we client-servercommunicatie met een RESTful-applicatie als voorbeeld. Stel dat we een webapplicatie ontwikkelen waarin informatie over klanten en hun bestellingen wordt opgeslagen. Met andere woorden, ons systeem kan bewerkingen uitvoeren op bepaalde entiteiten: ze maken, bewerken en verwijderen, en er informatie over weergeven. Deze entiteiten zullen zijn:

• klanten (klanten)
• bestellingen (klantbestellingen)
• artikelen (producten)

In een RESTful-architectuur sturen clients verzoeken naar een server om gegevens op te halen of te wijzigen, en vervolgens sturen servers klanten antwoorden op hun verzoeken.

Verzoeken

Clientverzoeken worden bijna altijd gedaan met behulp van het HTTP-protocol. Over het algemeen bestaan ​​HTTP-verzoeken uit verschillende componenten:

• HTTP-methode
• koptekst
• URI
• lichaam aanvragen

Hieronder gaan we dieper in op elk onderdeel.

URI's en bronnen

De gegevens die clients via verzoeken ontvangen of wijzigen, worden resources genoemd. Bij client-servercommunicatie draait alles om het manipuleren van bronnen. In REST zijn bronnen alles waar je een naam aan kunt geven. In zekere zin zijn het net klassen in Java. In Java kunnen we voor alles een klasse maken. Dus in REST kan een resource van alles zijn: een gebruiker, een document, een rapport, een bestelling. Het kan een abstractie zijn van een entiteit of iets specifieks, bijvoorbeeld een afbeelding, video, animatie of pdf-bestand. In ons voorbeeld hebben we 3 bronnen:

• klanten (klanten)
• bestellingen (klantbestellingen)
• artikelen (producten)

Clients sturen verzoeken naar resourcelocaties die eindpunten worden genoemd. Simpel gezegd, een eindpunt is als een adres op het netwerk. Als we dieper duiken, kunnen we zeggen dat een eindpunt een URI is, dwz een reeks tekens die een abstracte of fysieke bron identificeert. Uniform resource identifier (URI) Soms wordt een eindpunt, of URI, een pad genoemd, wat het pad naar een bron betekent. Voor de doeleinden van dit artikel gebruiken we de term URI. Elke specifieke resource moet een unieke URI hebben. De serverontwikkelaar is ervoor verantwoordelijk dat elke bron altijd zijn eigen URI heeft. In ons voorbeeld zijn wij de ontwikkelaars, dus we zullen het doen zoals we weten hoe. Net zoals het vaak gebruikelijk is om numerieke identifiers toe te wijzen als de primaire sleutels in een relationele database, heeft elke resource ook zijn eigen ID in REST. De resource-ID in REST komt vaak overeen met de ID van het record in de database waarin informatie over de resource is opgeslagen. REST URI's beginnen gewoonlijk met de meervoudsvorm van een zelfstandig naamwoord dat een bron beschrijft. Bijvoorbeeld, "

• /customers — URI van alle beschikbare klanten
• /customers/23 — URI van een specifieke klant, dwz de klant met ID=23
• /customers/4 — URI van een specifieke klant, dwz de klant met ID=4.

Maar dat is niet alles. We kunnen de URI uitbreiden door bestellingen toe te voegen:

• /customers/4/orders — URI van alle bestellingen van klant nr. 4
• /customers/1/orders/12 — URI van bestelling nr. 12 gemaakt door klant nr. 1.

Als we de uitbreiding voortzetten door meer producten toe te voegen, krijgen we:

• /customers/1/orders/12/items — URI van de lijst met alle producten in bestelling nr. 12 gemaakt door klant nr. 1.

Bij het toevoegen van niveaus van nesting is het belangrijk om de URI's intuïtief te maken.

HTTP-methode

De HTTP-methode is een reeks van willekeurige tekens (behalve besturingstekens en scheidingstekens), die de hoofdbewerking aangeeft die op de bron wordt uitgevoerd. Er zijn verschillende algemene HTTP-methoden. We zullen de lijst opsommen die het meest worden gebruikt in RESTful-services:

• GET - Krijg informatie over een bepaalde bron (via zijn ID) of over een verzameling bronnen
• POST - Maak een nieuwe bron aan
• PUT - Verander een bron (via zijn ID)
• VERWIJDEREN — Een bron verwijderen (via zijn ID)

Kopteksten

Verzoeken, evenals antwoorden, bevatten HTTP-headers. Ze geven aanvullende informatie over het verzoek (of antwoord). Headers zijn sleutel-waardeparen. U kunt de lijst met de meest voorkomende headers op Wikipedia bekijken . Wat betreft REST, clients sturen vaak een "Accept"-header in verzoeken naar de server. Deze header is nodig om de server te vertellen in welk formaat de client een antwoord verwacht te ontvangen. In een lijst met MIME-typen worden verschillende formaten gegeven. MIME (Multipurpose Internet Mail Extensions) is een specificatie voor het coderen van informatie en het formatteren van berichten, zodat ze via internet kunnen worden verzonden. Elk MIME-type bestaat uit twee delen gescheiden door een schuine streep: een type en een subtype. Voorbeelden van MIME-types voor verschillende soorten bestanden:

• tekst — tekst/plain, tekst/css, tekst/html
• afbeelding — afbeelding/png, afbeelding/jpeg, afbeelding/gif
• audio — audio/wav, audio/mpeg
• video — video/mp4, video/ogg
• applicatie — applicatie/json, applicatie/pdf, applicatie/xml, applicatie/octet-stream

Een verzoek kan bijvoorbeeld een header als deze hebben:

Accept:application/json

Deze header vertelt de server dat de client een antwoord verwacht in JSON-indeling.

Verzoek lichaam

Dit is het bericht dat door de client naar de server wordt gestuurd. Of het verzoek al dan niet een hoofdtekst heeft, hangt af van het type HTTP-verzoek. GET- en DELETE-verzoeken bevatten bijvoorbeeld over het algemeen geen verzoektekst. Maar PUT- en POST-verzoeken kunnen - het hangt gewoon af van het doel van het verzoek. Om gegevens te ontvangen en/of te verwijderen met behulp van een ID (die wordt doorgegeven in de URL), hoeft u immers geen extra gegevens naar de server te sturen. Maar om een ​​nieuwe bron te maken (via een POST-verzoek), moet u de bron verzenden. Hetzelfde geldt voor het wijzigen van een bestaande bron. In REST wordt de aanvraagtekst meestal verzonden in XML- of JSON-indeling. Het JSON-formaat wordt het meest gebruikt. Stel dat we een verzoek naar de server willen sturen om een ​​nieuwe bron te maken. Als je het niet bent vergeten, we hebben het voorbeeld overwogen van een applicatie die klantorders beheert. Stel dat we een nieuwe klant willen aanmaken. In ons geval slaan we de volgende klantgegevens op: Naam, e-mail, telefoonnummer. Dan zou de body van het verzoek de volgende JSON kunnen zijn:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

Aanvragen in elkaar zetten

We hebben dus onderzocht wat er in een verzoek van een klant zou kunnen staan. We zullen nu enkele voorbeelden van verzoeken samen met beschrijvingen geven

Reacties

Laten we een paar woorden zeggen over serverreacties. Een reactie bestaat meestal uit de volgende onderdelen:

• Reactiecode
• koppen
• reactie lichaam

Over het algemeen verschillen responsheaders niet veel van verzoekheaders. Bovendien worden sommige headers gebruikt in zowel antwoorden als verzoeken. Ik denk dat alles ook duidelijk is wat betreft de verzoekende instantie. De instantie geeft vaak de door de cliënt gevraagde informatie terug. Informatie die als reactie op GET-verzoeken wordt geretourneerd, kan ook in JSON-indeling zijn. Maar het laatste deel is iets interessanter.

HTTP-antwoordcodes

Laten we HTTP-antwoordcodes in meer detail bekijken. Een HTTP-statuscode maakt deel uit van de eerste regel van een serverreactie op verzoeken via het HTTP-protocol. Het is een geheel getal bestaande uit drie decimale cijfers. Het eerste cijfer geeft de klasse van de antwoordstatuscode aan. De responscode wordt meestal gevolgd door een verklarende zin in het Engels, gescheiden door een spatie. Deze zin is een voor mensen leesbare reden voor het antwoord. Voorbeelden:

• 201 Gemaakt
• 401 Ongeoorloofd
• 507 Onvoldoende opslag

De responscode vertelt de client het resultaat van het verzoek en stelt hem in staat om te bepalen welke acties vervolgens moeten worden ondernomen. Responscodes zijn onderverdeeld in verschillende klassen of groepen:

• 1XX — Informatief
• 2XX — Deze codes geven aan dat het verzoek van de klant met succes is ontvangen en verwerkt
• 3XX - Deze codes informeren de klant dat een extra verzoek, meestal naar een andere URI, moet worden gedaan om de bewerking met succes te voltooien
• 4XX — Clientfout. Dergelijke codes kunnen het gevolg zijn van een onjuist samengesteld verzoek. Een ander voorbeeld is de bekende "404 Not Found"-code, die kan optreden wanneer een client een niet-bestaande bron opvraagt
• 5XX — Serverfout. Deze codes worden teruggestuurd naar de client als de server verantwoordelijk is voor het mislukken van de bewerking

Overzicht van REST. Deel 3: Een RESTful-service bouwen op Spring Boot