Java Interview Questions

Home / All Answers / REST HTTP

Question 1 · Section 6

What is REST?

It is not a protocol or a library, but a set of guidelines (constraints). A service can only be called RESTful if it follows all of these constraints.

English REST HTTP Source Markdown
Language versions: English Russian Ukrainian

Junior Level

REST (Representational State Transfer) is an architectural style for building web services, introduced by Roy Fielding in 2000.

It is not a protocol or a library, but a set of guidelines (constraints). A service can only be called RESTful if it follows all of these constraints.

Core Principles:

  • Resources: Everything in REST is a resource, identified by a URI (e.g., /users/1).
  • HTTP methods: Standard HTTP methods are used for resource operations:
    • GET — retrieving data
    • POST — creating data
    • PUT — updating data
    • DELETE — deleting data
  • Stateless: Each request contains all necessary information. The server does not store client state between requests.
  • Data format: Typically JSON or XML.

Example REST API:

GET    /users        — get all users
GET    /users/1      — get user with ID 1
POST   /users        — create a new user
PUT    /users/1      — update user with ID 1
DELETE /users/1      — delete user with ID 1

// Note: the resource is named in plural (/users), // and a specific instance is accessed via /users/{id}. This is a standard convention.

Six REST Constraints:

  1. Client-Server — separation of concerns between client and server
  2. Stateless — each request is independent
  3. Cacheable — responses can be cached
  4. Layered System — client doesn’t know about intermediate layers (proxies, CDNs)
  5. Uniform Interface — uniformity of interface: any resource is available through the same set of operations (GET/PUT/POST/DELETE), regardless of what the resource is.
  6. Code on Demand (optional) — server can transfer executable code

When NOT to Use REST

  1. High-frequency real-time streaming — use WebSockets or gRPC streams instead
  2. Internal microservices with strict latency requirements — use gRPC (binary, faster serialization)
  3. Complex graph queries — use GraphQL (single request instead of N REST calls)

Middle Level

REST vs RESTful

  • REST — an architectural style
  • RESTful — a concrete API implementation adhering to the REST style
  • Most “REST APIs” are actually HTTP APIs because they ignore HATEOAS

An HTTP API uses HTTP as transport but may ignore REST constraints (e.g., not using HATEOAS or violating idempotency). A RESTful API follows all 6 constraints.

Richardson Maturity Model

  • Level 0: HTTP as transport (RPC over HTTP)
  • Level 1: Using resources (individual URIs)
  • Level 2: HTTP methods and status codes (industry standard)
  • Level 3: HATEOAS (hypermedia as the engine of application state)

Content Negotiation

Server and client agree on data format through headers:

  • Content-Type: application/json — format of data being sent
  • Accept: application/json — format of expected response

Vary Header

The Vary header indicates which request headers affect the response:

Vary: Accept-Encoding, Authorization

Incorrect configuration can lead to caching issues.

Senior Level

Architectural Nuances

HATEOAS Problem in Microservices

HATEOAS requires the server to return links to related actions. In microservices this becomes a problem:

  • The microservice doesn’t know the external API Gateway URL
  • Solution: Using X-Forwarded-Host headers or special libraries (Spring HATEOAS)

URI Length Limit

The standard doesn’t limit URI length, but most servers and proxies (Nginx, AWS ALB) cap it at 8KB. If you pass huge filters in a GET request, you may get 414 URI Too Long.

HTTP Method Tunneling

If a corporate firewall blocks PUT/DELETE, use X-HTTP-Method-Override: DELETE inside a POST request.

Performance and Highload

  • Thundering Herd Problem: When a popular resource’s cache expires, thousands of requests may hit the DB simultaneously
    • Solution: “Soft expiry” or locks at the caching layer (Redis/Memcached)
  • Binary Format: For mobile clients or high-load systems, REST can serve MessagePack or CBOR, preserving HTTP semantics

Modernity (Java 21 / Spring Boot 3.3)

  • Virtual Threads (Project Loom): REST controllers can handle tens of thousands of connections without WebFlux (since Java 21, 2023; before that reactive stacks were the only way to handle tens of thousands of connections)
  • HTTP/3 (QUIC): Eliminates Head-of-Line blocking at the TCP level
  • Declarative Clients: @HttpExchange allows describing an API contract in an interface
  • Problem Details (RFC 9457): Standard JSON with fields type, title, status, detail, instance for error handling

Interview Cheat Sheet

Must know:

  • REST is an architectural style, introduced by Roy Fielding in 2000, not a protocol
  • 6 REST constraints: Client-Server, Stateless, Cacheable, Layered System, Uniform Interface, Code on Demand
  • RESTful API follows all 6 constraints; most “REST APIs” are just HTTP APIs without HATEOAS
  • Richardson Maturity Model: Levels 0-3, where Level 2 (HTTP Verbs + Status Codes) is the industry gold standard
  • REST is not suitable for real-time streaming (use WebSockets/gRPC) and complex graph queries (use GraphQL)
  • Content Negotiation works through Content-Type and Accept headers
  • HTTP/3 (QUIC) eliminates Head-of-Line blocking at the TCP level
  • Virtual Threads in Java 21 allow handling tens of thousands of connections without a reactive stack

Frequent follow-up questions:

  • What’s the difference between REST and RESTful? — REST is a style, RESTful is an implementation following all REST constraints
  • What is Uniform Interface? — Uniformity: any resource is available through the same set of operations (GET/PUT/POST/DELETE)
  • Which Richardson maturity level is the industry standard? — Level 2: HTTP methods and status codes
  • When is REST a bad choice? — Real-time streaming, internal microservices with strict latency, graph queries

Red flags (DO NOT say):

  • “REST is a protocol” — it’s an architectural style, not a protocol
  • “Any HTTP API is REST” — REST requires all 6 constraints including HATEOAS
  • “GET can be used for deletion” — GET must be safe, not change state
  • “HATEOAS is mandatory in every project” — for internal microservices and mobile apps, HATEOAS is excessive

Related topics:

  • [[What does Stateless mean in REST context]]
  • [[What is RESTful API design]]
  • [[What is HATEOAS]]
  • [[What HTTP status codes do you know]]
  • [[What is Accept header]]