Re: [Netconf] Representing URLs

[Andy Bierman <[e-mail]>]

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.


> Thanks,
> Wojciech.
>
>
Andy