RE: ATOM representation of search result facets
"Rushforth, Peter" <[email protected]>
| Newsgroups | gmane.comp.web.services.rest |
|---|---|
| Message-ID | <1CD55F04538DEA4F85F3ADF7745464AF1AE4DEA2@S-BSC-MBX1.nrn.nrcan.gc.ca> |
Hi Erik, > yes, for media types where the profile information should become visible > on the media type level (and not just added to the representation using > a generic linking mechanism with "profile" relation type links), the > media type needs to be updated. afaict, there is no way how a media type > parameter can be "added" to a media type without essentially > re-registering the media type with the new parameter added. So, to bring this back around to the topic of the OP, are you suggesting using a profile link relation as a RESTful mechanism to signal the extension of the atom media type? If so, my take is that it's not terribly RESTful, since the client can't request the media type with that profile. So, while the link relation (alone) would constitute a form of self-description, it can only be discovered after message reception (unless the media type uses the profile parameter, as you mentioned), and as a result, tightens coupling between clients which rely on that profile and the server which serves it. That doesn't, of course, make it not useful. HTML is extended every which way, and typically no signposts are added to the message to indicate the nature of the extensions. It might be useful in feeds to indicate that they are georss-enabled, and which profile of georss, for example. But IMHO, such extensions are not in the 'architectural style' of the web. Cheers, Peter