Architecture Of The Web

The birth of the web

The idea of the web originated from the CERN laboratory by Tim Berners-Lee.

Scientists from all over the world would visit CERN to use its accelerator, but they had difficulty sharing information.

Tem Berners Lee saw the problem and he had his eureka moment.

Millions of computers were already connected through the network, so existing infrastructure could be utilized to share the information among computers. His idea was to design a loosely connected system that communicates using hypertext.

This idea eventually gave birth to the web in 1989 and he wrote his first web browser in 1990.

The browser technology was made open source and became available to the general public.

Shortly thereafter, every business wanted to establish a web presence. This discovery was central to the Information Age. Now, billions of people use the internet to share information.

Architecture of world wide web

As documented by the World Wide Web Consortium (W3C) in its Architecture of the World Wide Web:

“The World Wide Web (WWW, or simply Web) is an information space in which the items of interest, referred to as resources, are identified by global identifiers called Uniform Resource Identifiers (URI).”

Based on the above definition web constitutes of:

1. Resources
2. URI

Resources

Resources are the fundamental building blocks of web-based systems. Everything on the web is a resource. A resource is anything from a simple text document to an audio or video clip. From a consumer’s point of view, a resource is anything with which that consumer wants to interact. Now think about our EliteClub and Billionaire club application. If we apply the same web philosophy to our application our resources are Clubs and Billionaires.

URI/URL

To interact with a resource we need its address on the web and have some way of requesting it or manipulating it. The web provides a URL (uniform resource locator) to make a resource addressable. A URL is composed of 3 parts.

1. Protocol: Protocol can be HTTP, FTP, etc.
2. Resource Address: Location of server resolved using IP address.
3. Resource: Resource being requested or manipulated.

Let’s see the 3 parts with this example URL: https://en.wikipedia.org/wiki/World_Wide_Web

1. Protocol is HTTPS.
2. Resource Address is en.wikipedia.org resolved using DNS.
3. Resource is /wiki/World_Wide_Web.

It’s the responsibility of the machine “listening” at en.wikipedia.org to map the remainder of the URL, /wiki/World_Wide_Web, to the actual resource.

Resource formats

Now we have resource location but now the question is in what format resource should be served? Good thing the web does not advocate any specific format. A resource should be like water; it can take any shape, such as HTML, ATOM, XML, JSON, PDF, JPG, CSV, or Plain text.

This separation between a resource and its representations promotes loose coupling between server and consuming applications.

To illustrate the importance of the representation format we have modeled our author URL with different representations.

In the example above, we have decided to make only HTML and JSON representations of the resource available. Many more representations of the same resource could be served using formats such as PDF, JPEG, MPEG video, and so on.

If a server is providing multiple representations of the same information. How can a consumer ask for a specific representation?

Using content negotiation, consumers can negotiate for specific representation formats from a service. They do so by populating the HTTP Accept request header with a list of media types they’re prepared to process.

The art of web communication

We have knitted some threads together to see how resources, representation formats, and URIs help us build systems.

But how do we act on them?

The answer is that the web provides HTTP verbs to act on resources.

The set of verbs supported by HTTP are GET, POST, PUT, DELETE, OPTIONS, HEAD, TRACE, CONNECT, and PATCH forms a sufficient vocabulary to support a wide range of actions.

HTTP defines a set of status codes and HTTP verbs, such as 200 OK, 500 Error, and 404 Not Found, that coordinate the interactions triggered by the verbs. Verbs and status codes, provide a framework for working with web resources when combined.

Key takeaways

Now that we understand the architecture of the web & what are key components of web architecture. Let’s put all of them together.

• Resource: Anything being requested over the web.
• URI: Location of resource
• Representation: Same resources can be presented in multiple formats like HTML, XML, JPG, etc.
• Verbs: Verbs represent action on a resource.
• HTTP status code: Combined with verbs, they orchestrate the flow and navigation.