3 ms·

I'm not following anything you've said about "content types". The well-defined, well-known content types in typical applications are images and other "attachmen

I'm not following anything you've said about "content types". The well-defined, well-known content types in typical applications are images and other "attachment" type resources, as well as the occasional RSS feed or something like that. In domain-specific APIs (ie. nearly all the ones that matter), every single resource type has a unique schema. Ignoring versioning, I can request resources with a specific URL pattern and parse them with specific logic. That's all there is to it. It's not complicated. The Content-Type is entirely irrelevant, unless I decide to use it for versioning or waste my time supporting both XML and JSON. > > Stop the pontificating and get back to work. > Oh irony, you're so delicious. My point was directed at the whole "What is RESTful?" debate, including all the versioning, content types, URLs, headers, verbs, etc. Discussions of approaches and problems is not pontification. Discussion of "Which approach is more RESTful?" is pontification.

masklinn 15y ago
> I'm not following anything you've said about "content types". Which amply demonstrates your complete lack of understanding of the subject "pontificate" about. edit: you can downvote me all you want, does not change that fact. Here's what Fieldings has to say on the subject: > A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). (I used "content types" for his "media types", that's about it).
PaulHoule 15y ago
What bugs me about adding contents, strange result codes, and all of these things that "are in the spec even if they're only implemented sporadically" is that it's programming as if interoperability didn't matter. It's almost as bad as the SOAP implementation in ASP.NET.

masklinn 15y ago

> I'm not following anything you've said about "content types". Which amply demonstrates your complete lack of understanding of the subject "pontificate" about. edit: you can downvote me all you want, does not change that fact. Here's what Fieldings has to say on the subject: > A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). (I used "content types" for his "media types", that's about it).

PaulHoule 15y ago

What bugs me about adding contents, strange result codes, and all of these things that "are in the spec even if they're only implemented sporadically" is that it's programming as if interoperability didn't matter. It's almost as bad as the SOAP implementation in ASP.NET.