En API-forespørgsels livscyklus · Mindmaps

En API-forespørgsels livscyklus · 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.

Find the service

Denne gren samler “The first round trip is DNS — the domain is resolved to an IP address before a single request is sent. See How DNS Works for the full lookup chain.”, “A TCP connection is established”, “The encryption handshake negotiates keys before the HTTP request travels — see How HTTPS Works for what happens inside it.”.

Send request

Denne gren samler “The HTTP request is sent”, “With several servers behind one address, the load balancer picks a healthy instance for each request and spreads traffic across them.”.

Application

Denne gren samler “Handler validates and processes the request”, “Server queries the database”.

Return response

Denne gren samler “Server serialises the response”, “Response travels back through the same path”, “Client parses and renders the response”.

Forbindelser på tværs

DNS, TCP og TLS kommer før HTTP-forespørgslen: tre ture frem og tilbage, før nogen applikationskode kører.

Load balanceren får mange servere til at ligne én adresse; klienten ser aldrig den rigtige server.

Databaseforespørgslen er det langsomste hop i de fleste API-kald, og derfor betyder caching og indeksering noget.

Svaret følger forespørgslens vej tilbage: begge retninger krydser det samme netværk og den samme load balancer.

Livscyklussen sætter de andre forklaringer sammen: DNS, HTTPS og REST er alle trin på den samme rejse.

Key relationships and takeaways

• DNS, TCP og TLS kommer før HTTP-forespørgslen: tre ture frem og tilbage, før nogen applikationskode kører.
• Load balanceren får mange servere til at ligne én adresse; klienten ser aldrig den rigtige server.
• Databaseforespørgslen er det langsomste hop i de fleste API-kald, og derfor betyder caching og indeksering noget.
• Svaret følger forespørgslens vej tilbage: begge retninger krydser det samme netværk og den samme load balancer.
• Livscyklussen sætter de andre forklaringer sammen: DNS, HTTPS og REST er alle trin på den samme rejse.

When to use this visual

• At lære en ny udvikler, at svartiden på et API er mere end serverkode: netværket og opsætningen er reelle trin.
• At fejlsøge langsomhed: lærredet navngiver de hop, du skal måle: DNS-tid, TTFB, servertid, overførselstid.
• At forankre en samtale om load balancing og caching i, hvor hver ting sidder på rejsen.

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

Hvilke trin består en API-forespørgsel af?

Før der sendes noget HTTP, slår klienten domænet op via DNS, åbner en TCP-forbindelse og gennemfører et TLS-handshake. Derefter rejser forespørgslen til en load balancer, som router den videre til en applikationsserver; serveren validerer og behandler den, kører en forespørgsel mod databasen og serialiserer et svar; og svaret vender tilbage ad den samme vej. Forklaringens tre kolonner er præcis de tre grupper af trin.

Hvorfor er et API-kald langsomt, før serveren gør noget som helst?

Fordi DNS-opslaget, TCP-forbindelsen og TLS-handshaket alle er reelle ture frem og tilbage, der sker, før en eneste byte HTTP sendes. På en kold forbindelse kan de tage længere tid end selve behandlingen af forespørgslen. Derfor åbner forklaringen med kolonnen »Før forespørgslen«: det meste af svartiden på den første forespørgsel er opsætning, ikke serverkode.

Hvilken rolle spiller load balanceren i livscyklussen?

Load balanceren er den stabile hoveddør, de faktiske servere står bag. Den tager imod forespørgslen, vælger en sund instans og sender trafikken videre, og den er også ofte der, hvor health checks og TLS terminerer. Klienter ved aldrig, hvilken server der betjente dem, og det er det, der gør det muligt at tilføje og fjerne servere uden at ændre klienten.

Hvorfor tager svaret den samme vej tilbage?

Fordi forbindelsen er vejen: svaret rejser over den samme TCP/TLS-forbindelse, gennem det samme netværk og den samme load balancer, som bar forespørgslen. Symmetrien betyder noget i drift: et langsomt eller ødelagt hop rammer begge retninger, og derfor tegner forklaringen svarkolonnen som spejlbilledet af forespørgselskolonnen i stedet for at gå ud fra, at returrejsen er gratis.

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