Why?

Rest is a style derived from other ones, “the REST style draws from many preexisting distributed process paradigms, communication protocols, and software fields“.

Http can be used to implement a REST based system, with several limitations, and some key aspects are implemented through http, but not described within it. One example is semantics and hypermidia: one can make use of http with hundreds of resources that does not provide any semantic value or hyperlinks, creating hundreds of tight coupled entry points.

Why do we stick to basic http after so many years?

After so many years of REST, why aren’t we able to create systems that deals with all the information required?

First, as Roy himself mentioned, his job was to research something, not apply it to practical contemporary concerns. Througtout the REST chapters in his dissertation, media types and general examples are almost always related to web spidering and information retrieval systems.

And it was left to others to fill in the gaps and discover a way to take advantage of the architecture between those systems (REST) and apply them to our application problems: “Fortunately, there are more than enough people who are specialist enough to understand what I have written (even when they disagree with it) and care enough about the subject to explain it to others in more concrete terms“.

And this is actually good. It is a typical scenario where researchers (specialists) look out for new ideas while practitioners (mixed field specialists) apply them to different scenarios or even dig it even deeper. As a researcher himself, he mentions the importance of those who apply these knowledge: “That’s a good thing, because it helps refine my knowledge of the field as well”.

In several moments in history we saw different people having an idea, going through the pain of research, while others would apply those ideas into real life, going through the pain of adapting to restrictions.

This is part of an idea life cycle and both researchers and practitioners are essential to invent and build something that aid us with our problems.

So first it is left to us to apply it to our application problems: transactions, procurement, dynamic clients and so on.

HTTP libraries

Let’s imagine that EJBs, CORBA, or any RPC protocol was implemented in a library in a way that the user is responsible for i.e. marshalling its content:


result = MyLibrary.send("header content", 1287361278361278365674)
if result==200
order_price = result.body[95..100]
else
raise "unable to retrieve order information"
end


What hapenned? Is it really an EJB/Corba/RPC implementation if you have to marshal/unmarshal on your own? Or is it just a socket library that sends the client information to the server and partially parses the response? In the same way, an HTTP library that only organizes your headers and sends it to the servers, returning parsed information back to the user, is not yet an http library.

If you pick Ruby’s Net:HTTP implementation, it does not automatically follow a 303 or 307/GET as the http specification dictates, but returns the response code to you. Meanwhile Jakarta Common’s HTTP Client does.

All http libraries we use implement http to some degree and are great doing so, i.e. http party and jakarta commons http client, but there is still more to support to create a rest client library.

Implementing part of http, socketing your data in the correct form, but nothing else, led us to believe that’s all http is about, and we had wrongly affirmed that REST is the same thing for all this time.

Hypermedia, code on demand, local cache, knowledge and interpretation of media types, everything that is not a direct implication of http, but a way to use it, need to be implemented in top of a HTTP library to support REST.

Even amazing http client libraries are prone to make mistakes.