DEV Community

Cover image for Hypermedia as the Engine of Application State (HATEOAS)
Athreya aka Maneshwar
Athreya aka Maneshwar

Posted on • Edited on

Hypermedia as the Engine of Application State (HATEOAS)

Hello, I'm Maneshwar. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

I'm working on FreeDevTools online currently building **one place for all dev tools, cheat codes, and TLDRs — a free, open-source hub where developers can quickly find and use tools without any hassle of searching all over the internet.

HATEOAS is a constraint of REST that sets it apart from other network application architectures.

It allows clients to dynamically navigate APIs using hypermedia links without requiring prior knowledge beyond a basic understanding of hypermedia itself.

At its core, HATEOAS enables the server to guide the client by embedding links within responses.

This theoretically decouples clients from ser
vers, allowing the latter to evolve independently.

But here’s the catch: HATEOAS doesn’t work for APIs in the real world.

The Ideal vs. The Reality

Let’s compare two approaches: one that follows HATEOAS and one that follows a typical JSON API design.

HATEOAS in Action

Consider a GET request to fetch a bank account:

GET /accounts/12345 HTTP/1.1
Host: bank.example.com
Enter fullscreen mode Exit fullscreen mode

The server responds with hypermedia links embedded in the HTML:

<html>
  <body>
    <div>Account number: 12345</div>
    <div>Balance: $100.00 USD</div>
    <div>Links:
        <a href="/accounts/12345/deposits">deposits</a>
        <a href="/accounts/12345/withdrawals">withdrawals</a>
        <a href="/accounts/12345/transfers">transfers</a>
        <a href="/accounts/12345/close-requests">close-requests</a>
    </div>
  <body>
</html>
Enter fullscreen mode Exit fullscreen mode

When the account is overdrawn, the response dynamically changes:

<html>
  <body>
    <div>Account number: 12345</div>
    <div>Balance: -$50.00 USD</div>
    <div>Links:
        <a href="/accounts/12345/deposits">deposits</a>
    </div>
  <body>
</html>
Enter fullscreen mode Exit fullscreen mode

The client doesn't need to know anything about account states—it just follows the links provided.

JSON API Without HATEOAS

Now, compare this with a more typical JSON API response:

{
    "account": {
        "account_number": 12345,
        "balance": {
            "currency": "usd",
            "value": -50.00
        },
        "status": "overdrawn"
    }
}
Enter fullscreen mode Exit fullscreen mode

Here’s the issue: the client needs out-of-band knowledge (from documentation) to understand what status: "overdrawn" means and what actions are allowed.

The client must also know endpoint URLs, which are not embedded in the response.

Why HATEOAS Fails in APIs

In theory, HATEOAS should make APIs self-explanatory and adaptable.

In practice, it doesn’t work because:

  1. Few Good Tools Exist – Most API frameworks don’t have strong support for HATEOAS.
  2. Clients Don’t Use It – API consumers rarely build clients that dynamically discover actions from responses.
  3. Developers Still Need API Documentation – Since no standard conventions exist for representing actions, developers must rely on external documentation.
  4. Versioning Is Still Needed – HATEOAS was meant to allow seamless API evolution, but clients still break when APIs change.

Even Roy Fielding, the creator of REST, has criticized the misuse of the term “REST API” for JSON-based RPC-like designs.

REST Is Still Useful, But Not Sacred

REST is great, but it’s not the only option. While RESTful principles like statelessness and resource-based interactions are valuable, HATEOAS is largely impractical.

Most modern APIs function more like RPC-over-HTTP than true RESTful systems.

If you’re building an API today, don’t get stuck on HATEOAS.

Instead, focus on clear documentation, strong API contracts, and developer experience.

Final Thoughts

REST isn’t dead, but it’s not a religion.

The industry has moved beyond HATEOAS, and that’s okay.

**Choosethe API architecture that best fits your need---

A collection of UI/UX-focused tools crafted to simplify workflows, save time, and reduce friction in searching tools/materials.

Any feedback or contributors are welcome!

It’s online, open-source, and ready for anyone to use.

👉 Check it out: ⭐ Star it on GitHub:

Let’s make it even better together.

git-lrc
*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

GitHub logo HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc logo

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit


git-lrc - Free, unlimited AI code reviews that run on commit | Product Hunt

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

See git-lrc catch serious security issues such as leaked credentials, expensive cloud operations, and sensitive material in log statements

git-lrc-intro-60s.mp4

Why

  • 🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
  • 🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
  • 🔁 Build a habit, ship better code. Regular review → fewer bugs → more robust code → better results in your team.
  • 🔗 Why git? Git is universal. Every editor, every IDE, every AI…




Top comments (0)