feedHere is a nice post at dev.opera.com. But I can't completely agree with the statement that
That's one side of the story. The other side is repeating the same ideas with better and more flexible technology.
This is in response to Mike Amundsen's post on hypermedia. I started commenting on his blog, but then realized I have more to say than what I could fit in the comment form.
Mike's questions are, for REST-ful applications that use JSON for representing resources, (a) "where is the hypermedia (links and forms)" and (b) "what standardized clients understand how to render these elements propertly?"
Content negotiation in HTTP 1.1 is not broken. It is insufficient and incomplete, but the way it was defined in RFC 2616 works for what it is intended for. What is broken includes HTML, user agents, and buggy servers. Web services developers should not use the argument that content negotiation is broken and avoid supporting it altogether or support it poorly. I don't know if this was the rationale used by Twitter, but Twitter APIs do not understand content negotiation.
Mike Amundsen is wondering how to express hypermedia in JSON. He rightly identifies that there needs to be a new media type, e.g. application/hypermedia+json. Putting together such a new media type is not hard, but in my view, the real issue is defining a JSON format that can express data/media as well as hypermedia. One possibility is to take the "payload" formats defined by Atom and Atom Publishing Protocol, and translate that into JSON using some simple rules. Here is one, based on example from RFC 5023.
With the weather being a bit cooler than it was last week, I decided to ride up Mt Hamilton today, from east to west, starting from Livermore. From downtown Livermore, it is a about 49 miles to the summit (at about 4300 ft), which makes it tougher to climb from this side. What is more challenging is that, the final climb of about 2000ft happens in just about six miles (i.e. from mile 43). These six miles are grueling, with an average 9-10% grade, and I could not average more than 4 miles/hour during this segment. My GPS puts the cumulative ascent at 6500ft, although my legs are trying to make me believe that it is much more than that.
Through Stefan Tilkov's blog, I came across ServiceReg whose goal is to let us "execute RESTful web service calls against Rails applications (and other REST compliant framworks) with a simple URL". The "simple URL" is one that can be submitted via a GET.
When it comes to URI design, I am in the camp that argues that URIs ought to be opaque as far as the representations are concerned. In my view, URIs and representations are two independent axes of web service design, and must be designed to be evolved independently of each other, and that URIs should not be used to infer the structure of representations. Does this mean that URIs should be completely opaque and cryptic, like the following ...
There is a push in some corners to treat URIs as a means to represent hierarchies of objects. In this view, each path segment in the URI either represents either an object or a relationship to another object. For example, if a person object has a firstName, lastName and an address, under this model, the web service would provide the following URIs:
Last night, I relocated this blog from my long-time hosting company ICDSoft to my slice at Slicehost. Due to DNS changes, and a fresh environment, this blog (in particular comments) was broken for about 12 hours. Things should be okay now.
What is the best way to start building RESTful applications? One of the common advice heard is, "nouns are your resources". You walk through your application, identify all the nouns, model them as resources, and try to rely on HTTP verbs to operate on those resources. Use POST to create a resource, PUT to replace (or even create, when the client can name the resource), DELETE to delete the resource, and GET to get the resource. However, the notion that nouns can be used to identify resources is simplistic.