Re: [Netconf] Opinion poll on RESTCONF encoding

[Mahesh Jethanandani <[e-mail]>]

What I am reading from the discussion till now is:

Accept request-header needs to be supported and that it is not an option.
The client can choose not to send the header, in which case the server can pick an encoding of its choice and respond with it.
The client can send what it does support, in which case the server either accepts the encoding it supports or returns a 406. The 406 (Not Acceptable) status codes include information about the available representations.
The client can send “*/*". Same behavior as not getting a Accept header.
Server MAY support advertising of encodings using the ./well-known/host-meta file and XRD.

If this a fair summary, we can update the RESTCONF draft with these details.

> On Aug 27, 2015, at 10:31 AM, Kent Watsen <[e-mail]> wrote:
> 
> 
> 
> 
>> It does not matter, we should not change HTTP.
> 
> But we're not, HTTP has a bunch of "SHOULD"s that can and should be
> restricted as it makes sense for REST APIs.   Please feel free to search
> REST API best practices on this.
> 
> 
> 
>> This is what RRC 7231 has to say:
>> 
>>  A request without any Accept header field implies that the user agent
>>  will accept any media type in response.
> 
> Lada brought this up too.   Yes, this could be interpreted as "assume */*
> was passed" or, per section 3.4.2:
> 
>   A server might choose not to send an initial representation, other
>   than the list of alternatives, and thereby indicate that reactive
>   negotiation by the user agent is preferred.  For example, the
>   alternatives listed in responses with the 300 (Multiple Choices) and
>   406 (Not Acceptable) status codes include information about the
>   available representations so that the user or user agent can react by
>   making a selection.
> 
> 
> 
> BTW, I tested `wget` and `curl` also, they both pass "*/*" like the
> mainline browsers...
> 
> Kent
> 
> 
> 
> 
> 
> 

Mahesh Jethanandani
[e-mail]