Re: [Netconf] Representing URLs

[Andy Bierman <[e-mail]>]

On Fri, Dec 6, 2013 at 1:27 PM, Martin Bjorklund <[e-mail]> wrote:

> Andy Bierman <[e-mail]> wrote:
> > Hi,
> >
> > You have raised an important RESTCONF issue, which is the
> > client processing of server resource URIs.  I think the
> > client should be able to use the Location header URI for
> > all CRUD access to the data resource.
> >
> > That's why the /restconf/config and /restconf/operational split
> > is broken. In order to retrieve operational data, the client
> > has to parse the URI and change it -- not too REST-ful ;-)
>
> RESTCONF's uri scheme is already not too REST-ful.  The uri's are
> deterministic and known by both client and server.  The Location
> header only works when the client has created a resource, but it
> cannot be used to discover uris on the server.
>
> The split into config and operational does not change this.
>
>
OK, but the split was supposed to get rid of the config query param
but it didn't.  Now config=true|false applies only to the /restconf/data
resource, not the /restconf/config resource.

I think we are better off without the /restconf/config resource and
just have /restconf/data + content=enum (config|operational|both)
[default:config]
The ETag and Last-Modified values are only returned when content=config.
They are only maintained for config=true data nodes.




>
> /martin
>


Andy