Two questions: 1. Could the REST API use the Accept header rather than looking for the content-type in the URL? i.e. instead of doing: http://twitter.com/statuses/public_timeline.json do this: http://twitter.com/statuses/public_timeline with an Accept: application/json header?
I understand you guys are trying to keep things browser-friendly, but isn't use of the "Accept" header more REST-ful? Technically, public_timeline.json and public_timeline.xml should represent two separate resources, but in reality they are two different representations of the _same_ resource. Right? I would suggest that if a request omits the format (e.g. .xml) from the request URL, that the REST API utilize the "Accept" header to return the proper content- type. But if the format is part of the URL, ignore any "Accept" header. This would keep backward-compatibility with the current behavior. 2. Also, shouldn't any valid URL respond to the OPTIONS method with an "Allow" header? i.e. I would expect OPTIONS /statuses/destroy/12345.json to return "Allow: POST, DELETE" Right? I attempted this (on a status ID that my user owns) and I got a "400 Bad Request" reply. Am I doing something wrong, or just something that isn't supported? Thanks.
