Re: [Netconf] Representing URLs

[Wojciech Dec <[e-mail]>]

Following up some of my earlier questions... Inline...

On 29 November 2013 16:59, Andy Bierman <[e-mail]> wrote:
>
>
>
> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec <[e-mail]> 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
>> }
>>
>> 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:
>>
>> 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"
>> }
>
>
>
> I do not understand the concern.
> One leaf is //restconf/config/someUri and the other is
> /restconf/config/anotherUri.
> What is the manipulation magic?  Constructing /path/to/data/node based on
> YANG?
> That is the point of RESTCONF.  There are already plenty of solutions for
> using
> REST APIs for ad-hoc data.  I do not see any reason to develop RESTCONF for
> clients that want to ignore YANG.  There are already have plenty of choices
> for that.
>
>
>>
>>
>> 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?
>
>
> Can you describe the solution you have in mind?
>
>>
>>
>> 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"]
>>     }
>> }
>>
>
> The API already has /restconf/operations/<YANG-rpc-name>.
>
> YANG is not object-oriented, so /restconf/config/routing/<RPC-name>
> is not how the RPC is defined.  You are describing a proprietary
> extension.
>
>> 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?
>>
>
>
> The URI is not an XPath expression. There are no predicates allowed,
> I don't think current() is allowed outside a predicate.

Ok, so what is the way in Yang to have a predicate (e.g. current())
based expression that ends up being represented as a URI in Restconf?
Use of the current() predicate in the instance-identifier appears not
to be supported (at least by pyang).

Thanks,
Wojciech.

>
>>
>> Thanks,
>> Wojciech.
>>
>
> Andy
>