API
Styles.

An API is how two pieces of software talk over a network. There are several API styles. The four common ones are REST, GraphQL, gRPC and WebSocket. SOAP and RPC are older styles.

Every style solves the same problem: a client needs to fetch or change data on a server. They differ in data format, how you call them, and their trade-offs in speed, flexibility and cacheability. This topic compares the three main styles and shows when to choose each.

REST models everything as a resource, and each resource has a URL. The client acts on resources with HTTP verbs. GET reads, POST creates, PUT updates, DELETE removes. The data is usually JSON.

REST is stateless. Each request carries enough information for the server to handle it, and the server remembers no previous request. This makes REST easy to scale horizontally. A GET response is also easy to cache because it maps to a fixed URL.

REST has a weakness when the UI is complex. Each endpoint returns a fixed data shape. If the client needs only a few fields, it still receives the whole object. This is over-fetching, which wastes bandwidth.

The opposite is under-fetching. One screen needs data from several resources, so the client calls many endpoints and stitches them together. On mobile, many round-trips slow the experience. GraphQL was created to solve exactly these two problems.

GraphQL has a single endpoint. The client sends a query describing exactly the fields it needs, including nested data from several resources. The server returns that exact shape, nothing more and nothing less.

This solves over-fetching because the client takes only the fields it needs. It solves under-fetching because one query gathers data from many sources in a single call. The frontend becomes flexible and can change the UI without the backend adding new endpoints.

GraphQL pays a price in a few places. Caching is harder than REST. Every query hits the same endpoint over POST, so it cannot use URL-based HTTP caching the way GET does. You must cache at the application layer.

GraphQL also invites the N+1 query problem: a deeply nested query can explode into many database queries behind it. You need techniques like a dataloader to batch them. The server is also more complex. Choose GraphQL when clients are diverse and the UI changes fast.

gRPC calls a function on a remote service as if it were local. It uses Protocol Buffers to encode data as binary, much smaller and faster than JSON. It runs on HTTP/2, so it gets multiplexing and streaming.

Both sides share one schema definition file. From that file, client and server code is generated automatically, in many languages. This makes gRPC very fast and strongly typed.

gRPC shines in internal communication between microservices. Its binary speed and streaming suit heavy traffic inside one system. It is also good for two-way real-time connections.

gRPC is weak on the browser side. A browser cannot call gRPC directly and needs a proxy layer. Binary data is also hard to read when debugging. The rule: use gRPC between internal services, and use REST or GraphQL for APIs that outside clients call.

The three main styles serve three different needs. Use REST for public APIs and simple CRUD, because it is easy to understand and caches well. Use GraphQL when many client types need different data shapes, or the UI changes fast.

Use gRPC for internal microservice communication that needs high speed. Use WebSocket when you need a two-way real-time channel. No style is best in the absolute. Choose by the client, by caching needs, and by whether the API is internal or public.