Re: [Netconf] Representing URLs

[Wojciech Dec <[e-mail]>]

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

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