3 ms·
"Further, the output format ought to be determined hubristically from the HTTP Accept header; that lets clients select output formats without resorting to ugly
by snorkel 18y ago
"Further, the output format ought to be determined hubristically from the HTTP Accept header; that lets clients select output formats without resorting to ugly ?format=xml crap."
I have to disagree. First of all, do not assume anything based on mime types the browser (or whatever user agent) asked for. It's very hacky to expect consumers to mess with their user agent's Accepts header to get the response format they want. Specifying the desired format such as ?format=xml is simple, clear, specific, and reliable. I prefer default format be XML and other formats available by passing a format parameter.
The REST of article has some good suggestions. I made a pun there. Did you catch it? "REST of the article". Because it's about REST? That's comedy gold.
- seldo 18y agoThis sentence also stood out to me, but mainly because he used "hubristically" when he meant "heuristically". Unless he really thinks that determining what format to send the response in from the HTTP header is an overwhelmingly arrogant move...
- mustpax 18y agoThe main reason people don't want to put the output format into the URL is that URLs are supposed to represent canonical consumer-independent foreign keys in REST. If you want to put the output format into the URL, I like the .json .xml extensions better. Not that there's anything wrong with the request parameter approach, but the file extension approach also plays nice with user OSes. Also, I'd ideally use both approaches. So the consumer can pick between using /resouce/1 with an Accept header, or just using /resource/1.xml /resource/1.json directly. The nice thing about the Accept header is that file extensions can have some ambiguity whereas the MIME types are pretty standard and come with RFCs backing them up.