Tech Notes

Layer 7 The Application Layer REST

4 min read

REST in the Application Layer

When systems talk to other systems (not browsers), they usually do so via APIs.

There are three major API paradigms:

  • REST
  • GraphQL
  • GRPC

Among these, REST is the default and most common choice, especially in system design interviews.

Summary

REST is a simple, flexible way to expose application functionality over HTTP using resource-based thinking.

Core Idea of REST

REST stands for Representational State Transfer.

The key idea:

  • Systems expose resources
  • Clients perform standard operations on those resources

Think of resources like:

  • Database tables
  • Files on a server
  • Domain entities

Analogy:
REST treats your system like a remote file system where you read, create, update, and delete files using standard commands.

Resources, Not Actions (Very Important)

REST forces a mindset shift.

Bad (action-based thinking):

  • UpdateUser
  • StartGame
  • CancelOrder

Good (resource-based thinking):

  • User
  • Game
  • Order

Operations are expressed using HTTP verbs, not method names.

Important

REST models nouns (resources), not verbs (actions).

Mapping REST to HTTP

REST uses:

  • HTTP methods to express intent
  • URL paths to identify resources
  • Request/response bodies to represent resource state

This reuse of HTTP semantics is what makes REST simple and powerful.

Basic REST Patterns (CRUD)

Assume User is a JSON object.

Read a resource

GET /users/{id} → User
  • GET = fetch
  • {id} = resource identifier
  • No request body

Update an existing resource

PUT /users/{id} → User
    {
      "username": "john.doe",
      "email": "john.doe@example.com"
    }
  • PUT = replace/update resource
  • Resource already exists
  • Client sends new representation

Important

PUT is typically idempotent (same request → same result).

Create a new resource

POST /users → User
    {
      "username": "stefan.mai",
      "email": "stefan@hellointerview.com"
    }
  • POST = create
  • Server assigns the ID
  • Client does not specify {id}

Delete a resource

DELETE /users/{id}
  • DELETE = remove resource
  • Should be idempotent

Nested Resources (Relationships)

REST can express relationships through path nesting.

Example:

  • One user

  • Many posts

    GET /users/{id}/posts → [Post]

This communicates:

  • Ownership
  • Hierarchy
  • Containment

Summary

Path structure explains relationships between resources.

REST and Domain Modeling

In system design:

  • Your core entities often map directly to REST resources
  • This makes APIs intuitive and consistent

Example:

  • User entity → /users
  • Order entity → /orders
  • Product entity → /products

Tip

If your domain model is clean, your REST API usually designs itself.

REST Conventions (Not Strict Rules)

REST is opinionated, not rigid.

Common conventions:

  • JSON for request/response bodies
  • Plural nouns for collections
  • Predictable paths
  • Meaningful HTTP status codes

But:

  • REST does not require JSON
  • REST does not enforce one “correct” structure

What REST is NOT

REST is often misunderstood.

Not RESTful:

  • POST /updateUser
  • POST /startGame
  • GET /doPayment

These describe actions, not resources.

RESTful alternatives:

  • PUT /users/{id}
  • PATCH /games/{id} { “status”: “started” }
  • POST /payments

Warning

If your API reads like function calls, it’s probably not RESTful.

Performance Considerations

REST tradeoffs:

  • JSON is verbose
  • Serialization/deserialization costs CPU
  • Not ideal for extremely high throughput systems

However:

  • Most systems are not bottlenecked here
  • Simplicity usually wins

Summary

REST optimizes for clarity and flexibility, not raw performance.

Where REST Shines

REST works well for:

  • CRUD-heavy systems
  • Public APIs
  • Internal microservices
  • Admin and configuration APIs

Real-world example:

  • ElasticSearch uses REST to manage documents, indexes, and clusters

Where REST Struggles

REST may not be ideal for:

  • Real-time streaming
  • Bi-directional communication
  • Very low-latency, high-throughput systems

Alternatives:

  • GraphQL → flexible querying
  • GRPC → high-performance RPC
  • WebSockets / SSE → realtime updates

REST in System Design

Why REST is the default:

  • Well understood
  • Easy to reason about
  • Maps cleanly to HTTP
  • Widely adopted

Interview guidance:

  • Default to REST
  • Switch only if requirements demand it

Important

Like TCP, REST is a safe and expected default in interviews.

Mental Model for Revision

  • REST = resource-oriented design
  • URLs identify resources
  • HTTP verbs express intent
  • JSON represents state
  • Stateless by default
  • Scalable by design

Summary

REST is about modeling your system as resources and using HTTP correctly to operate on them.

Graph View

Backlinks