Re: [Netconf] Representing URLs

[Wojciech Dec <[e-mail]>]

On 3 December 2013 20:40, Ladislav Lhotka <[e-mail]> wrote:
>
> 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.

So leafrefs are great, but if I interpret them correctly in rfc6020
(http://tools.ietf.org/html/rfc6020#page-124), their usage in the
context of Restconf would result not in a URI for the leaf being
passed to a client (say after a GET), but rather the value of that
leaf. It also does not appear to be suited to referencing a data node
(eg container).

Regards,
Wojciech.
>
> 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
>
>
>
>