REST != JSON
REST as a concept has been conflated and “incorrectly” intertwined with JSON and APIs; authors implore readers to set aside the idea that the two are interchangeable and that REST == JSON.
web applications are not islands
when writing a web application, you must remember that you are not building something in a vacuum; web applications should “play along” with the web. interactivity and even socialization is necessary.
accessibility
HTML, when written with the “full range of constituents of the hypermedia system,” is not only hypermedia-friendly, but highly accessible between mediums and formats (such as browser, screen readers, good-faith bots such as search engine scrapers and spiders, etc.)
good HTML is not inherently accessible. this implies that even the most semantic of HTML can be lacking in accessibility (ARIA comes to mind). to “shun” JavaScript would be a waste of potential for hypermedia-focused developers.
basic htmx
htmx is declarative by design, similar to href
and action
. unlike JavaScript, which requires inline scripting in the HTML, htmx integrates seamlessly into the HTML tags by introducing its own attributes. example from the book:
<button hx-get="/contacts/1" hx-target="#contact-ui">
Fetch Content
</button>
hx-get
issues a GET
request, which then takes the content of the value of hx-get
(in this example, /contacts/1
) and targets any element with the unique ID of #contact-ui
. the “target” in this example is named as such because the GET
request and its result will “target” the element tagged with that unique ID, and then replace the content of that element with the result of the GET
request.
the book emphasizes that, unlike JavaScript-shaped applications, htmx dictates that the server’s HTTP response will always be in HTML rather than JSON.
PUT
vs. POST
and other HTTP request things
POST
: can be handled in any way by the server
PUT
: replace the resource being handled
only GET
and POST
are natively handled by HTML; to issue PUT
, PATCH
, and DELETE
, JavaScript must be used. htmx seems to be a way to rectify this.
REST’s original meaning
REST, as originally coined by Roy Fielding in his PhD dissertation, was pre-JSON and pre-API. thus, this book argues that REST in its original intention was designed for a hypermedia-oriented web, but ironically became conflated with JSON APIs which are less REST-ful by the original definition.
i wonder if the formal definition and adoption of REST after Fielding’s dissertation changed this? if it formally became related to JSON and APIs?
worth noting that JSON is a JavaScript related invention; the full name is JavaScript object notation.
htmx as an extension of HTML
htmx was invented by the authors to elevate and extend the power and capability of HTML through the raw hypermedia approach; by leveraging JavaScript without fully supplanting HTML with it, htmx is able to build on the design of HTML with hypermedia specifically in mind so that HTML can adopt modern design practices (such as the style of an SPA that doesn’t require a full-page refresh to update information) without sacrificing its simplicity and semantics.