spec: allow to select rel and media types

[dunglas]

• Allow to select specific media types as requested in Support setting accepted media-type on Preload & Fields pushes #46 but also specific relation types and languages
• Allow to select all links by passing an empty string (best used with the new rel parameter
• Switch to the format defined in the structured headers I-D
• Add an "Implementation Status" section (RFC6982
• Add an "Acknowledgment" section

@andrerom could you review this change? It should address the eZ Publish's use case (closes #46).
@evert as discussed during API Days Interface, this change to the spec should allow to cover the use cases also covered by your Prefer-Push I-D. Would you mind to take a look?

Thanks!

[evert]

This looks great! Definitely meets my use-case and then some. I also like that structured headers is used for this!

[andrerom]

Looks promising!

One comment comes to mind on both hreflang and type, for both you have:

If this parameter is provided, the server SHOULD preload only relations matched by the provided selector

In #46 I was however rather asking for a way to overload the Accept type.

Example for GET /content/objects/{contentId} you can set different Accept and get different representations:

• application/vnd.ez.api.Content+xml
• application/vnd.ez.api.Content+json
• application/vnd.ez.api.ContentInfo+xml
• application/vnd.ez.api.ContentInfo+json

This can furthermore be extended to be able to add more data to the response for instance (custom use cases).

So to enable that I would expect Accept for Preload requests to to be set in the following order:

1. If the Preload/Fields header has a type override for the given selector, use this
2. If the matched link in the document has a type, use this
3. Lastly reuse Accept from the current ("parent") request

[dunglas]

@andrerom unfortunately I think that it's fundamentally incompatible with the other goad of this change which is to add selection capabilities similar to what the Prefer-Push header allows. Maybe could we add another attribute for this use case (overloadtype? overloadaccept?), but I wonder if it's not too specific. Maybe could we do as in the Web Linking RFC and allow custom attributes as an extension. The eZ would be able to pass its own attribute for this use case?

[dunglas]

In 3e54822 I added a clarification regarding content negotiation: servers should try to guess the best possible value for the Accept and Accept-Language request headers.