Location vs. Content-Location
Here is a quick note on the purposes of and differences between Location and Content-Location response headers. The question came up several times, and more recently in Bill Burke's post on Atom too SOAPy for me.
Payload Formats
Bill Burke says:
For me, the value of Atom haven’t really clicked with me yet. Its just too SOAPy for me. If you look at ATOM, the ATOM protocol, and how people are talking about using it, they’re really using it as an envelope. One of the things that attracted me to REST was that I could focus on the problem at hand and ignore bulky middleware protocols (like SOAP) and lean on HTTP as a rich application protocol.
REST Patterns
Document your patterns, today!
Coincidentally, at Yahoo we have been working on developing patterns for RESTful web services. If all goes as planned, we may be able to publish these externally (don' hold me for this - this is not an official announcement). But the focus right now is covering the ground as broadly as possible.
Clean URIs and SEO
I just came across two recent discussions about clean URIs - one from the Google Webmaster Central blog titled Dynamic URIs vs. static URLs; and the other from a Nathan Buggia of Miscoroft titled Advaned SEO for Web Developers. Both are in the context of SEO.
Double POST and POE
POST is non-idempotent by design, and clients are not supposed to resubmit their POST requests. But if network or software fails before the client could read the POST response, it would not know whether the server processed the request or not. It it resubmits the request, it could cause duplicate resources when POST is used for resource creation, or other negative side effects when POST is used for other purposes. This is a well-known problem with POST for a long time. For the user-facing web, we can play some tricks such as using hidden form parameters or disabling form submit buttons. But how to deal with this problem for non-HTML RESTful apps?
Resources and Classes
What is the closest thing to a class or type in RESTful systems?
I think it is the media type. URIs name resources, but don't describe types. Media types, on the other hand, describe representations. A representation is the closest thing to an object. Media types describe types of representations.
That's why, the more specific the media types are, the better. Using a generic type like application/xml is like using a generic class like java.lang.Object (or its equivalent in other languages).
Netflix REST API
Here is a well-designed REST API from Netflix that starts with this in the overview:
Designed to be resource centric, the API keeps the data references for resources in the URL path, to the right of the host name, and uses links to tie together related resources. Method information goes into the standard HTTP verbs.
This is first API that I came across that has linking stated so prominently. Kudos to the Netflix team.
On REST WSDL 2.0 Demo
In response to some comments by me, and perhaps several others, Keith Chapman has recently put together a demo to illustrate that WSDL 2.0 can be used to write RESTful apps. Kudos to Keith for the effort.
However, I can't help but note that this demo illustrates the point I was trying to make then and in my recent posts on linking (On Linking - Part 1, and On Linking - Part 2). If you ignore linking and hypermedia, and are happy to pre-publish all possible URIs in a WSDL (or WADL some such thing), it is not impossible to use SOAP based frameworks for developing POXy REST apps. Now I just need to imagine how many thousands of URIs would I be pre-publishing for this blog if I were to follow this and other POXy demos.
On Linking - Part 2
This is part 2 of my post on linking. See Part 1 for the previous post.
As demonstrated by AtomPub, linking can and does work. But, there are a couple of design hurdles to cross for a more widespread use of linking.
On Linking - Part 1
Linking is the most under-utilized aspects in modern RESTful apps. Without linking, what we are building today are essentially POXy REST apps. I categorize a well-designed POXy REST app as one that is built as follows: