In this case, sending some representation as just JSON (application/json) clearly breaks the Uniform Interface constraint, particularly the HATEOAS principle: a client is supposed to only know the base URL and the mimetypes. If he gets 'application/json' as a reply, how is he supposed to know what to do with it? It may be a user profile, or a blog post, or a description of an UI, etc, there's no way to tell.

Yes, because the clients have to know that for your service specifically, when they get an "application/json" response, they have to look for that property. That kind of information, unless defined in the standard - in this case, the HTTP or JSON specs - is considered out-of-band information, which breaks the Uniform Interface constraint.

To quote Roy Fielding:

     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

Of course, I believe you could easily bypass that by making up a single new mediatype (e.g. application/vnd.my-service+json) and then use that for any JSON response with that type property. Since the clients know knew how to distinguish your JSON responses from everybody else's just by their mediatype, it wouldn't break REST.

But on the other hand, if you're using a different mediatype, why not go all the way and just use different mediatypes instead of a type property?

EDIT: As an addendum, the point of this constraint is to reduce coupling and enable the REST clients to be as generic as possible, enabling code reuse and modularity.

Using your example, I could write an application where the core was composed of an HTTP client, with support for plugins that would register themselves as "mediatype handlers". This way, the core could fetch the representation for an URL and then dispatch it to the right handler using the mediatype.

If I wanted to process your API, now my core client would have to include a JSON parser and an hack in the middle of the dispatching code to process all 'application/json' responses looking for your type property. It'd be ugly, bloated (multiple JSON parsing instances), harder to maintain, etc.

Of course, right now we don't see this as a problem because everyone writes a client against a specific API anyway, but frankly I think that's a bug, not a feature. If the REST APIs out there were truly RESTful, I think we'd see much more interesting clients that could combine dozens of different APIs, which is now impossible due to the sheer manpower required.

Yeah, it'd be awesome if we could all consume APIs with standard interfaces using Content-Types, however I don't think the current solution is realistic or even good for innovation.

Having to define a Content-Type like "application/vnd.my-service+json" and submit it to a standards body and then approved like described in Amundsen's book is hardly practical or desirable.

The standards process today sucks (see the CSS prefix debate for a prime example) (and, I'm not claiming I can do better, just making an observation)

The way I see it, defining types in a JSON format to help with type-marshalling until that format is successful and thus merits standardization is far more effective at promoting innovation than starting with submission to a standards body so that everyone can comment on (i.e. bikeshed) about a format until it gains acceptance.

There is a an interesting dynamic between pragmatism and academics, but I think it would be best for the academics to actively move the pragmatics towards the ideal instead of staying in an ivory tower and letting the pragmatics take twice as long to discover the "pure" solution.

RESTish solutions should become RESTful through standardization into a proper media type. Maybe the RESTful solution is derived from the coordinated cooperation of several participants with RESTish solutions.

Acknowledging and adopting the human element is likely to move things forward far faster than a steadfast insistence on being pure. We could probably have far more useful media types if we assumed that formats eventually become a media type once they become popular enough. Pave the cowpaths.

Anyways, not arguing with your comment. I agree with most of what you said and ot was enlightening. Just saying, that it'd be great if people actively considered the fact that human beings are involved when discussing ideas. Ideas are great, but they mean nothing if you can't humans to go along with them.

Yeah, but that's why I chose media types in the Vendor Tree (application/vnd.) as examples - as far as I can tell, they do not need to be registered with IANA. And I'm sure they don't have to be reviewed, even if you do register them:

    public exposure and review of media types to be 
    registered in the vendor tree is not required

The way I see it, defining types in a JSON format to help with type-marshalling until that format is successful and thus merits standardization is far more effective at promoting innovation than starting with submission to a standards body so that everyone can comment on (i.e. bikeshed) about a format until it gains acceptance.

Sure, but it doesn't have to be a standard to have its own mimetype. Just put it after your company's name (application/vnd.COMPANY.FORMAT) and forget about registration, imho.

Sure, a standard would be better, but this is still way better than having to use an hack like that.

In defense of the grandparent post though, REST never specified a data or for that mater media format. It could be JSON or XML or even a binary format like a bitmap but a lot of people that talk about RESTfull services talk about JSON which is not a requirement of the original REST concept. REST was more about how a resource was accessed, not what that resource is.

Not really. The web is a RESTful system, but there's nothing specific to HTTP in REST. It's just an architectural style, it doesn't specify nothing in concrete.