I'm writing Web API in ASP NET Core and I want to consume it from single page applications (e.g. using Angular, Vue, React), native desktop applications and mobile applications.
I stumbled across concept called "HATEOAS" and I learnt that the API I'm building isn't really RESTful and I wrongly named it RESTful (https://devblast.com/b/calling-your-web-api-restful-youre-doing-it-wrong).
And it seems like most of the people use this term badly (Roy T. Fielding - man behind REST idea about his annoyance: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven)
From what I learnt the idea behind HATEOAS is thinking of your application as you think of websites, that means it exposes links to resources (like <a href.../> in HTML) so you don't have to hardcode the links/endpoints in your client code and your client code won't break if you change some endpoint (?).
Another thing is that it makes your API discoverable without any documentation, i.e. API describes itself (like meta API)
When I look at the existing "REST" clients for C# for example:
They have "REST" in their name but none of them dig into the concept of HATEOAS. So why the heck are they named "Rest clients"?
How HATEOAS is supposed to be used on the client-side? To my surprise there isn't much about it on the internet, there's a lot about how to implement HATEOAS on the server, but there isn't much how it's supposed to work on the client. That most often should provide navigation logic.
Besides of that all, there are many API client generators (parsing OpenAPI specification) like AutoRest (nothing about hyperlinks and HATEOAS, to my surprise), or NSwag
I was googling for few hours to learn about HATEOAS, but most often people talk about it without describing how to use it (there are almost none client libraries supporting it).
There are many standards for it like HAL, Ion etc. But there are almost none rest client libraries implementing those standards. There's also json:api. All these standards are very similar.
So my question is:
Is HATEOAS applicable for applications like SPAs, mobile and desktop clients?
What's the real use case for HATEOAS, if I can as well hardcode my endpoints, or generate new API client from OpenAPI (Swagger) specification as it changes?
Is it even worth to bother with it?
There are almost none practical examples of interacting with HATEOAS or Hypermedia APIs, or am I missing something here and they're not supposed to be used by my client code?
To me it seems like implementing it on both client and the server is a lot of boilerplate code, so why aren't there many libraries supporting it out of the box (using one of the standard). It seems like json:api has many implementations http://jsonapi.org/implementations/#client-libraries-net
REST is a paradigm that applies more broadly than just the HTTP protocol and so-called "web APIs". A RESTful Web API, is one that simply applies principles from the REST paradigm to client-server communication over HTTP. As such, it doesn't necessary follow everything in REST and doesn't necessarily need to.
While HATEOAS is a nice concept, there's no HTTP client that actually implements it out of the box (at least that I'm aware of). You can feel free to make your API implement it, but that doesn't mean it will actually be used, and while your API may be "RESTful", it doesn't mean every client will be. Part of the foundation of the HTTP protocol is adaptive communication. In other words, a client need not support all the features of a server and vice versa. The client and server, instead, work with what they share in common in terms of functionality.