De tre dominante alternativene er REST (HTTP/JSON), gRPC (HTTP/2 + Protobuf) og meldingskøer (Kafka/RabbitMQ). REST og gRPC er synkrone; køer er asynkrone.
De tre dominante alternativene er REST (HTTP/JSON), gRPC (HTTP/2 + Protobuf) og meldingskøer (Kafka/RabbitMQ). REST og gRPC er synkrone; køer er asynkrone.
| Aspekt | REST | gRPC | Message Queue |
|---|
| Stil | Synk | Synk | Asynk |
| Payload | JSON (tekst) | Protobuf (binært) | Enhver (ofte binær) |
| Ytelse | God | Høy | Høy gjennomstrømning |
| Kontrakt | OpenAPI (løs) | .proto (streng) | Schema/event |
| Streaming | Begrenset | Innebygd (bidi) | Pub/sub |
| Best for | Offentlige APIer, nettlesere | Interne kritiske stier | Frakobleing, events |
service OrderService {
// strongly-typed RPC, generated client + server stubs
rpc GetOrder (OrderId) returns (Order);
}
message OrderId { string id = 1; }
message Order { string id = 1; double total = 2; }
Order Service ─publish→ [ "OrderPlaced" topic ] ─▶ Inventory
└────▶ Notifications
(producer doesn't know or wait for consumers)
Bruk av synkron gRPC/REST overalt gjenoppretter tett kobling; bruk av asynkron for umiddelbar lesing av bruker legger til unødvendig latens.
Transportvalget setter koblings- og ytelsesgrensen for hver interaksjon, så valg per brukstilfelle — ikke globalt — er det som holder systemet både raskt og robust.
Modne systemer blander med vilje alle tre: gRPC på interne kritiske stier, REST ved kanten, og køer for arbeidsflyter.