Carson Gross, creator of HTMX, discusses how REST was originally defined, how the industry ended up calling JSON over HTTP “REST”, and why he thinks returning HTML from the server is closer to the original idea.

The discussion also covers HTMX 4, when you actually do need a SPA, and how AI changes the tradeoff between simple and clever code.

Full episode: https://youtu.be/9xs0oZN2rs4

4’ video on the history of REST: https://www.youtube.com/watch?v=DbNvpiJ9gTs

  • expr@programming.dev
    link
    fedilink
    arrow-up
    5
    ·
    2 days ago

    No, the author is not confusing them. It’s everyone else that has been confused insofar as they use “REST” to describe APIs that are not actually REST. True REST is a way of architecting networked applications according to a set of constraints, as defined by Roy Fielding in his original dissertation. Here’s an excerpt that sums it up:

    In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.

    Many “REST” APIs do not adhere to these constraints, especially self-descriptive messages and hypermedia as the engine of application state (also known as HATEOAS). Note that this says nothing about HTML: HTML is but one representation of hypermedia, but far from the only one. Hypermedia is something that allows discovery of additional, related resources by way of links between resources. There are a number of ways of doing this, such as RFC 8288 Link Headers or embedding links within one of a resource’s representations (such as a JSON representation).

    It’s a much larger topic than I can fully explain here, but I highly recommend reading Roy Fielding’s dissertation, especially Chapter 5 which talks about REST and what it is.

    I also highly recommend this blog post from Google Cloud’s engineering team, which talks about why you should use links instead of keys to represent relationships in API design: https://cloud.google.com/blog/products/application-development/api-design-why-you-should-use-links-not-keys-to-represent-relationships-in-apis.