Thursday, 16 April 2009

Understanding REST

I’ve been reading to answer the questions in my last post, and the picture is a bit clearer.

I think I now understand what we gain by HATEOAS. Instead of the client guessing where to go throughout an application by constructing URIs, it is guided by the server by providing it with hyperlinks (representations) to follow.

What do we gain from that?
More decoupling, thus more reusability, less likeliness of clients to break.

So that is HATEOAS, but what is statelessness.

The application state is on the client, because the client is keeping track of where it is and what it is doing. The server doesn’t need to do that.
In the book RESTful Web Services the authors differentiate between two types of states application state and resource state. Resource state is on the server and application state is on the client.

So in my case of ordering a pizza, should the order be a resource created by the client on the server, therefore a resource state? Or should it be part of the application state and should be stored on the client side?

There are some things to note here:
-In my pizza delivery there would be another client interested in the resource, the carrier service so having the order on the client that would not be very efficient.

-Scalability issues, having the order on the server won’t be as scalable and reliable as having the order on the client. In the RESTful Web Services book the authors wrote, “When your application is stateless you don’t need to coordinate activities between servers, sharing memory or creating “server affinity” to make sure the same server handles every request in a session you can throw web servers at the problem until the bottleneck becomes access to your resource state. Then you have to get into database replication, mirroring or whatever strategy is most appropriate for the way you have chosen to store your resource state”. My problem with that is that mostly what clients would deal with in Web Services are resource states, or are we thinking about resources in a wrong way.

-I believe the problem boils down to who creates resources in the book the clients could create resources, however in the dissertation, to the best I know Fielding didn’t mention that clients could create resources on the server. He referred to creators of resources as authors which I assume have control over the server. So if the client can create resources on the server, then the server is storing part of the application state which according to what I understood from Fielding's dissertation isn't RESTful.

-Also in the dissertation there is an example of a shopping cart “A state mechanism that involves preferences can be more efficiently implemented using judicious use of context-setting URI rather than cookies, where judicious means one URI per state rather than an unbounded number of URI due to the embedding of a user-id. Likewise, the use of cookies to identify a user-specific “shopping basket” within a server-side database could be more efficiently implemented by defining the semantics of shopping items within the hypermedia data formats, allowing the user agent to select and store those items within their own client-side shopping basket, complete with a URI to be used for check-out when the client is ready to purchase.” I think that if this was implemented using the RESTful Web Services book way then a client would create a shopping cart at the server then post items to it which won’t be as scalable as Fielding’s client side shopping basket.

Difference between REST and ROA
By REST I am referring to Fielding’s dissertation, and by ROA I am referring to the RESTful Web Services book.
-In REST there is no CRUD. It states that a uniform interface should exist but not what it is.
-In REST there is more emphasis on HATEOAS.
-In ROA there is more emphasis on uniform interface: GET, PUT, POST and DELETE.
-ROA uses the HTTP protocol and its methods to implement RESTful Web Services. In REST a set of constraints are set but not tied to any protocol or system.
-Web Services are not mentioned in REST, but they are the heart of ROA.

Limitations of REST
As stated by Fielding in his dissertation:
“The REST interface is designed to be efficient for large grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.”
“not optimal for other forms of architectural interaction” so why the fuss about RESTful Web Services? They are not transferring large grain hypermedia? Is it that the WS community saw in REST what Fielding didn’t see?

Another limitation which was pointed out by “Triple Space Computing” researchers when considering REST as an infrastructure is that there isn’t a way for the server to send notifications to clients asynchronously.

Wednesday, 8 April 2009



This maybe total nonsense I am 90% sure it is but I’m putting it here anyway coz:
1-I believe my blog hasn’t been indexed by Google -I haven’t linked it to any website yet- so it doesn’t officially exist on the Web :) The only person that might be reading this besides me is my supervisor. Sorry Dr Dave :).
2-If one day I feel like releasing this to the world then hopefully I would have came up with something to make up for this nonsense
3-I might delete this post someday :)
4-Putting up here makes me more keen on finding the solution.

Interested in REST I was thinking that it can’t just be about providing hyperlinks and accessing them in a uniform way. There must be more to it, especially because it is a PhD dissertation. I’ve read some chapters of Fielding’s dissertation or to be accurate skimmed through them.
The thing that I can’t quite get was statelessness and “Hypermedia as the engine of application state” which are related I think.
I understood what they meant, but not why they were important.

Q1-Do we make “fat clients” that store the state of the application?
Q2-Or do we make the messages fat by storing everything about the state in them?
Q3-Or do we have a hyperlink for every possible transition? But where are these hyperlinks stored and processed? At the server? Ok isn’t that storing the application state at the server? Does that defy REST?

Possible Answers:
A1-If we made clients fat; that removes the storage and processing burden from the server to the client. But is that desirable? Isn’t the fact that servers having more power, why clients sometimes choose to use servers? In case of the Web that is OK because there isn’t much processing involved? However if I have a server offering heavy analysis of client provided data that needs to interact with the client during the analysis can that be decoupled? Or are there applications in which REST is favoured and others where it isn’t?
The question holds also for things that we don’t trust the client to do such as authenticating a credit card.
A2-Making messages fat. That would burden the server too. And the communication media? And at the end hinder the server from responding to more messages.
A3-It offers visibility as stated in the dissertation but what else?

The greatest application for REST after the web is Web Services (currently). Yet although picked up by the WS community. I don’t see any adoption from Fielding himself towards RESTful Web Services? Why not? Isn’t this another testbed for his ideas. Or is he fed up with people and companies using it as a buzzword.

Or is it to offer RESTful Web Services (with the benefits REST claims) you need a REST architecture not just an interface. Which may currently be unavailable? But the Web is RESTful, Web Services are built on top of it or should be.

To find answers my queries I need to :
1-Go back and read Fielding’s dissertation.
2-Go back and read the RESTful Web Services book by Leonard Richardson and Sam Ruby.
3- Read this post again and again