Spring Boot – HATEOAS (Notes + Extra)

 

Spring Boot – HATEOAS (Notes + Extra)

1. What is HATEOAS?

HATEOAS =

Hypermedia As The Engine Of Application State

It means:

The API response itself tells the client what next action it can perform.

So the client does NOT need to hardcode which API to call next.

2. Concept from Page 1 (State Flow Diagram)

The diagram shows a User Verification Flow:

POST /addUser
        |
   Unverified User Added
        |
  -------------------------
  |        |             |
GET user  DELETE user   VERIFY user
                         |
           -----------------------------
           |                           |
    SMS Verify                  EMAIL Verify
    (start → finish)          (start → finish)

Each state tells the client what link (action) is valid next.

3. Without HATEOAS (Tight Coupling)

From page 1:

{
  "userID": "123456",
  "name": "SJ",
  "verifyStatus": "UNVERIFIED"
}

❌ Problem:

  • Client must decide logic
  • Client must know URLs
  • Client must know flow rules

This causes tight coupling.

4. With HATEOAS (Loose Coupling)

From page 1:

{
  "userID": "123456",
  "name": "SJ",
  "verifyStatus": "UNVERIFIED",
  "links": [
    {
      "rel": "verify",
      "href": "http://localhost:8080/api/sms-verify-start/123456",
      "type": "POST"
    }
  ]
}

✅ Client simply follows the link.
No business logic in UI.

5. Why Use HATEOAS?

From page 1:

Two major goals:

  1. Loose Coupling
  2. API Discovery

Server tells:

  • Which API to call
  • When to call
  • What method to use

6. Warning (Page 2)

❌ Never add all possible next APIs blindly

Because it causes:

  • Bigger payload
  • More latency
  • Server complexity

We must expose only valid next actions.

7. Tight Coupling Example (Page 2)

Client-side logic:

if(verifyStatus == "UNVERIFIED") {
   if(verifyType == "SMS") {
      if(state == "NOT_STARTED") call /sms-verify-start
      else call /sms-verify-finish
   } else {
      if(state == "NOT_STARTED") call /email-verify-start
      else call /email-verify-finish
   }
}

❌ Client is controlling business rules → BAD.

8. HATEOAS Solution (Page 3)

Now server sends:

{
  "userID": "123456",
  "verifyStatus": "UNVERIFIED",
  "links": [
    {
      "rel": "verify",
      "href": "http://localhost:8080/api/sms-verify-finish/123456",
      "type": "POST"
    }
  ]
}

Client just:

invoke(link.href)

9. Dependency (Page 3)

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-hateoas</artifactId>
  <version>2.6.4</version>
</dependency>

10. Creating Links (Page 3)

Link verifyLink = Link.of(
   "api/sms-verify-finish/" + response.getUserID())
   .withRel("verify")
   .withType("POST");

EXTRA INTERVIEW POINTS

Without HATEOAS With HATEOAS
Client has logic Server controls flow
Tight coupling Loose coupling
Hardcoded URLs Dynamic links
Hard to change Easy to evolve APIs

SHORT INTERVIEW Q&A

Q1. What problem does HATEOAS solve?
➡ Tight coupling between client and server.

Q2. Does HATEOAS change REST?
➡ No, it completes REST.

Q3. Should we expose all links always?
➡ No. Only valid next actions.

Q4. Where is logic stored?
➡ On the server, not the client.

Q5. Which Spring dependency is needed?
➡ spring-boot-starter-hateoas

  •  
Tags:

Leave a Reply