Hypermedia Systems

tags

Hypermedia

Notes

many developers ignore the hypermedia features of the browser, in favor of building their web applications entirely in JavaScript. Applications built in this manner have come to be called Single Page Applications (SPAs).

We define a hypermedia system as a system that adheres to the RESTful network architecture in Fielding’s original sense of this term.

in his dissertation, Fielding was describing The World Wide Web as it existed in the late 1990s. The web, at that point, was simply web browsers exchanging hypermedia.

Hypermedia was a great idea! It still is!

In a sad turn of events, today, the world’s most popular hypermedia, HTML, is often viewed resentfully: it is an awkward, legacy markup language that must be grudgingly used to build user interfaces in what are increasingly entirely JavaScript-based web applications.

Hypermedia is a media, for example a text, that includes non-linear branching from one location in the media to another

It is the form tag that makes Hypermedia-Driven Applications possible.

Only two tags!

the crucial aspect of this JSON-based server interaction is that it is not using hypermedia. The JSON API being used here does not return a hypermedia response. There are no hyperlinks or other hypermedia-style controls in it.

the code in updateUI() needs to know about the internal structure and meaning of the data.

the updateUI() code and the API have a strong relationship, known as tight coupling: if the format of the JSON response changes, then the code for updateUI() will almost certainly also need to be changed as well.

HTML is still used to build user interfaces, but the hypermedia aspect of the two major hypermedia controls, anchors and forms, are unused. Neither tag interacts with a server via their native hypermedia mechanism. Rather, they become user interface elements that drive local interactions with the in-memory domain model via JavaScript, which is then synchronized with the server using plain data JSON APIs.

The Single Page Application offers a far more interactive and immersive experience than the old, gronky, Web 1.0 hypermedia-based applications could.

extremely simple approach to building web applications.

extremely tolerant of content and API changes.

leverages tried and true features of web browsers

“JavaScript Fatigue.” This refers to a general sense of exhaustion with all the hoops that are necessary to jump through to get anything done in modern-day web applications.

expressiveness of HTML as a hypermedia hasn’t changed much, if at all, since HTML 2.0, which was released in the mid 1990s.

as the interactivity and expressiveness of HTML has remained frozen, the demands of web users have continued to increase

It was the user experience that you could achieve in JavaScript, and that you couldn’t achieve in plain HTML, that drove the web development community to the JavaScript-based Single Page Application approach.

use JavaScript to augment HTML itself as a hypermedia.

The HTTP response from the server is expected to be in HTML format, not JSON.

this htmx-powered button is exchanging hypermedia with the server

Htmx extends the hypermedia system of the web, rather than replacing that hypermedia system with a totally different architecture.

there is no need for client-side routing, for managing a client-side model, for hand-wiring in JavaScript logic, and so forth. The back button will “just work.” Deep linking will “just work.”

at the time Fielding wrote his dissertation, JSON APIs and AJAX did not exist. He was describing the early web, with HTML being transferred over HTTP by early browsers, as a hypermedia system.

In practice, for many web applications today, we actually violate this constraint: it is common to establish a session cookie

This violation of the Statelessness REST architectural constraint has proven to be useful for building web applications and does not appear to have had a major impact on the overall flexibility the web.

sessions do cause additional operational complexity headaches when deploying hypermedia servers

the most interesting and, in our opinion, most innovative constraint in REST: that of the uniform interface.

all information necessary to both display and also operate on the data being represented must be present in the response. In a properly RESTful system, there can be no additional “side” information necessary for a client to transform a response from a server into a useful user interface. Everything must “be in” the message itself, in the form of hypermedia controls.

uniform interface degrades efficiency

the JSON API client must know in advance exactly what other URLs (and request methods) are available for working with the contact information.

the hypermedia client (that is, the browser) needs only to know how to render the given HTML. It doesn’t need to understand what actions are available for this contact: they are simply encoded within the HTML response itself as hypermedia controls.

The browser, our hypermedia client, simply renders the HTML and allows the user, who presumably understands the concept of a Contact, to make a decision

in a RESTful system, hypermedia should be “the engine of application state.” This is sometimes abbreviated as “HATEOAS”

hypermedia APIs do not have the versioning headaches that JSON Data APIs do.

perhaps the most important thing to understand about htmx: it expects the response to this AJAX request to be HTML.

htmx provides another attribute, hx-swap, that allows you to specify exactly how the content should be swapped into the DOM.

the overall feel of htmx is declarative rather than imperative. That keeps htmx-powered applications “feeling like” standard web 1.0 applications

our experience with this pattern has not been great, for reasons that should be clear given the differences we outlined between Data and hypermedia APIs: they have different needs and often take on very different “shapes”, and trying to pound them into the same set of URLs ends up creating a lot of tension in the application code.

breaking the JSON Data API out to its own set of URLs is the right choice.