Yeah, once I realized this, HATEOAS / "strict" REST immediately went into my "nope" bucket. It's pretty much fine for humans and makes some compelling decisions in that context, but it's wildly unusable and unstructured for literally anything else and that makes it almost useless.

HTTP verbs and codes are plenty useful, and REST has been co-opted to mean "use verbs and codes correctly" and... I'm OK with that. It summarizes as "follow the patterns that much of the computing world relies on, so you don't break shit everywhere all the time" and that's something absolutely worth understanding and adopting in depth.

The downside to this boost in productivity is when the need for a mobile app comes along, now you need a non-REST API, too. Then you can take out GraphQL or gRPC or something suited for the task. Your mobile client would most likely be using a different surface of the API even if you had one for web clients, so it’s not like you’re wasting much effort here.

https://htmx.org/essays/splitting-your-apis/

We went on a wild goose chase trying to recreate a hypermedia client with javascript, contorting xmlhttprequest from an application api into a data api, on an already existing hypermedia client (the browser) because the latter stagnated and failed to fill out its functionality.

htmx adds the missing functionality to make the browser a functional hypermedia client.

That's the point I've never understood, and maybe someone here can clear it up for me?

As far as I understand, Fielding is constantly hammering on the point that navigation between resources should be hypertext-driven, so no "extraneous" information (where some resource or method is located) should be used. Only hypertext-style links from query/response to query/response.

But HTTP has very generic verbs. GET, PUT etc. They don't mean much.

Okay, REST proponents will say, while Fielding did his work in the context of HTTP, but envisioned a much richer hypertext capability.

Good. Now I have verbs like "Resize photo" or "Follow user" or "Get GPS coordinates from EXIF" in my hypertext API? How is a generic client supposed to understand those?

That's where I'm stuck. What's the use of it all if the client still needs to know everything about the domain (unavoidably, IMO)? Showing responses to the user and having him decide cannot be a real proposal, can it?

    {
      "response": {
        "actions": {
          "resizePhoto": {
            "method": "PATCH",
            "uri": "/photos/1",
            "body": {
              "w": "100",
              "h": "50"
            }
          }...

You either tightly couple the client to the API or you need AI, don't you?

And if the client needs to know that connection, how is that superior to having it do the PATCH dierectly?

This is great in theory, but very hard to do in practice.

Now that doesn't solve everything, because now you need to know relationship information too. Let's say a link on a mortgage application is `application/vnd.property.address`. Is this the property being purchased, or is this a property in the borrower's address history? The api needs to put an attribute of some kind on the links themselves to explain to a machine what they mean in context.

Humans surfing the web don't need this, they use their brains to understand from context what the link relationship is. And when they get to the new page, they don't need to have a hyper specific format for the exact page shape in order to be able to navigate the page. So while hypermedia is genius for the web, it forces an API developer to do all this insane busywork to make it so a "generic client" (which actually has a bunch of hard coded media types and link types in it) can navigate the API.

There's a reason this never took off

It’s the foundation of the World-Wide Web, which is the most successful platform in history. It solves a tonne of problems, that’s why it is so successful. You are using HATEOAS right now.

Maybe once we can run gpt-3 on a mobile phone lightning fast, we can start building these fuzzy, flexible apis and not worry about breaking our clients. But in the meantime, it's a ton of work for very little gain.