Re:REST isn't what you think it is, and that's OK
by DougWebb on Thursday April 29, 2010 @11:51AM
(#1304846)
Also, a URL for the root of your service should be sufficient to find every resource that the service provides access to, and every method that can be used with those resources. The example is a website; from the home page of a website you can reach every other page of the website by navigating through hyperlinks and form submissions.
Another example drawn from the article: if the blog posting service provides each post under a uri like /posts/{post-id}, the client of the service shouldn't have to know the uri structure. Instead, /posts/ should be a resource, and it should contain hyperlinks to all of the /posts/{post-id} uris that are available. There would probably be some metadata about each one as well, such as a title, to enable clients to figure out which one they want to follow.
The first sentence of your quote say that all prior knowledge should be about media formats (like the html specification, microformats, the PNG image format…).
From there, the medium itself should provide enough clue for the client to go on. For instance, anchor links in html says you can GET a resource at the specified URI. Other media formats could provide other clues.
To sum up, the only things you can specify a-priori are media formats. URIs and protocols should be interchangeable, so you can update and deprecate them. I think the main goal of REST is to concentrate coupling on media formats alone. Hopefully, most media formats are (or will be) standardized, effectively reducing coupling. Basically, REST architectures are for the long term.