Bubbles_glow

≡ Literary Systems ≡

 
Corner_fold
  • Citation
  • Extension
  • Response
  • Comment
Hopo_catalog
Literary Systems
 
Flowchart_grey_24

The Architecture of the Web

The study of the use of hypertext on the web must begin with the fundamentals of web architecture. Originally designed by Tim Berners-Lee, and later expanded by Roy Fielding, the general architectural style of the web is now called REST, which stands for Representational State Transfer. REST is a far cry from what hypertext theorists first intended to become the world's global hypertext system, Ted Nelson has always been extremely critical of the web, writing this tiny plaintext tirade:
I DON'T BUY IN

The Web isn't hypertext, it's DECORATED DIRECTORIES!

What we have instead is the vacuous victory of typesetters over authors, and the most trivial form of hypertext that could have been imagined.

The original hypertext project, Xanadu®, has always been about pure document structures where authors and readers don't have to think about computerish structures of files and hierarchical directories. The Xanadu project has endeavored to implement a pure structure of links and facilitated re-use of content in any amounts and ways, allowing authors to concentrate on what mattered.

[...]

Markup must not be embedded. Hierarchies and files must not be part of the mental structure of documents. Links must go both ways. All these fundamental errors of the Web must be repaired. But the geeks have tried to lock the door behind them to make nothing else possible.

We fight on.

More later.
REST is technically an architectural style, not an architecture. It's a coordinated set of constraints on the body of potential architectures. This sort of meta-architecture-by-constraint was pioneered by Christopher Alexander, with his widely influential idea of design patterns. The constraints that make up REST were developed with "anarchic scalability" in mind, to produce a system where there are no centralized bottlenecks to growth. The elimination of two-way links, part of the central dogma of hypertext theory, way a key part of pursuing this scalability: two-way links simply don't scale. The burden of back-links that an immensely popular site would accumulate would be overwhelming, both visually and in terms of bandwidth. REST was developed to try and maximize the following qualities, in no particular order, of global-scale hypertext systems:
Performance, Scalability, Simplicity, Evolvability, Extensibility, Customizeability, Configurability, Reusability, Visibility, Portability, Reliability.
The architecture that was created under REST ideals, and that serves as the backbone of the web today, grew into three pieces: URI, HTTP, and HTML. HTTP is the protocol that computers speak to send each other hypertextual documents. One of the most important characteristics of HTTP is that it is designed to be stateless. Both the viewer and the server act as if they forget all about each other, and start fresh with every request. This constraint goes against many of the classic hypertexts, which depended on the ability to keep track of the path of particular readers.

Tim Berners-Lee's original proposal for the web had an idea that has since fallen by the wayside: the link type. His paper, "Information Management: A Proposal", had a large diagram on the cover that showed many concepts connected with clearly typed links: "depends on", "is part of", "made", "refers to", "uses", and "is an example of". He wrote down his rationale: "In practice, it is useful for the system to be aware of the generic types of the links between items, and the types of nodes without imposing any limitations." There are many other writers who have weighed in on the usefulness of link types.

This website tries to bring typed links back to hypertext on the web, as one, humble literary form to help enrich your writing. The legend on the left-hand side tells you what color is associated with what sort of link. If you happen to be working on a text, you can click the legend to create link types of your own and choose their colors. It's a modest experiment for the literary system of the web, and has had some interesting results. You can explore the Grand Library to see what people have been doing with them.


 
Here's how the architecture grew, as described in Fielding's dissertation:

First we add the Client-Server constraint, which separates the interface from the data storage and retrieval. This provides portability, scalability, and allows for independent evolution of the two parts.

Then we make it Stateless. Each request must hold all of the context that the server needs to fulfill that request. This increases the visibility of the system, as each request can be treated as a complete and independent entity. You only have to look at the request to see all the information you need. This increases scalability at the expense of speed, as more information is being transmitted redundantly.

Now, we add a Caching ability. A response must be labeled cacheable or non-cacheable. The client can cache data, to avoid requesting it again for later requests. This increases efficiency and speed at the cost of reliability, if you happen to run into stale data.

And then, as perhaps REST's biggest innovation, we add a Uniform Interface. Every request should be made with the same kind of grammar, using the four HTTP verbs (GET, PUT, POST, DELETE), as a kind of minimal language for accessing, updating, saving and removing resources on the web. In this way the implementation is decoupled from the interface, allowing you to provide consistent APIs (and therefore long-lasting URIs) while your code changes behind the scenes. This works best when used in the context of four web principles: The need to identify resources with good, permanent URIs. The ability to manipulate resources via representations. That each request is a self-descriptive message. And that hypermedia drives state.

Now, we make it a Layered System. No component should be able to have knowledge beyond the single layer that it interacts with. This increases the compartmentalization of the web. (The browser doesn't reach down to mess with the TCP/IP packets, for instance.)

And lastly, add the ability for Code-On-Demand. For any additional programmatic functionality, you can download scripts to do it, so that the browsers themselves can remain simpler. This constraint is optional.

All these together build up a long string of adjectives: Replicated, Separated, Layered, Programmable, Uniform, On-Demand, Stateless, Visible, Reliable, Shared, Extensible, Reusable, Scalable REST!