Even within a single bookstore, different tasks call for different kinds of communication. A reader requests book details, checkout asks inventory to reserve a copy, and a delivery service reports that a parcel has shipped. An API approach that fits one interaction may not fit another equally well.

Names such as REST, GraphQL, gRPC, and WebSocket appear together in technology discussions, but they describe different parts of the problem.

This chapter maps the main approaches network APIs use, explains their trade-offs, and shows how they can coexist within one system.

Before comparing technologies, separate the decisions they address.

An API style shapes how consumers express their intent, such as accessing resources or calling named operations. A protocol defines rules for exchanging messages. A data format defines how those messages represent information. A specification document can describe an API's operations and data so people and tools can understand its contract.

These concepts combine. An API might organize operations around books, exchange HTTP messages, represent book data as JSON, and document the interface with OpenAPI.

Some technologies cover several dimensions. gRPC supplies a framework for remote calls with defined communication behavior and tooling. GraphQL defines a language and execution rules around a typed schema. Neither fits only one of these categories.

Audience is another independent decision. Public, partner, and internal describe intended consumers; they do not require a particular API style. Similarly, sending JSON does not by itself make an API RESTful.

REST, or Representational State Transfer, is an architectural style. A resource is something an interface identifies, such as a book, an order, or a collection of books. A representation is information describing that resource, such as a JSON document containing a book's current details.

REST includes constraints such as a uniform interface, stateless interactions, and explicit cacheability. Its uniform interface includes links that guide interactions. A resource URL and a JSON response alone do not establish that an API satisfies the full style.

In everyday engineering, teams often use “REST API” for resource-oriented HTTP APIs. For a bookstore, retrieving book book_1042 might use GET /books/book_1042. This notation identifies an operation; it is not a complete HTTP request.

The caller names the resource and uses an operation with shared meaning. The provider defines the representation, including which book fields it returns. JSON is a common choice for these APIs, but REST does not require it.

A resource-oriented HTTP interface can fit catalog browsing and order management. It works with HTTP clients and infrastructure, and eligible responses can use HTTP caching, the reuse of stored responses under defined conditions.

The representation still needs to fit consumers. If a book page needs author details and related titles, a narrowly designed interface may require several requests. The provider can design richer representations or additional operations, but those choices affect the contract. REST does not require one request per database table or forbid returning related information.

GraphQL is a query language for APIs with rules for executing operations against a typed schema, a description of available types, fields, and operations. A client selects fields the schema exposes, and the service resolves their values. GraphQL supports reads through queries, changes through mutations, and ongoing results through subscriptions.

Assume a fictional bookstore schema exposes a book field that accepts an identifier and returns a book with an author. A client could submit this query:

For a successful lookup, the service could return:

The response follows the selected fields. This example shows the GraphQL operation and result, without specifying how the client and service transport them.

GraphQL can fit applications whose screens need different combinations of related data. A compact search result and a detailed book page can select different fields from the same schema.

That flexibility creates server responsibilities. A small query can request expensive work, and one client request can trigger many storage or service calls. The server must control access and bound the work it accepts. Clients can request fields the schema exposes; they do not receive unrestricted access to the database.

GraphQL also does not guarantee fewer total bytes or lower latency in every application. The outcome depends on the query, schema, implementation, and the alternative interface you compare it with.

RPC, or Remote Procedure Call, lets a caller invoke a named operation on another process. An inventory service might expose a ReserveStock operation with a book identifier and quantity as inputs. The interface emphasizes the action the caller wants the service to perform.

This can be natural for capabilities such as calculating delivery charges, reserving inventory, or generating a report. The operation still needs a contract for inputs, results, and failures. A remote call can fail because of the network even when its syntax resembles a local function call.

The following diagram compares the emphasis of three interface models. The labels are conceptual examples, not complete requests:

The models change how callers ask for work, not which business operations a system can offer. For example, you could model a stock reservation as creating a reservation resource.

gRPC

gRPC is an RPC framework that commonly uses Protocol Buffers, a schema language and binary serialization format. Serialization converts structured values into a form that software can transmit or store. Service definitions support generating client and server code in supported languages.

gRPC supports individual request and response calls as well as server, client, and bidirectional streaming. Streaming allows a call to carry a sequence of messages.

It can fit communication between services when explicit message types and generated integration code are useful. For browser clients, check which integration options the framework supports, such as gRPC-Web, rather than assuming a native gRPC client can run unchanged in a browser.

The generated tooling and compact encoding are useful capabilities, but they do not establish that every gRPC application will outperform every HTTP JSON application. Workload, implementation, and infrastructure still matter.

SOAP

SOAP is an XML-based messaging framework. It defines an envelope for messages, processing rules, and a fault structure. SOAP supports different underlying protocol bindings and can carry document-oriented exchanges as well as RPC-style interactions. It is not simply another name for RPC.

You may encounter it when connecting the bookstore to a supplier with an existing SOAP contract. In that case, interoperability with the supplier's interface may determine the choice. The structured messaging conventions bring tooling requirements and complexity that may be unnecessary for a small new catalog integration.

Retrieving current data is only one need. A consumer may also need to learn when something changes, such as an order shipping or a delivery estimate changing.

Webhooks

A webhook delivers a notification to an endpoint the receiving system supplies, commonly through an HTTP request. GitHub, for example, sends HTTP requests to configured URLs when subscribed events occur.

The bookstore could use the same pattern to notify a partner when an order ships. The partner provides a receiving endpoint, and the bookstore calls it when the event occurs.

This complements an API for retrieving order details. The notification says that something happened; the receiving system can use the identifier to request additional permitted information if needed. Polling means repeatedly asking for changes. Webhooks can reduce that polling, but the receiver must be able to accept incoming requests.

A webhook contract must address delivery failures and whether notifications can repeat. A delivery attempt does not prove that the receiving application completed its business work.

Server-Sent Events and WebSocket

Server-Sent Events, or SSE, lets a client receive a stream of text events over an HTTP response. Browsers expose this through the EventSource interface. It fits a page that needs continuing updates from the server, such as order progress. Client actions can use separate requests.

WebSocket provides two-way message exchange over an established connection. A bookstore support chat could use it for customer and agent messages. The application still defines what those messages mean.

Both require decisions about connection loss and recovery. Keeping a connection open does not by itself preserve every update during a disconnection. A stream also does not guarantee that an update reaches a user within a particular time limit.

Messaging Between Services

An event records something that happened, such as OrderShipped. Services can publish such events through a message broker, an intermediary that receives messages and makes them available to consumers.

The bookstore could publish one shipping event for notification and analytics consumers. The diagram shows this illustrative arrangement:

Publishing to the broker separates the shipping service from direct calls to these consumers. It adds infrastructure and delivery behavior that the system must manage. Ordering, retention, and redelivery depend on the broker and configuration; none follows merely from calling the system event-driven.

The messages form contracts too. Consumers need to know what OrderShipped and its fields mean, and when the service publishes the event. Request callers likewise need documented inputs and results.

The bookstore does not need to choose one technology for every interaction. Its catalog may use a resource-oriented HTTP API, inventory calls may use gRPC, and delivery updates may arrive through webhooks.

This diagram shows a possible combination, not a recommended minimum architecture:

Each connection serves a particular interaction. The app reads data and receives progress updates, inventory performs defined operations, and the partner reports shipment changes.

Every additional approach also creates maintenance work: libraries, monitoring, debugging tools, and contracts that the team must understand. A smaller system may meet its needs with ordinary HTTP requests and occasional polling. Introduce another mechanism when its benefits justify that added work.

When comparing options, start with the caller's task. Does it need a current resource, a particular operation, a custom selection of related fields, or an ongoing flow of updates? Then consider client environments, expected workload, existing integrations, and the team's ability to operate the result.

Some names in API discussions describe the contract rather than how an API models business operations. OpenAPI is a standard for describing HTTP APIs, including their operations, parameters, and responses. It does not make an API RESTful or require a particular implementation language.

AsyncAPI describes message-driven interfaces, including the messages and channels through which applications communicate. Its role is to make that contract understandable to people and tools, rather than to deliver the messages itself.

Specialized protocols can build on other communication mechanisms. MCP, the Model Context Protocol, defines interactions that connect AI applications with external tools and context. A bookstore could expose a catalog-search tool through an MCP server that calls its existing catalog API. That gives an AI application another integration interface while the underlying catalog service continues to perform its work.

Placing a term in context is more useful than treating every new name as a competing replacement. Ask whether it defines an interface model, carries messages, describes a contract, or supports a particular consumer. Several answers can apply to the same technology.

The API landscape combines interface models, communication patterns, protocols, formats, and contract descriptions. REST emphasizes resources and a uniform interface, GraphQL exposes schema-based field selection, and RPC exposes named operations. SOAP defines a messaging framework, while webhooks, streams, and brokered messages support different ways of delivering changes.

Choose approaches around the interactions consumers need and the system your team can operate. Multiple approaches can coexist, but each should have a clear purpose and an explicit contract.