rest - HATEOAS Content-Type : Custom mime-type -

i've been trying implement restful architecture, i've gotten thoroughly confused whether custom media-types or bad.

currently application conveys "links", using http link: header. great, use title attribute, allowing server describe on earth 'action' is, when presented user.

where i've gotten confused whether should specify custom mime-type or not. instance have concept of user. may associated current resource. i'm going make example , have item on auction. may have user "watching" it. include link

<http://someuserrelation> rel="http://myapp/watching";title="joe blogg", methods="get"

in header. if had ability remove user watching get.

<http://someuserrelation> rel="http://myapp/watching";title="joe blogg", methods="get,delete"

i'm pretty happy this, if client has correct role can remove relationship. i'm defining relationship. neat thing call on 'relation' resource, redirect client user resource.

what's confusing me whether or not use custom mime-type. there's arguments both ways on internet, , in head in regards this.

i've done sample in call head on unknown url, , server returns content-type: application/vnd.myapp.user. client decides whether can understand mime-type (it maintains mappings of resources understands views), , either follow it, or explain it's unable figure out @ end of link.

is bad?. have maintain special mime-types. what's particularly odd i'm more happy use standard application/user format, can't find 1 specified anywhere.

i'm beginning think should attempting guess @ rendering in http response, point maybe restful api should rendering html instead of attempting json/xml.

i've tried searching (even roy fieldings blog), can't find describes how client should deal sort of situation.

edit: argument have including custom type, may not 'user' watching item, application/vnd.myapp.group. getting response client knows body has different, , change view displays groups. coupling of mime-type view bad?.

i'd say, want have specific media-type representations. if can find standard 1 (html, jpeg, atom, etc.) use that, if not, should define 1 (or multiple ones).

the reason is: representations should self-contained. means client gets link somewhere should know it. how display it, how proceed there, etc. example browser knows how display text/html. client should know how display/handle application/vnd.company.user.

also, think you've got content negotiation backwards. don't need call head determine representations server supports. can tell server client supports in get/post/etc requests using "accepts" header. indeed standard way it. server responds 'best' representation can give accepted mime-types. don't need more round-trips.

so, although links providing can contain contextual information, given in 'rel' attribute, if link points 'next page', 'previous page', 'subscribed user' or 'owner user', etc., client can not assume representation under links. knows semantically 'user', can fill 'accepts' header supported representations user (application/vnd.company.user). if representation says text/xml, there nothing client can assume either of content, or semantics of links may receive.

in practice can of course code client assume representations under links/urls, , don't have conform rest time, lot of benefits (described in roy fielding's paper) if do.

another minor point: links not need contain methods available given resource, that's options for. admittedly, implemented.