REST uses HTTP methods and URLs; payloads are usually JSON. It is simple, widely supported, and easy to debug (curl, browser). Great for public APIs, web and mobile clients, and when you want broad compatibility. Caching (HTTP cache headers), load balancers, and firewalls understand it. Drawbacks: over-fetching or under-fetching (client gets a whole resource or needs multiple round-trips), and no standard for streaming or real-time.

Use REST when: external or multi-client APIs, CRUD-heavy, need caching and simple tooling.

gRPC uses Protocol Buffers and HTTP/2. Strongly typed, binary, and efficient. Supports streaming (client, server, or bidirectional). Excellent for internal service-to-service APIs where you control both sides and want performance and streaming. Less friendly for browsers (no native gRPC in fetch) and requires grpc-web or a proxy for browser clients.

Use gRPC when: internal microservices, high throughput, low latency, or streaming (e.g. real-time updates, bulk data).

GraphQL exposes a single endpoint; the client sends a query describing exactly the data it needs. The server returns only those fields. No over-fetching; one round-trip can aggregate many resources. Great for complex UIs where different screens need different shapes. Downsides: caching is harder (no HTTP resource URLs), and abusive queries can be expensive—you need query depth/size limits and complexity analysis.

Use GraphQL when: flexible client needs, many clients with different views, or you want to consolidate multiple REST calls into one.

Public or partner API: REST (or REST + OpenAPI). Internal services, performance-critical: gRPC. Mobile or SPA with varying data needs: GraphQL or REST with sparse fieldsets. Real-time or streaming: gRPC or WebSockets. You can mix: e.g. REST for external, gRPC between services, GraphQL for a BFF (backend-for-frontend) that talks to services.