Sådan fungerer REST-API'er · Mindmaps

Sådan fungerer REST-API'er · Mindmaps

The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

Sådan læser du mindmappet

• Begynd ved emnet i midten, og følg en farvet gren til de tilhørende idéer.
• Buede linjer viser sammenhænge; pile bruges, når retningen har betydning.

Request

Denne gren samler “The method is the verb — GET reads, POST creates, PUT replaces, PATCH updates, DELETE removes. REST names resources by URL and acts on them with these verbs.”, “Client sends the request over HTTPS”.

Routing

Denne gren samler “The URL path is the routing key: /users/42 is the handler for one user. Query parameters, headers and the body carry everything else the handler needs.”, “Validation covers authentication (are you who you say you are?), authorization (are you allowed?), and the payload itself (is the data well formed?).”.

Business logic

Denne gren samler “Handler runs the business logic”, “Server reads or writes the resource in the database”.

Response

Denne gren samler “The status code is the contract: 200 OK, 201 Created, 204 No Content, 404 Not Found, 500 Server Error. Clients branch on it before they read the body.”, “Client receives the response and parses it”, “Client renders the result to the user”.

Errors

Denne gren samler “Server returns 400 / 401 / 403”.

Forbindelser på tværs

REST er en kontrakt i HTTP: metoder er verber, URL'er er ressourcer, og statuskoder er det maskinlæsbare udfald.

Klienten er tilstandsløs: hver forespørgsel bærer alt, hvad serveren har brug for, så der kræves ingen delt session.

Valideringen er sikkerhedsgrænsen; en ugyldig forespørgsel afvises, før nogen forretningslogik kører.

Svaret defineres først af sin statuskode og dernæst af sin body.

REST-trafik kører på den samme DNS, HTTPS og internetinfrastruktur, som de andre teknologiforklaringer tegner.

Key relationships and takeaways

• REST er en kontrakt i HTTP: metoder er verber, URL'er er ressourcer, og statuskoder er det maskinlæsbare udfald.
• Klienten er tilstandsløs: hver forespørgsel bærer alt, hvad serveren har brug for, så der kræves ingen delt session.
• Valideringen er sikkerhedsgrænsen; en ugyldig forespørgsel afvises, før nogen forretningslogik kører.
• Svaret defineres først af sin statuskode og dernæst af sin body.
• REST-trafik kører på den samme DNS, HTTPS og internetinfrastruktur, som de andre teknologiforklaringer tegner.

When to use this visual

• At undervise udviklere i modellen med HTTP-metode, URL og statuskode, før de designer deres første endpoint.
• At gennemgå et API's kontrakt op mod REST-konventionen: er fejl statuskoder eller 200 med et flag?
• At forankre en samtale om idempotens og caching i, hvordan forespørgsler faktisk bygges og valideres.

Sådan fungerer det

1. Tilpas emnet i midten

   Giv emnet et navn, der passer til dit projekt eller din undervisning.

2. Udbyg grenene

   Rediger idéerne, og tilføj eksempler eller noter.

3. Forbind beslægtede idéer

   Tegn forbindelser på tværs af grene; brug kun pile, når retningen betyder noget.

Ofte stillede spørgsmål

Hvad er et REST-API?

Et REST-API er et sæt HTTP-endpoints, der eksponerer et systems ressourcer. Klienter handler på ressourcerne med HTTP-metoder: GET for at læse, POST for at oprette, PUT eller PATCH for at opdatere, DELETE for at fjerne, og serveren svarer med en statuskode og en repræsentation, typisk JSON. REST er en stil snarere end en standard, og værdien er, at enhver klient, der taler HTTP, kan bruge det.

Hvad er forskellen på GET, POST, PUT og DELETE?

De er verberne i REST-kontrakten. GET læser en ressource og bør ikke have sideeffekter. POST opretter en ny ressource og returnerer dens identitet. PUT erstatter en ressource i sin helhed og er idempotent: at gentage den ændrer ikke mere. PATCH laver en delvis opdatering. DELETE fjerner en ressource. Tilsammen navngiver verbet og URL'en hele handlingen, og derfor fremhæver forespørgselsboksen i forklaringen metoden først.

Hvorfor er statuskoder vigtige i REST?

Fordi de er forespørgslens maskinlæsbare udfald. En klient kan forgrene på statuskoden uden at parse bodyen: 2xx er succes, 4xx er klientens fejl, 5xx er serverens. API'er, der returnerer 200 med et fejlflag i bodyen, bryder den kontrakt og tvinger hver eneste klient til at behandle svaret som et særtilfælde.

Hvad gør et API »RESTful«?

Den praktiske tjekliste: ressourcer navngivet med URL'er, handlinger udtrykt som HTTP-metoder, tilstandsløse forespørgsler (hver enkelt bærer alt, hvad serveren har brug for), svar, der bruger statuskoder rigtigt, og ofte hypermedia eller versionerede URL'er. Lærredet modellerer turen frem og tilbage (forespørgsel, validering, behandling, svar) som er den form, enhver RESTful udveksling har til fælles.

Rediger dette mindmap i QueryChart

Åbn mindmappet på et redigerbart lærred. Flyt idéer, tilføj grene, og tegn forbindelser.

Rediger dette mindmap i QueryChart