Re: [Netconf] Representing URLs

On 03 Dec 2013, at 16:39, Wojciech Dec <wdec.ietf@gmail.com> wrote:

> Following up some of my earlier questions... Inline...
> 
> On 29 November 2013 16:59, Andy Bierman <andy@yumaworks.com> wrote:
>> 
>> 
>> 
>> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec <wdec.ietf@gmail.com> 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?

Lada

> 
> Thanks,
> Wojciech.
> 
>> 
>>> 
>>> Thanks,
>>> Wojciech.
>>> 
>> 
>> Andy
>> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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