Understanding API Design Styles: REST, RPC, GraphQL, and Data Serialization Formats

Although HTTP is an application‑layer protocol, it often serves as the transport mechanism for API development.

There are several ways to implement APIs over HTTP, each representing a different architectural style: REST, RPC, GraphQL, and others such as JSON, gRPC, protobuf.

1. REST (Representational State Transfer)

REST is an architectural style defined by a set of constraints; it treats resources as nouns and uses a limited set of verbs (GET, POST, PUT, DELETE, etc.). The mapping from REST concepts to HTTP is straightforward.

# Create new book
POST http://myapi.com/books/ (author="R. Feynman", year=1975) -> book_id
# Get book with ID = 1
GET http://myapi.com/books/1 () -> (id=1, author="R. Feynman", year=1975)
# Update book with ID = 1
PUT http://myapi.com/books/1 (id=1, author="Richard Feynman", year=1975) -> (...)
# Delete book with ID = 1
DELETE http://myapi.com/books/1 () -> nu

While most modern web frameworks provide tools to build RESTful services, designing a clean resource model can be challenging, and many “REST‑style” APIs are not truly RESTful.

2. RPC (Remote Procedure Call)

RPC focuses on actions (verbs). Each business operation is exposed as a procedure, e.g., createBook, getBook, setBookAuthor.

# Create new book
createBook(author, year) -> book_id
# Get book by ID
getBook(book_id) -> book
# Change book's author
setBookAuthor(book_id, author) -> null
# Delete book by ID
deleteBook(book_id) -> nu

In practice an RPC call is translated to an HTTP request, for example:

POST http://myapi.com/set-book-author/ (book_id=1, author="Richard Feynman") -> null

RPC can simplify certain updates but often leads to a proliferation of custom endpoints, making the API surface harder to manage.

3. GraphQL

GraphQL attempts to combine the strengths of REST and RPC. It defines a schema of types (entities) and relationships, exposing a single endpoint that accepts flexible queries, allowing clients to request exactly the data they need. The trade‑off is increased server and client complexity.

4. Data serialization formats (protobuf, JSON, etc.)

Serialization formats are orthogonal to the API style. Protobuf, for instance, is used by gRPC but can also be employed with REST APIs as an alternative to JSON or XML. Different frameworks (gRPC, Thrift) provide their own wire formats.

In summary, HTTP API design encompasses several architectural styles—REST, RPC, and GraphQL—each with its own advantages, drawbacks, and supporting frameworks such as gRPC and Apache Thrift. Choosing the right style depends on the trade‑offs between simplicity, flexibility, and maintainability.

Author

Ivan Velichko is a software engineer with ten years of experience in reliability and distributed systems, passionate about building robust backend services.