If you've been following along so far, you'll note that REST is not HTTP. It is also not the verbs of HTTP (GET, PUT, POST, or DELETE). You should know by now that REST contains the principles that guided HTTP. REST helped the HTTP standard describe how a well defined web server should behave.
The Fielding dissertation highlights how REST relates to HTTP mostly by way of its mismatches with HTTP. REST was used to identify problems and to compare solutions to those problems according to the requirements of the web. The early HTTP implementations were changed to more directly adhere to the REST architecture represented in the final HTTP 1.1 standard.
Many of the problems with early HTTP outlined in the REST paper were due to a lack of self
describing messages. If you recall from our previous discussion, the requirement for messages to be self describing is one of the interface constraints within REST.
There were several mismatches of REST with the early implementations of HTTP. Early http lacked full URLs (with hostname), had no way to layer MIME types, and had no way to signal the end of a message. It also conflated the parsing of headers with the parsing of header contents, had no content negotiation, could not differentiate authoritative from non-authoritative responses, and in some situations had problems with matching responses to requests altogether. These were for the most part corrected in HTTP 1.1 which was standardized in 1996.
In HTTP 1.1 however, there are still some mismatches. URIs and cookies can be and are abused to the point of obscuring messages. Mandatory extensions for headers violate self descriptiveness as well. Sometimes control data and other metadata can be intermingled. MIME is also inefficient when describing the media-type because it was designed for mail not hypermedia.
Nevertheless, REST helped HTTP become the primary protocol for web component communication and is unique in that it is designed specifically to manipulate resources via representation transfer. REST redefined what a resource meant within the context of HTTP. Sending representations, usually implemented in HTML, became the way to manipulate the resource on the remote server. REST also helped HTTP avoid extensions that would limit HTTP's scalability. Some of these extensions were MGET/MHEAD, write (PUT) caching, various persistent connection solutions, and some http versioning solutions. At the same time, it helped guide other unimplemented solutions like using self describing messages to implement HTTP's versioning scheme and the implementation of caching.
This article was originally published on wwatson.net