Re: [Netconf] Representing URLs

[Ladislav Lhotka <[e-mail]>]

On 03 Dec 2013, at 18:47, Wojciech Dec <[e-mail]> wrote:

> On 3 December 2013 16:58, Ladislav Lhotka <[e-mail]> wrote:
>> 
>> On 03 Dec 2013, at 16:39, Wojciech Dec <[e-mail]> wrote:
>> 
>>> 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).
>> 
>> Predicates in instance-identifiers can be used only for matching list keys against constant strings, see sec. 9.13 in RFC 6020.
>> 
>> Can you give an example of an effect you would like to achieve?
> 
> Starting with a basic example: In a data-model for interfaces/x/y, I
> would like the ability to actually have a reference to another node in
> the model, that in Restconf ends up shwoing up as a URI. Eg. getting
> at the URI /interfaces/x/y, would return data which would also give me
> a URI for "/line-cards/foo/serial-number".
> 
> A hypothetical Yang data-model for this could be:
> list interfaces {
>    key some;
>    leaf some {
>       type string;
>    }
>    list details;
>      key id;
>      leaf id {
>        type string;
>      }
>     Other stuff
>     leaf someUri {
>         type instance-identifier;
>     // Xpath expression to the line-cards/foo
>     }
>   }
> }

Assuming that line-cards also appear somewhere in the data tree, a leafref would be a more natural way of representing the reference - and then you can use current(), too.

I have myself never used an instance-identifier in any data model yet, presumably they are mainly useful in notifications.

Lada
 
> 
> In the instance-identifier, having a leafref like current()
> restriction/replacement would appear to be useful in cases where wants
> to construct such a URI by using as a piece the context of the current
> node.
> 
> 
> Open to your suggestions.
> 
> Thanks,
> Wojciech.
> 
>> 
>> Lada
>> 
>>> 
>>> Thanks,
>>> Wojciech.
>>> 
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> Wojciech.
>>>>> 
>>>> 
>>>> Andy
>>>> 
>>> _______________________________________________
>>> Netconf mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netconf
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C