Register media type with IANA

[kevinswiber]

Howdy.

Have you thought about registering application/vnd.hyper+json with IANA? Even if you plan on taking this through a standards process to register application/hyper+json, having this vendor-specific type will help during development.

Here's the application: http://www.iana.org/form/media-types

[cainus]

Thanks Kevin! I'm curious... other than raising the profile of the spec, how do you think it will help?

[kevinswiber]

If I write a client that speaks hyper+json, I need to know that the server
does, too. This is helpful for content negotiation if supporting multiple
formats. The IANA registration means I can't just make up
application/hyperjson+json and expect it to work. It's not necessary, as
in... everything breaks without it... but it's nice to have. Also, it's
free and easy. Just takes a little time to process.

Plus, it would mean I can add it here:
https://github.com/kevinswiber/hypermedia-type#supported-media-types :)

On Sun, Feb 2, 2014 at 12:34 PM, Gregg Caines [email protected]:

Thanks Kevin! I'm curious... other than raising the profile of the spec,
how do you think it will help?

Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-33906206
.

Kevin Swiber
Projects: https://github.com/kevinswiber
Twitter: @kevinswiber

[cainus]

Well I agree with that on a theoretical level, but I do sort of doubt that clients for hyperjson would really be much different from json clients. Because both are such general-purpose formats, and to use either requires a bunch of out-of-band information, I've always felt that specifying the sub-type (hyperjson) in out-of-band information is just as effective. The meaning of the rels has to be specified anyway, so I don't even see this as extra work.

And the downside of servers responding with application/vnd.hyper+json is that pretty much every client library that couples json parsing with http requests (a lot of them!) will be broken/useless.

So I guess I'm wondering on a practical level what you think the advantage would be, or how you'd mitigate the downsides.

(With that said, I think I'll go through with the process anyway, if only to stake claim on the name. Thanks for the nudge!)

[kevinswiber]

Because both are such general-purpose formats, and to use either requires a bunch of out-of-band information, I've always felt that specifying the sub-type (hyperjson) in out-of-band information is just as effective. The meaning of the rels has to be specified anyway, so I don't even see this as extra work.

Okie-doke. :)

And the downside of servers responding with application/vnd.hyper+json is that pretty much every client library that couples json parsing with http requests (a lot of them!) will be broken/useless.

Out of curiosity, do you know of a framework, in particular, that will break? Jersey, for instance, recognizes the +json suffix and will translate the type into JSON.

So I guess I'm wondering on a practical level what you think the advantage would be, or how you'd mitigate the downsides.

Well, I'm not convinced all the downsides are real concerns.

Also, at times, I've made it so that the API returns application/json by default, but if an Accept header prefers application/vnd.siren+json (for instance), I'll return the application/vnd.siren+json content type.

In any case, just thought I'd make the suggestion. Feel free to close.

[cainus]

I haven't tested any of these, but I'm talking about libs like: https://github.com/mikeal/request , probably jquery as well, and also tools like jsonview ( https://chrome.google.com/webstore/detail/jsonview/chklaanhfefbnpoihckbnefhakgolnmc?hl=en ).

I like your idea about defaulting to application/json though and returning application/vnd.hyper+json based on Accept header. That's a nice transition method.

So yeah. I'm going to do it. :) Thanks :)