Re: [Netconf] Representing URLs

[Juergen Schoenwaelder <[e-mail]>]

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.
 
> 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.

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/>