> 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).
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).