Atom and XML for represention? You lost me...<p>I think the reason JSON apis caught like wildfire was to get away from the many pitfalls of over-architecture of XML in relation to SOAP, attribute/element dichotomy, namespacing with multiple nodes for the same value and general bulkiness. Parsing xml in javascript, scripting like actionscript and more is being mean to your consumers where JSON becomes objects they can use immediately. Are you making the API for your consumers or Roy Fielding?<p>Granted Roy has helped me win many arguments and I am on board, it just takes time for these things to catch or be able to be used 100% to the spec as with any standard. I see REST more as a pattern much like the GOF patterns that evolved from actual work to become patterns. But strictly adhering to patterns or standards is not always business/market/product capable at the time.<p>I don't see being true to what I deem a biased view of what REST is over making your api dead simple. Simplicity is missing more in software than long term thinking. This is mostly simple but adding in the requirement for representational view to be deemed 'REST certified' is a bit snouty.<p>RESTful on the client was only recently available so all this is evolving (i.e. setting client headers and anything other than POST or GET wasn't even possible until a few years ago consistently in browsers). I think the wrong direction to go is to get too SOAPy about services. Most heavily in use apis on the web still have to bend more RPCish because the market required it at the time, with time things will move more towards REST now that it is possible to perform a DELETE or set a header from more consumers.<p>If real programming standards weren't both academic and market based but solely academic then we'd all be using Java to code up our SOAP generated services which in term didn't work with other platforms like .NET services.<p>KISS prevails always and once again... JSON is a member. And I am down with HATEOAS but what a bad acronym.
I disagree with the notion that api.twitter.com is a bad idea. URLs don't need to be unique ways of locating a resource. An application designed around HATEOAS doesn't even need to include the domain in the URLs it describes, so you could make the same resources available with the same paths on both twitter.com and api.twitter.com without changing the content of the resources.<p>This isn't necessarily the best design in the world, but you also can't ignore the real world requirements of operating a site as large as twitter. I suspect it would be more expensive (in many ways) for twitter to direct all traffic to twitter.com and then route it internally based on the accept header.<p>Versioning on the accept header is, in my mind, the most controversial part of "Hypermedia" API design. Custom mime types add a lot of complexity in the real world, from both the client and server side perspectives. And yet, changing the path in order to access a new resource has many downsides of its own. There's also a question of scale -- adding a bit of new information to existi
as much as it says that in a fielding-style rest system the URLs and verbs are opaque, he spends a lot of time nitpicking over the format of urls.<p>unless the resource in question is exposed as an endpoint, the url and verb are handled by the link or form discovered by the client, and <i>invisible</i> to the client.<p>as for versioning - versioning the mime types is a useful thing, but it does still make sense to use a different url if you are using different links and forms to navigate the service.