Nettet pleide å være en høflig brevveksling: du skriver en forespørsel, du får et svar. Så begynte maskinene å svare tilbake midt i setningen, be om verktøy, strømme tanker, synge stemmepakker over UDP. Å velge en API-stil nå handler mindre om ideologi og mer om koreografi: hvem leder, hvem følger, hvem improviserer, og hvordan holde takten når bandet er halvt menneske, halvt transformer.

TL;DR

  • REST forblir den offentlige, cachbare, CDN-vennlige ryggraden. Kombiner med OpenAPI og (for AI) strukturerte outputs for å gjøre modeller til forutsigbare maskiner.
  • GraphQL skinner når produkt-UIs trenger fleksible utsnitt av data; bruk APQ og (der det trengs) subscriptions over SSE/WebSocket.
  • gRPC regjerer tjeneste-til-tjeneste-kall: sterke kontrakter, strømming, deadlines og klare feilsemantikker over HTTP/2; bruk Connect/gRPC-Web ved nettleserkanten.
  • tRPC er det pragmatiske valget for et TypeScript-overalt-team som sender interne/front-end-til-backend-apper raskt; eksporter OpenAPI hvis utenforstående må konsumere det.
  • SSE er den enkleste veien for token-strømming fra LLM-er; mye brukt av OpenAI/Anthropic-stakker. WebSocket er for ekte toveis, lav-latens-interaksjon (samarbeidsredigering, flerspiller, modell-«realtime»-agenter).
I liten skala, bias mot REST + SSE eller tRPC + SSE. I mellomstor skala, GraphQL for produktoverflater, gRPC for interne tjenester. I stor skala, bygg et blandet mesh: REST i perimeteren, GraphQL for aggregering, gRPC for øst-vest, SSE/WS for sanntid, med typede kontrakter og gateways som policy-punkter.

Den nye begrensningen: AI i forespørsels-stien

Tre atferder dominerer 2025-arkitekturer:

  1. Strømmende responser. Brukere forventer at ord (og lyd) ankommer midt i tanken. De fleste store LLM-APIer strømmer via Server-Sent Events (SSE); stemmeagenter bruker ofte WebRTC/WebSocket for full-dupleks media. Transporten din må håndtere delvise resultater, mottrykk og kansellering.
  1. Verktøybruk / function calling. Modeller sender typede kall; du utfører dem og mater resultater tilbake. JSON Schema-støttede strukturerte outputs og verktøyskjemaer gjør dette robust.
  1. Strenge SLAer mellom tjenester. LLM-pipelines forgrener seg: embeddings her, retrieval der, re-ranking andre steder. Deadlines/timeouts og typede feilkoder holder kjeder ærlige—dette er der gRPCs semantikk hjelper.

Hold disse tre i hodet; de er metronomen for resten av partituret.

Prosjektstørrelse (vær presis, ikke grandiose)

  • Liten: 1–3 utviklere, ≤ 9 måneder, ≤ ~10k LOC, én UI + et par tjenester, ingen offentlig API.
  • Mellomstor: 3–12 utviklere, 9–36 måneder, 10k–75k LOC, flere klienter, noen interne tjenester, kanskje partnerintegrasjoner.
  • Stor: 12–50+ utviklere, flerårig, 75k–250k+ LOC, polyglot, offentlige APIer/SDKer, regulert eller inntektskritisk.

De fleste «store» prosjekter er faktisk mellomstore; kompleksitetsinflasjon er reell. Velg den enkleste stilen som fortsatt skalerer til din horisont.

REST: den varige perimeteren

Når det synger: offentlige APIer, cachbare lesinger, bred klientkompatibilitet, governance og lange levetider. Hva det gir deg:
  • HTTP-semantikk & caching: verb, statuskoder, content negotiation; CDN/edge-gevinster på GET med RFC 9110/9111.
  • Observerbarhet & policy: modne gateways, rate limits, OAuth-flyter, retries.
AI-æra-vri:
  • Strukturerte outputs: eksponer «function-calling»-stil endepunkter med JSON Schema-kontrakter slik at modellklientene dine treffer deterministiske former. (OpenAI/Azure leverer førsteklasses strukturerte outputs.)
  • Strømmende tokens: hold forespørselen klassisk REST, men returner text/event-stream og push deltas via SSE; dette er de facto-mønsteret på tvers av leverandører.
Bruk til:
  • Liten: CRUD + et /chat/stream SSE-endepunkt.
  • Mellomstor: partner-APIer; offentlige webhooks; cache-tunge ressurser.
  • Stor: kontrakten du vil at tredjeparter skal leve med i et tiår fremover.
REST-mønstre du vil trenge:
  • JSON Patch (RFC 6902) & JSON Merge Patch (RFC 7386): Kutt payloads og konflikter for modell/konfig-oppdateringer; essensielt når AI-agenter justerer ressurser ofte.
  • Hypermedia/Formater (JSON:API, HAL, OData): Standardiser former, paginering og linking slik at agenter og verktøy ikke må lære hver APIs særegenheter på nytt. Spesielt nyttig for AI-«function calling» mot mange tjenester.

GraphQL: produktformet data, én rundtur

Når det synger: komplekse UIer som trenger utsnitt på tvers av domener; færre rundturer; skjemastyrt evolusjon. Hva det gir deg:
  • Et typet skjema klienten spør fleksibelt; ikke bundet til lagring.
  • Subscriptions & strømmende felter via WebSocket eller i økende grad GraphQL over SSE.
AI-æra-vri:
  • APQ (Automatic Persisted Queries) for å aktivere GET + cache ved kanten; modeller kan læres å velge fra en hvitelistet katalog av operasjoner (mindre jailbreak, mer guardrails).
  • Transportvalg: for inkrementelle resultater (@defer, subscriptions) er SSE enkelt og HTTP-nativt; behold WebSocket der du virkelig trenger dupleks-interaksjon.
Bruk til:
  • Liten: kun hvis du har flere klienter med divergerende views; ellers er REST raskere å sende.
  • Mellomstor: UI-aggregeringslag; sy sammen mikrotjenester; subscriptions for live-widgets.
  • Stor: supergrafer/federation med APQ, caching og policy ved routeren.

gRPC: ryggraden i tjenestemeshet ditt

Når det synger: inter-tjenestekall med strenge kontrakter, strømming og stramme SLAer. Hva det gir deg:
  • Protocol Buffers-skjemaer og genererte klienter; HTTP/2-transport med multipleksing; unær + klient/server/bidi strømming.
  • Deadlines, kansellering, statuskoder innebygd—avgjørende når en LLM-pipeline kjeder flere hopp.
Nettleserrealitet:
  • Nativ gRPC over HTTP/2 er ikke direkte nettleservennlig; bruk gRPC-Web eller en Connect-server for å bygge bro (og du kan fortsatt strømme).
AI-æra-vri:
  • Perfekt for verktøy-backends (retrievers, vektorsøkere, rerankere) der du trenger deadlines og typede feil for å holde orkesteret samlet under latensbudsjetter.
Bruk til:
  • Liten: vanligvis overkill med mindre du allerede er i Proto-land.
  • Mellomstor: interne tjenester og dataplan.
  • Stor: standard øst-vest-protokoll; eksponer REST/GraphQL ved kanten.

tRPC: TypeScript ende-til-ende-hastighet

Når det synger: ett team, TypeScript på begge sider, du vil ha typer uten ekstra maskineri. Hva det gir deg:
  • Infererte typer fra server til klient; minimal boilerplate; HTTP under panseret.
Forbehold:
  • Ikke polyglot; tett kobling til TS; ikke ideelt som offentlig API med mindre du eksporterer OpenAPI (community-plugins finnes).
AI-æra-vri:
  • Ende-til-ende-typer er catnip for copiloter: endre server-formen, kompilatoren (og modellen) guider refaktoreringen. For eksterne modellkonsumenter, publiser OpenAPI slik at ikke-TS-stakker kan interoperere.
Bruk til:
  • Liten: raskeste vei for TS-team (f.eks. Next.js-apper).
  • Mellomstor: interne dashboards/devtools; oppgrader til REST/GraphQL når partnere ankommer.
  • Stor: sjelden; speil kontrakter inn i OpenAPI/GraphQL hvis du beholder det.

SSE: den undervurderte arbeidshesten for AI-UX

Hva det er:
  • En enkelt HTTP-tilkobling som strømmer text/event-stream til nettleserens EventSource. Enveis server → klient; auto-reconnect; proxy-vennlig.
Hvorfor AI elsker det:
  • Token-strømming er naturlig på SSE, og mange leverandører dokumenterer det eksplisitt (inkludert på managed clouds).
Bruk til:
  • Liten/Mellomstor/Stor: når du trenger inkrementelle outputs uten toveis prat (chat, logger, fremgangshendelser). Reserver WS for ekte dupleks.
Variant: HTTP-strømming med NDJSON (JSON Lines):
  • Billig, debuggbar server → klient-strømmer (og et fint valg for LLM token-for-token output). Kombiner med SSE når du ikke trenger full dupleks.

WebSocket: når du virkelig trenger toveis

Hva det er:
  • En full-dupleks-kanal definert av RFC 6455, med nettleser-APIer på MDN; flott for interaktive apper og egendefinerte protokoller.
AI-æra-vri:
  • For stemme/visjons-agenter eller samarbeidsverktøy ender du opp med WebSocket eller WebRTC (OpenAI/Azure støtter begge stier i realtime).
Bruk til:
  • Liten: chatter, markører, whiteboards som trenger klient→server-hendelser.
  • Mellomstor/Stor: tilstandsfull collab eller sanntids kontrollkanaler; ellers foretrekk SSE.

Moderne tillegg: strømme- og hendelseslaget

WebTransport (HTTP/3/QUIC)

Hva det er: Toveis strømmer og upålitelige datagrammer til en server, ingen head-of-line-blokkering. AI-æra bruk: Ideelt for lav-latens token- og telemetri-strømming når WebSockets treffer proxy- eller multipleksings-snags. Nyttig for LLM token-strømmer, live modellkontroll og multi-strøm UI-oppdateringer. Bruk til: Mellomstor/Stor når du trenger ekte lav-latens multi-strøm-transport og kan kontrollere både klient og server.

WebRTC Data Channels

Hva det er: Peer-to-peer, pålitelig eller delvis-pålitelig data; perfekt for stemme/visjons-agenter, flerspiller, eller local-first AI-verktøy. AI-æra bruk: WebRTC er hvordan nye realtime AI-APIer leverer voice-in/voice-out. Også flott for distribuert AI-inferens (peer-to-peer modellruting). Bruk til: Liten/Mellomstor/Stor stemmeagenter, samarbeidsredigering, flerspiller, eller ethvert scenario der peer-to-peer reduserer serverkostnader.

Web Push + Notifications API

Hva det er: For re-engasjement og out-of-band-dytter (f.eks. «din langkjørende batch LLM-jobb er ferdig»). Fungerer selv når appen ikke er åpen. Bruk til: Mellomstor/Stor bakgrunnsjobb-varsler, modelltrenings-ferdig-varsler.

Meldingstjenester for tjenester, agenter og dataplan

MQTT (inkl. MQTT over WebSockets)

Hva det er: Ultra-lett pub/sub; utmerket for IoT-enheter som mater edge AI eller abonnerer på modelloutputs. Nettleservennlig via WebSockets. Bruk til: Liten/Mellomstor IoT + AI edge-deployments; Stor når du trenger millioner av lette tilkoblede enheter.

NATS (+ JetStream)

Hva det er: Enkel, veldig rask meldingstjeneste med valgfrie varige strømmer og exactly-once-mønstre; fin ryggrad for mikrotjenester pluss AI-agenter som trenger request/reply og pub/sub. Bruk til: Mellomstor intern hendelsesbuss; Stor som service mesh-ryggrad når du trenger enkelhet over Kafkas kompleksitet.

Apache Kafka (Event Streaming)

Hva det er: Varige, ordnede hendelseslogger for høy-throughput-pipelines; flott for modelltelemetri, feature stores og emittering/konsumering av AI-hendelser i skala. Bruk til: Stor hendelsesdrevne arkitekturer, ML feature stores, revisjonslogger, CDC-pipelines som mater AI-modeller.

AMQP 1.0

Hva det er: Åpen, interoperabel enterprise-meldingstjeneste; robust ruting, transaksjoner og pålitelighet. Nyttig der AI-hendelser må krysse heterogene systemer (banker, myndigheter, flyselskaper). Bruk til: Stor regulerte bransjer som trenger garantert levering og transaksjons-semantikk.

CloudEvents (CNCF)

Hva det er: En felles konvolutt for hendelser på tvers av transporter (HTTP, Kafka, NATS). Hjelper med å standardisere AI-hendelsespayloads på tvers av systemet ditt. Bruk til: Mellomstor/Stor når du kjører multi-transport hendelsesarkitekturer og trenger interop.

AsyncAPI

Hva det er: OpenAPI for hendelsessystemer; dokumenter og styr strømme/meldingsAPIene dine (Kafka, MQTT, NATS, AMQP). Bruk til: Mellomstor/Stor governance, klient-SDK-generering, API-kataloger for hendelsesdrevne systemer.

RPC-alternativer & broer

Connect RPC (av Buf)

Hva det er: En pragmatisk, HTTP/1.1-vennlig søsken av gRPC med førsteklasses JSON + Protobuf, enkel CORS og god DX—hendig for web + mobil som snakker til samme AI-backends. Bruk til: Liten/Mellomstor når du vil ha gRPC-semantikk uten nettleser/proxy-smerten; Stor som et enklere alternativ til gRPC-Web.

gRPC-JSON Transcoding (Envoy)

Hva det er: Eksponer REST/JSON over gRPC-backendene dine slik at AI-verktøykjeder og low-code-klienter kan kalle dem enkelt. Bruk til: Mellomstor/Stor når du vil opprettholde gRPC internt men eksponere REST eksternt.

Cap'n Proto / Thrift

Hva det er: Nisje men potent: zero-copy, capability-basert RPC (Cap'n Proto) eller moden IDL-først RPC (Thrift). Bruk til: Stor super-lav latens mellom AI-mikrotjenester der nanosekunder betyr noe.

AI-spesifikke protokoller verdt å kjenne

Model Context Protocol (MCP)

Hva det er: En åpen, JSON-RPC-basert protokoll for å koble modeller med verktøy, data og IDEer. Hvis artikkelen din dekker «AI som kaller APIene dine», er MCP den leverandørnøytrale historien. Bruk til: Liten/Mellomstor/Stor når du bygger AI-agentsystemer som trenger standardiserte verktøy/data-koblinger.

Strukturerte Outputs / JSON Schema-begrensede responser

Hva det er: Behandle LLMer som veltypede APIer; avgjørende for verktøybruk og sikker automatisering. Bruk til: Alle størrelser når du eksponerer APIer til AI-agenter—håndhev skjemaer for å forhindre hallusinerte felter.

Realtime AI over WebRTC/WebSocket

Hva det er: Mange LLM-leverandører tilbyr nå WebRTC/WebSocket realtime APIer for stemme/visjons-agenter. Bruk til: Mellomstor/Stor stemmeassistenter, live transkripsjon, visjonsanalyse med strømmende resultater.

Bromønstre verdt å kjenne (2025)

  • Connect RPC: én kodebase som snakker gRPC, gRPC-Web og sin egen HTTP-vennlige protokoll (JSON eller Protobuf; strømming også). Det er en praktisk måte å eksponere samme tjeneste til nettlesere og backends uten Envoy-gymnastikk.
  • GraphQL over SSE: mange servere implementerer nå SSE for subscriptions (enklere ops, HTTP-nativt). Behold WS der du trenger dupleks.
  • APQ for GraphQL: aktiver GET + hasher for edge-caching og hvitelisting.

Beslutningsguide etter prosjektstørrelse

Liten (1–3 utviklere, ≤9 måneder)

Standard:
  • REST + SSE (OpenAPI + strukturerte outputs; ett strømme-endepunkt).
  • TS full-stack? tRPC + SSE for hastighet; eksporter OpenAPI hvis noen utenfor repoet ditt må kalle deg.
Unngå:
  • GraphQL med mindre du virkelig har flere divergerende klienter.
  • gRPC med mindre du allerede eier Proto.

Mellomstor (3–12 utviklere, 9–36 måneder)

Front-ends:
  • GraphQL for UI-fleksibilitet; slå på APQ; bruk SSE for subscriptions/strømming.
Interne tjenester:
  • gRPC mellom tjenester; sett deadlines; map feil til statuskoder.
  • NATS eller Kafka for asynkron hendelsesbuss.
Sanntid:
  • SSE for token-strømmer.
  • WebSocket kun hvis klienter må sende live-hendelser.
Governance:
  • AsyncAPI hvis du har hendelsesdrevne tjenester.
  • CloudEvents for standardisering av hendelseskonvolutter.

Stor (12–50+, flerårig)

Perimeter:
  • REST (versjonert, cachbar) med strukturerte outputs for AI-klienter; publiser SDKer.
Aggregering:
  • GraphQL-supergraf med APQ; subscriptions over SSE der mulig, WS der nødvendig.
Mesh:
  • gRPC øst-vest (strømming der det hjelper); bygg bro til nettlesere med Connect/gRPC-Web.
  • Kafka som hendelsesryggrad for ML-pipelines, feature stores, revisjonslogger.
Realtime-agenter:
  • WebRTC/WS-kontrollkanaler; SSE for tekst-strøm-fallbacks.
Governance:
  • API Extractor for TypeScript offentlig overflate.
  • AsyncAPI for hendelseskataloger.
  • CloudEvents for kryss-transport hendelsesinterop.

Vanlige feller (og hvordan AI endrer regnestykket)

  1. Bruke WebSocket «bare fordi det er realtime». Hvis klienten sjelden snakker tilbake, velg SSE; det er enklere, mer CDN/proxy-vennlig, og er i tråd med LLM token-flyter.
  1. GraphQL uten en cache-historie. Slå på APQ og vurder response-caching der semantikken tillater; ellers vil du skyve alt til klient-cacher og lure på hvorfor kanten sitter ubrukt.
  1. Offentlig tRPC. Flott inne i en TS-monorepo; for partnere, generer OpenAPI (eller tilby REST/GraphQL) slik at ikke-TS-klienter og AI-agenter kan integrere fornuftig.
  1. Ignorere deadlines i LLM-pipelines. gRPC (eller Connect) gjør timeouts/kansellering førsteklasses; propager dem eller se hale-latens eksplodere.
  1. Mikse for mange transporter uten kontrakter. Velg 2-3 primære stiler og bygg bro forsiktig. Bruk OpenAPI, AsyncAPI og Protobuf for å opprettholde fornuften.

Rask velger (AI-sentrisk)

  • «Jeg trenger et offentlig API partnere kan cache ved kanten, og mine AI-klienter trenger JSON-skjemaer.» → REST + OpenAPI + Strukturerte Outputs; SSE for strømming.
  • «Produkt-UIen min trekker skreddersydde former på tvers av flere backends.» → GraphQL (+ APQ, SSE subscriptions).
  • «Dette er et internt, latens-sensitivt dataplan med fan-out og retries.» → gRPC (deadlines, statuskoder, strømming).
  • «Vi er en TS-butikk som sender en webapp raskt.» → tRPC (eksporter OpenAPI hvis noen andre skal kalle det).
  • «Det er en chat/konsoll/svar-strøm.» → SSE.
  • «Det er samarbeidende og toveis eller stemme.» → WebSocket/WebRTC.
  • «Vi trenger hendelsesdrevne mikrotjenester i skala.» → Kafka (stor), NATS (mellomstor), med AsyncAPI-dokumenter og CloudEvents-konvolutter.
  • «AI-agenter må kalle våre interne verktøy.» → REST med JSON Schema + MCP, eller gRPC med strukturerte verktøydefinisjoner.

Konklusjon: Orkesteret holder takten

I 2025 er valg av API-transport ikke én beslutning—det er å orkestrere en stakk der forskjellige instrumenter spiller forskjellige deler.

REST forankrer din offentlige overflate. GraphQL aggregerer for produkt-UIer. gRPC kobler tjenester under SLA. SSE strømmer tokens fra modeller. WebSocket håndterer ekte dupleks. Kafka/NATS megler hendelser. CloudEvents standardiserer konvolutter. AsyncAPI dokumenterer flytene.

Teamene som sender raskest er ikke de som velger «den beste» transporten. De er de som:
  • Størrelsesvurderer prosjektet sitt ærlig (Liten/Mellomstor/Stor)
  • Velger 2-3 primære stiler og bygger bro mellom dem rent
  • Behandler strømming og verktøykall som førsteklasses bekymringer
  • Bruker skjemaer (OpenAPI, Protobuf, JSON Schema, AsyncAPI) for å holde mennesker og AI ærlige

AI gjorde ikke REST foreldet. Det gjorde hybride arkitekturer obligatoriske. Maskinene er i loopen nå, og de trenger kontrakter de kan stole på.

Send koreografien. Hold takten. La bandet spille.

---

Om forfatteren: Odd-Arild Meling har bygget API-lag for telefonsvitsjer, betalingsgatewayer, flerspillerspill og LLM-drevne agenter. Han har debugget gRPC-deadlines klokken 3 om natten, feiret SSE-gjenoppkoblingslogikk som reddet Black Friday, og sett WebSocket-tilkoblinger multiplisere fra titalls til millioner. Arkitekterer for tiden edge-first-systemer hos Gothar der REST, GraphQL, gRPC og SSE alle sendes til produksjon—fordi virkeligheten ikke velger favoritter.