> What I'm looking for someone to answer is, when I control both the client and server, why is this a benefit? If you (and only you, personally) control both t

> What I'm looking for someone to answer is, when I control both the client and server, why is this a benefit? If you (and only you, personally) control both the client and the server (and by "control" I mean you can update/deploy them as you please, simultaneously if necessary), you can feel free to use any sort of homebrew efficient binary stateful protocol and format you like, with no consequence. However, the more parties that are involved (co-workers, separate teams, external organizations, etc.), and the less those parties are able/willing to synchronize their efforts over time, the more benefit you will see from aspects of REST and HATEOAS. Most developers aren't working in a domain and environment where the diversity of stakeholders is maximally broad for both the client(s) and server(s), so "going full HATEOAS" is often overkill, but you should still understand it, in the same way that you need to understand why data schemas ideally conform to fourth normal form, even if your production data is denormalized in practice. While some benefits from some REST practices can start accruing even in the single developer situation, simply because there can be costs to coordinating between present-you and various versions of past-you and future-you, and their respective client and server deployments, that only makes a case for partial adoption. By all means, only use the practices and patterns that make sense and solve or avoid a pain point for you in your situation rather than being dogmatic. In that sense, REST and HATEOAS shouldn't be considered in any different light than other aspects of writing software such as external dependencies, or changing the toolchain, or splitting some code into its own library or module, or publishing code as open source; sometimes it makes sense, sometimes not (especially when the costs are concrete and the benefits hypothetical).