REST Fluff
As Roy Fielding is trying to explain REST yet again, I am hearing some absurd fluff here:
- REST/HTTP is a core layer in the Web 2.0 goo
- REST/HTTP is not reliable. We still need WS-* for that
- REST is good for machine to human interactions
- REST needs less client software to be written
- REST is simple
- REST has this nice clean URL patterns that are self-explanatory
- CRUD can't deal with business processes.
Holy crap.
Generalized Linking
Jonas Galvez recently asked in the rest-discuss list whether to use Atom style link element, or roll his own.
There were a few more discussions recently on this topic in the context of JSON. One was by Joe Gregorio on RESTful JSON where he talked about using a href property for linking. The second was a proposal JSON Resources: A proposal for a RESTful JSON protocol by Kris Zyp in the restful-json group which took a very complicated approach by suggesting use of properties like $ref for linking.
(The following notes has been lying around for sometime on my desk, and this is an attempt to clear it and get some feedback.)
application/xxx+json
Why did RFC-4267 not leave room for a JSON-family of representations? For XML, RFC 3023 formally defined XML-based media types using the "+xml" naming convention, so that clients (e.g. XMLHttpRequest) can recognize any XMLish media type as long as the media type follows this convention. But not so for JSON?
3001 Miles for 2008
With today's ride, I finished 3001 miles on my bike(s) for 2008.
Here is a run down.
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).