Re: [Netconf] Representing URLs

[Wojciech Dec <[e-mail]>]

On 29 November 2013 16:02, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Fri, Nov 29, 2013 at 03:01:36PM +0100, Wojciech Dec wrote:
> > Hello Restconf authors,
> >
> > I would like to ask a few questions and seek your thoughts on the topic
> of
> > URL representation in the API
> > Currently Yang allows two forms by which one could seek to have URI data
> be
> > represented in a model:
> >
> > A.
> > leaf someUri {
> >     type instance-identifier;
> > //some Xpath expression to a node
> > }
>
> An instance-identifier is not a URI.
>

Granted, but
http://tools.ietf.org/html/draft-bierman-netconf-restconf-02#page-57 speaks
about how it ends up being a URI, possibly a URL, in the context of
Now, what is missing, or  at least not clear to me, is how this data-type
ends up being transformed into something more usable in a Rest context (IMO
a canonical URL). And then the other bits and pieces 1-3 below.


> > B.
> > leaf anotherUri {
> >     type yang:uri;
> >     default "/my_uri/is/here"
> > }
> >
> > Now, while the above is perhaps sufficient for some well known absolute
> > paths, there appear to be a couple of problems in terms of  a Restful
> API:
>
> A path is not a URI either. It seems you are talking about some form of
> paths but not URIs.
>

With Restconf, the Yang data-nodes are effectively being mapped to Restful
resources, accessible via URLs.
Putting URLs direlcty into the data model does not look right, so I'm
looking at ways in which these URLs could be generated by Restconf.

Cheers,
Wojciech.


>
> That said, I may agree that having a hard-wired logic how URIs to
> RESTful resources are constructed is somewhat unRESTful. It seems that
> discovery of URIs for such resources is what people prefer. But of
> course, the flexibility this allows comes at a price - you sometimes
> neeed to do additional lookups. The good news is that HTTP is
> providing decent caching support.
>




>
> /js
>
> > 1. Based on the current Restconf spec, both A and B above when faced
> with a
> > GET would appear to expose a URI, which the client would have to do some
> > manipulation magic on it before use. What a Restful API would be more
> > likely to expose instead is a URL, eg in JSON:
> > {
> >     "url" : "http://example.com/files/v1/documents/abc123"
> > }
> >
> > It would appear to be sensible to add to the Restconf spec a URL
> generation
> > capability. I.e. have Restconf transform URIs into canonical URLs.
> Thoughts?
> >
> > 2. A URL to a data-model specific method
> > Suppose that the model was also defining an RPC, along the lines of the
> > "play" RPC in the Jukebox example. Now, as part of the song resource
> access
> > API, it would be natural to have such a method returned in a URL. That
> > would also be much more Resful than the currently implicit "/operations"
> > resource listing.
> > While it may be possible to use B. above to some degree, that is still
> > below par as it is not validated in the model.
> > Use of A. appears, to me at least, not possible since the RPC is not a
> node.
> > Thus, is there a way to have Restconf return an RPC/services list for the
> > data? Eg:
> >
> > {
> >     "songs":
> >     [
> >         a list of songs, 1, 2, etc
> >     ],
> >     "rpc":
> >     {
> >         "play": [ "http://example.com/operations/example-jukebox:play"]
> >     }
> > }
> >
> > 3. Use of current() function as predicate in URIs/URLs
> >
> > It would be useful to be able to use the "current()" function to
> construct
> > URIs/URLs returned in Restconf. The spec does not make it clear on
> whether
> > this would actually work in A or B above. Would it, or is there some
> other
> > way?
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>