12
HTMX creator on the history of REST and why he thinks we got it wrong (www.youtube.com)
submitted 1 week ago by to c/programming@programming.dev
2 comments fedilink hide all child comments
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 1 week ago* (last edited 1 week ago) (1 child)

Is he confusing REST with AJAX? AJAX was supposed to return HTML but is nowadays often used to return JSON, yes mostly from a REST API.

But I would expect to get well structured data from a REST API. If you return HTML you might as well return it directly suited for presentation which may not be very well suited for data parsing by a computer.

Edit: No, he's not confusing them. The first guy coining the REST term defined them as explicitly returning hypertext. Sounds like every webserver ever to me.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
  • [–] 6 points 1 week 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.

  • permalink
  • fedilink
  • source
  • parent