Choosing the Right API Architecture: RPC, SOAP, REST, or GraphQL?

APIs act as bridges that let separate applications communicate, and the architectural style determines how that communication is structured. The four dominant styles—RPC, SOAP, REST, and GraphQL—have distinct protocols, data formats, and design constraints.

RPC: Calling Functions on Another System

How RPC Works

A client serializes a function name, parameters, and metadata into a message, sends it to the server, which deserializes the request, executes the function, and returns the result. Both sides handle their own serialization and deserialization. Early versions used XML‑RPC; later JSON‑RPC simplified payloads. Google’s gRPC (released 2015) adds HTTP/2 transport, pluggable load‑balancing, tracing, health‑checking, and TLS authentication.

Advantages

Simple, direct interaction : GET for queries, POST for other operations, essentially invoking an endpoint and receiving a response.

Easy to add new functions : Adding a capability only requires defining a new function and exposing a new endpoint.

High performance : Lightweight payloads reduce network pressure, making RPC suitable for high‑throughput scenarios such as parallel computation on shared servers.

Disadvantages

Tight coupling to the underlying system : The API mirrors server implementation details, limiting reusability and exposing internal logic, which can create security risks.

Low discoverability : Clients cannot easily explore available functions without external documentation.

Function explosion : The ease of adding functions often leads to a proliferation of overlapping endpoints.

Use Cases

Google (gRPC), Facebook (Apache Thrift), and Twitch (Twirp) use high‑performance RPC for internal microservice communication where low latency and high message rates are critical. Command‑oriented APIs such as Slack’s “join channel” map cleanly to RPC calls.

SOAP: Structured XML Messaging

How SOAP Works

SOAP messages consist of an envelope, a header, a body, and an optional fault element. The body carries the request or response payload; the header carries metadata such as authentication tokens. Services are described by a WSDL file that defines endpoints and available operations.

Advantages

Language and platform agnostic : XML‑based contracts enable diverse clients to interoperate.

Protocol flexibility : SOAP can be transported over HTTP, SMTP, TCP, and many other protocols.

Built‑in error handling : Fault messages return standardized error codes and descriptions.

Enterprise‑grade security extensions : WS‑Security provides message‑level encryption, signing, and authentication, making SOAP popular for financial and billing systems.

Disadvantages

Verbosity : XML payloads are large, consuming significant bandwidth.

Complexity : Implementing a SOAP service requires deep knowledge of XML schemas, WS‑* specifications, and strict contract management.

Heavy tooling : Adding or removing elements in the XML structure is cumbersome, slowing adoption.

Use Cases

SOAP remains common for internal enterprise integrations and scenarios demanding strong security, such as payment processing, reservation systems, and regulated data exchange.

REST: Resource‑Oriented Architecture

How REST Works

REST is defined by six constraints: uniform interface, statelessness, cacheability, client‑server separation, layered system, and optional code‑on‑demand. Resources are identified by URIs, and standard HTTP methods (GET, POST, PUT, DELETE, PATCH, OPTIONS) manipulate those resources. Hypermedia (HATEOAS) can provide discoverability by embedding links to related actions in responses.

Advantages

Client‑server decoupling : Allows independent evolution of front‑end and back‑end.

Discoverability : Hypermedia links expose available operations without external docs.

Cache friendliness : Leverages HTTP caching mechanisms to reduce load.

Multiple format support : JSON, XML, and others can be used for payloads.

Disadvantages

No single standard implementation : Resource modeling varies per project, making design decisions non‑trivial.

Potentially verbose responses : Returning full resource representations can increase bandwidth, a factor that motivated the creation of GraphQL.

Over‑ or under‑fetching : Clients may receive more data than needed or must issue additional requests for missing fields.

Use Cases

Management APIs : CRUD‑heavy services that benefit from discoverability and documentation.

Simple resource‑driven applications : Public APIs where bandwidth is ample and the resource model is stable.

GraphQL: Precise Data Queries

How GraphQL Works

Developers first define a strongly‑typed schema (SDL) that lists every query, mutation, and type the API supports. Clients write queries that exactly specify the fields they need; the server validates the query against the schema, resolves each field, and returns a JSON payload containing only the requested data. The schema enables introspection tools to generate documentation automatically.

Advantages

Typed schema : Improves discoverability because tooling can introspect the API.

No versioning : A single evolving schema replaces the need for multiple API versions.

Detailed error messages : Errors pinpoint the exact field and resolver that failed.

Fine‑grained permissions : Servers can expose only permitted fields per request.

Disadvantages

Performance trade‑offs : Deeply nested queries can overload the server; for simple CRUD operations, REST may be faster.

Cache complexity : Standard HTTP caching does not apply, requiring custom cache layers or client‑side caching libraries.

Learning curve : Developers must master SDL, resolver patterns, and tooling before gaining productivity.

Use Cases

Mobile APIs : Reduces payload size, which is critical for limited‑bandwidth devices.

Complex systems and microservices : Aggregates data from multiple back‑ends behind a single schema, easing evolution of legacy services.

How to Pick the Right Style

Choosing an API architecture depends on programming language, development environment, and resource budget (people and money). After weighing each style’s pros and cons, designers can match the style to project constraints:

Strongly coupled RPC is ideal for internal microservices where performance outweighs external discoverability.

SOAP’s extensive security extensions make it suitable for billing, reservation, and other regulated domains.

REST offers the highest level of abstraction for public APIs but can be “chatty” on mobile networks.

GraphQL provides precise data fetching and a single evolving schema, yet it requires investment in learning and tooling.

Experiment with a small use case, validate that the chosen style solves the problem, then scale it if it proves effective.

Author: AltexSoft Inc Original article: https://blog.zhangbing.site/2020/12/13/comparing-api-architectural-styles-soap-vs-rest-vs-graphql-vs-rpc/ Source: https://levelup.gitconnected.com/comparing-api-architectural-styles-soap-vs-rest-vs-graphql-vs-rpc-84a3720adefa

Code example

相关阅读：