link collection on item

[malevy]

While links in the links array have their accept header set to collection+json. Howerever, the links in the links collection on an item do not. Design decision? Should the links have their accept header set to application/vnd.collection+json, / to prioritize for collection+json but still allow anything to be retrieved?

[mamund]

@malevy

huh. those SHOULD be set to cj by default. currently most other servers (images, HTML pages) ignore the accept, so the cost of defaulting to Cj is low.

this brings up the possible need for an "accept" property on links to allow authors to signal to the client that the link points to something other than a Cj representation.

if you want to clone/fix/PR the items.links thing, that'd be cool.

[malevy]

I like the idea of adding an optional property to link so that the server can indicate the representation(s) that will be returned. UBER using 'accepting'. HTML, HAL and Siren use 'type'.

[mamund]

@malevy:

right -- that's something that's been discussed a couple times. for now, we can add an extension property (did someone already do that in the past?).

feel free to dig around in the extension section and, if it's not already there, you can start up an extension. could be handy.

[malevy]

Sure. Happy to.

[malevy]

So I'm finally getting back to this.

I like the idea of adding an optional property 'type' to the link object for hinting at the expected media type of the referenced resource however there is an existing extension for an optional property called 'model.' and I'm concerned about creating confusion. Especially since the extension is pretty terse. You have to go back to the referenced discussion to see that the intention, I believe, was to communicate information about the referenced resource but not necessarily the representation.

An option would be to further refine the 'model' extension to better clarify intention and the value of the property.

Now, I would prefer to have the property named 'type' over 'model' since 'type' is more common across a variety of existing media types however every media type that I reviewed explicitly indicated that the type property had to contain a media type and I'm not sure that this was the intent of the author of the 'model' extension.

[mamund]

Yeah. I world not attempt to modify the model extension.

Start a new 'type' extension and we can addressee any worries of perceived
overlap if/when or comes up.

Thanks for following up on this.
On May 31, 2015 15:59, "Michael Levy" [email protected] wrote:

So I'm finally getting back to this.

I like the idea of adding an optional property 'type' to the link object
for hinting at the expected media type of the referenced resource however
there is an existing extension for an optional property called 'model.' and
I'm concerned about creating confusion. Especially since the extension is
pretty terse. You have to go back to the referenced discussion to see that
the intention, I believe, was to communicate information about the
referenced resource but not necessarily the representation.

An option would be to further refine the 'model' extension to better
clarify intention and the value of the property.

Now, I would prefer to have the property named 'type' over 'model' since
'type' is more common across a variety of existing media types however
every media type that I reviewed explicitly indicated that the type
property had to contain a media type and I'm not sure that this was the
intent of the author of the 'model' extension.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[malevy]

While reading through all of the extensions again, I noticed that https://github.com/collection-json/extensions/blob/master/templates.md does add a type property to the link object. However, there is one that that might need clarifying if you decide to merge this into the Cj spec. Item 5.1 states that any link decorated with the collection link relation "refers to a collection document" so a conflict could be created if the type property referenced another media type.

[mamund]

1. a collection document is not a Cj representation. that defines the link relation value, not anything about the representation or protocol response formats. there is no conflict

2. the templates extension is fine, not sure how often it is used. an extension to cover just the "type" (as you talk about it) is still needed.

[malevy]

1. a collection document is not a Cj representation. that defines the link relation value, not anything about the representation or protocol response formats. there is no conflict

I believe my confusion was caused due to the definition of the collection link relation containing a link back to the definition of the collection object in section 2.1.