Re: [Netconf] Representing URLs

[Ladislav Lhotka <[e-mail]>]

On 04 Dec 2013, at 11:10, Wojciech Dec <[e-mail]> wrote:

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

In my view, the leafref value (such as a list key) can be passed in in a GET response and then it should be easy for the client-side application to construct the corresponding URI, XPath or whatever, because it has access to the data model. I know this goes against REST catechism but I am inclined to consider it a feature, not a bug.

Lada

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

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