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.

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.

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