> Vendor mimetypes are bad. They defeat the purpose of REST.
No they don't. Most standard mimetypes are far too broad and completely useless as an actual content type. "application/json" for instance does not tell you anything about the content you're getting, apart from the meta-format in which that content is expressed.
Ok, so you can "parse" it, which is just a way of saying you can transform a bunch of bytes to a nested structure consisting of a few basic types (dicts, lists, strings, floats, etc). Now what? What can you (or actually your program, not you as a human) do with it without some sort of schema, explicit or implicit?
The REST interface is designed to be efficient for large-
grain hypermedia data transfer, optimizing for the common
case of the Web, but resulting in an interface that is
not optimal for other forms of architectural interaction.
When a link is selected, information needs to be moved
from the location where it is stored to the location
where it will be used by, in most cases, a human reader.
Yes, it's obviously the primary use case, since REST is modeled after HTTP. But the keyword is primary - it doesn't mean it can't or shouldn't be used for machine-driven workflows.
> Vendor mimetypes violate the Uniform Interface constraint
Nope.
> and the "no prior knowledge" constraint.
Only if you read no further than "no prior knowledge" and made up what it's supposed to mean on the spot.
Here's what "no prior knowledge" is:
> A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). (http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...)
Vendor content types are the media types he's talking about. And according to fielding pretty much all of a REST service specification is spent defining media types:
> 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).
No they don't. Most standard mimetypes are far too broad and completely useless as an actual content type. "application/json" for instance does not tell you anything about the content you're getting, apart from the meta-format in which that content is expressed.
Useless.