Include technical details of hypermedia approaches (as envisioned during early Internet) into section on static versus dynamic websites

[sbutler-gh]

In Static versus dynamic websites #, it could perhaps benefit from some references to and discussion of HTML-based hypermedia approaches — which can be simultaneously minimal, and dynamic/hybrid.

This even includes how APIs are structured — APIs that return HTML content, vs APIs that return JSON content. JSON objects may be smaller in terms of bytes, but they require significantly more code in order to process them and translate them into the interface. HTML objects are larger in terms of bytes, but they can be inserted directly into a given interface — there is no interpretation of the data, the HTML is just inserted into the client and processed with the appropriate stylesheets. (More details)

TLDR: Beyond a breakdown of static, dynamic, and hybrid, this section could include details about the inherent minimalism built into the vision of hypermedia — including:

• Transclusion

HTML could be extended to allow the responses to requests to replace elements within the current document, rather than requiring that they replace the entire document

This is actually a very old concept in hypermedia. Ted Nelson, in his 1980 book “Literary Machines” coined the term transclusion to capture this idea: the inclusion of content into an existing document via a hypermedia reference. If HTML supported this style of “dynamic transclusion”, then Hypermedia Driven Applications could function much more like a Single Page Application, where only part of the DOM is updated by a given user interaction or network request.

• REST-fulness and associated constraints

The “Constraints” of REST
In his dissertation, Fielding defines various “constraints” to describe how a REST-ful system must behave. This approach can feel a little round-about and difficult to follow for many people, but it is an appropriate approach for an academic dissertation. Given a bit of time thinking about the constraints he outlines, and some concrete examples, it will become easy to understand if a given system actually satisfies the architectural requirements of REST or not.

Here are the constraints of REST, which are outlined in Section 5.1 of his dissertation:

It is a client-server architecture (section 5.1.2)

> It must be stateless (section 5.1.3) that is, every request contains all information necessary to respond to that request

It must allow for caching (section 5.1.4)

It must have a uniform interface (section 5.1.5)

It is a layered system (section 5.1.6)

Optionally, can allow for Code-On-Demand (section 5.1.7), that is, scripting.

Let’s go through each of these constrains in turn and discuss them in detail, looking at how (and to what extent) The Web satisfies each of them.

• The simplicity of the GET, POST, PUT, PATCH, DELETE http method paradigm (in terms of code that makes sense and is self-evident)

• Client-side frontends that can be smaller (e.g. templates with small file sizes), and render content by GET-ting content from servers when requested (so the amount of data transferred is never more than it needs to be for a given page — you're loading content as people look at it, not automatically when they load the website)

• Discussion of thick clients vs thin clients — as it relates historically, going back to thick client client server architecture from the 80s before the web, and what the considerations mean today

• Taking all of this into account, what do modes and decisions like thin clients and hypermedia (which, by being thin client, may rely on more connectivity) mean for accessibility and access in different types of contexts? For example, in some places where bandwidth is less consistent, a web application built as a thick client that's usable offline may be preferable — you download it, and the use it locally, without relying on a server you may not have access to to work. These kinds of questions and conversations could open up the minimal computing side of things in a really interesting way, and expand its relevancy from the decision matrix of (static/dynamic/hybrid) to more diverse types of web app and software contexts.