Today I was talking to Jose Valim, about hypermedia and how links could be represented in many ways using several different media types.
One of the most common question that appears on rest-discuss every now and then is why atom, and similar, links do not include an attribute that tells the client which verb should be used to access that resource, as html does:
form action="..." method="post"
Actually, html uses the method attribute in a form not to tell how to access a resource: a resource is always retrieved through GET, always created through PUT and POST, always deleted through DELETE.
Html uses that attribute to allow the server notifies which parameters are necessary and which media type to use to retrieve (GET) or create (POST) a resource.
We typically think that the verb is necessary because otherwise clients would not know that they are supposed to do a post, i.e. for publishing a blog entry:
link href="/posts/1/publish" rel="publish" verb="POST"
That’s because the link relation identifies an action, not a resource. Thinking about resources and sticking to the uniform interface when it comes to verbs, we would have:
link href="/posts/1/publish" rel="publication"
It is quite clear that POSTint to such URI would create something, while GETting would retrieve.
In those cases, there is no need for explicit verb declaration on the link (or form).
There *might* be a need when specifying query parameters or writing input elements within a form.
For those who are coming to Baltimore for Railsconf, Fabio Akita will present a session on Bringing more Rest to Rails with Restfulie. If you are up for a talk on REST join the session and meet us there or during the event.
Expecting specific results means coupling your client to a servers behavior, something that we want to minimize.
When there is a required item
And there is a basket
But didnt desire anything
Then desire this item as first item
When there is a required item
And there is a basket
Then desire this item
When it is a basket
And there are still products to buy
Then start again
When there is a payment
Then release payment information
The above code works and can be seen running in the last video from this post. In this Rest modelled process, several types of evolutions can happen on the server, without breaking the client:
1. After adding a product to the basket, if the server renders recommendations instead of your basket, the client still achieve its goal.
2. If some products are not found, the client is still able to pay for it.
3. If the server does not have the products, but links to another system in a affiliated program, we as clients will never notice it, and buy the products.
4. If we want to achieve the same goal in other systems that understand the same media type that we do, simply change the entry point..
Note the benefits from backward compatibility, forward compatibility and we are still capable to achieve our goals without knowing the existence of some changes on the protocol. We can even compare prices without changing one line of code, everything using well known media types as Atom. RDFa support can also be implemented.
This evolution power is not achieved in traditional process modelling, and several times, compatibility is left aside. This is something that REST and hypermedia brought us.
Now let’s imagine the traditional modelling:
In a typical web services + business processing scenario, how would a server notify me to access another system without changing one line of code in my client? It would break compatibility.
If the server now supports a limited quantity of items in your basket, your client will also break, while the adaptable REST client adapts itself and buys what it is capable of.
If our produt or company uses those traditional paths and every change on the service implies in heavy change costs for clients, thats a hint that your project is too much coupled, and a REST client as mentioned might help.
Tradicional web services decouple a little bit more than traditional RPC, but still provide this amount of coupling that cost our companies more than they were expecting to pay.
The entire video cast on the 3rd part from Rest from scratch is here:
This code achieves its results using Restfulie 0.8.0, with many thanks to everyone who contributed maturing this release: Caue Guerra, Luis Cipriani, Éverton Ribeiro, George Guimarães, Paulo Ahagon, Fabio Akita, Fernando Meyer and others.
Is your client api code already adapting itself to changes?
(update: changed some of the “Then” clauses from the dsl for easier spotting of document messages instead of commands)
Rest is not only about http and the web, but an architectural style derived from the web and others.
In this 20 minutes video, we will see how the web has been capable of scaling, providing different services and being a more effective system than other human distributed systems alike (i.e. water distribution and electricity).
We move on to describing the basic characteristics of a rest architecture and how it leverages your system.
This is the first video on the Rest from Scratch – Theory. You can watch the other Rest From Scratch – Practice videos online here.
This 20 minutes video shows how to move from a basic REST api to one which makes use of linked resources and adds semantic values to those links.
Did your REST api do that already? Great.
Otherwise, it’s time to move ahead and decouple a little bit further your clients from your server.
“It is something that we believe is worth exploring with the goal of understanding how it will affect the technology impacted dimensions of your enterprise”.
“It is an empirical proof that the web and hypermedia can be used to orchestrate complex business activities”
There are a few videos available at vimeo for those interested in learning how to use. Jim Webber and myself are giving a talk on REST May 13th in Sao Paulo and Fabio Akita is presenting Rest using restfulie at Railsconf 2010 later next month.
Congrats to the entire commit team (Guilherme Silveira, Caue Guerra and George Guimaraes) and all contributors, specially everyone at Abril Digital who has been contributing a lot of atom related code.
On this 10 minutes video you will learn how it is possible to make several representations of one resource available on the server side (xml, json, atom and so on) and one line of code access and parse it on the client side.
This video shows how to access those basic REST api’s as Twitters, CouchDB which are based on http verbs and multiple URIs. The following videos shall demonstrate how to access more advanced REST API’s.
If you have any questions, join us at our mailing list.