mca blog

Here is one way I talk about HTTP and Fielding's REST model:

the way of HTTP

HTTP was designed to favor long term (measured in years/decades) run-time stability over ease of implementation. to do this, it relies on some very simple (but powerful) constraints:

• every machine that operates over the WWW is constrained to a very tiny executable interface (what we know as the HTTP verbs). The details of this restricted interface are documented in a protocol that rarely changes over time and even when it does change, great pains are made to ensure these changes do not invalidate past implementations.
• every message sent over that interface consists to two basic parts: control data as a set of name-value pairs (HTTP Headers) and a single self-describing message body. This body can be "described" as 1) a structured document (text/html), 2) a binary image (image/png), 3) a list of arguments (application/x-www-form-urlencoded), etc. in HTTP the message contains not just data, but also instructions on how to operate on the data and what program-flow options are valid at that particular point in time. The list of "understood" message formats are publicly registered w/ the IANA today and is meant to evolve relatively easily over time in ways that do not "break" existing implementations.
• everything of importance is reachable using a universally understood address (URI). the list of addresses, while based on standards, is essentially unlimited and implementors are free to mint new ones as often as they wish and/or abandon existing addresses at any time.

the other way

implementing solutions under these constraints is usually quite different than what most programmers/architects learn in school. most training is "the reverse" of the above rules. Such that:

• the list of verbs in the interface is unlimited and their details (arguments, etc.) are subject to change. most implementation effort is focused on defining , documenting, and maintaining this variable interface.
• the program flow is found in code rather than in messages. usually in multiple place (clients and servers).
• the list of 'addresses' is constrained to the name of the executable programs themselves which do not change as often as the interface

why the differences matter

Fielding's dissertation, while focused on the details of identifying and documenting arbitrary styles of software architecture for distributed systems, still does a very good job of documenting a single example (or 'style') of software architecture that is closely aligned with the HTTP constraints listed at the top of this post. Fielding named his example "REST".

history has shown that the HTTP protocol is a very flexible protocol and that not all implementations need to follow the example provided by Fielding in order to meet the needs of users. for example, RPC over HTTP works just fine for many cases; esp. those that do not require system stability on the scale of years/decades.

however, the more important it is for the solution to continue to operate (and evolve) over an extended period of time, the more useful are the additional constraints Fielding identified in his example and the more important it is to optimize for run-time stability over ease/speed of initial implementation.