Re: [Netconf] Representing URLs
Wojciech Dec <wdec.ietf@gmail.com> Tue, 03 December 2013 15:39 UTC
Return-Path: <wdec.ietf@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD931AE187 for <netconf@ietfa.amsl.com>; Tue, 3 Dec 2013 07:39:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzpfTdkm4rC4 for <netconf@ietfa.amsl.com>; Tue, 3 Dec 2013 07:39:43 -0800 (PST)
Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id F18481AE15E for <netconf@ietf.org>; Tue, 3 Dec 2013 07:39:42 -0800 (PST)
Received: by mail-pb0-f52.google.com with SMTP id uo5so21096654pbc.25 for <netconf@ietf.org>; Tue, 03 Dec 2013 07:39:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ToHgf7kO9gjjdd8txWbrD/LBkqvdELtvDLT08y54T3I=; b=fBLDGPOILMBlPILltCRc8X6qvapCLXyWqTv23bo6ulQG7BmV1P201kRXp/DehXD4XR ql33P5IMviPNtB0A7CRgQ1mkIt42+BQFoERK4DbCqa2eZmcrKNDWhkO5dk+ysFoAGlm/ TOJR8pPbZJMlODDOa4YUKUqt7fpjHiieLEnEOOZ8I1aM0Aeky1uREYT/7McCo+PTX8a3 1GhBPVSB6iw8Z8VEXsAof8epnD2aNbPQK/CjjBdbOr/ibt7/J6U5/GO6ZkrpiR2ZPTyQ qvYbA4/lGJpmwN4QyaDxXwL6nStG3MJz1F/6ZH+4jOL0nl1qCA9zRvl+sV/hwkrfn/ce ZsnA==
MIME-Version: 1.0
X-Received: by 10.69.31.65 with SMTP id kk1mr24669991pbd.126.1386085180369; Tue, 03 Dec 2013 07:39:40 -0800 (PST)
Received: by 10.70.57.163 with HTTP; Tue, 3 Dec 2013 07:39:40 -0800 (PST)
In-Reply-To: <CABCOCHS4rRJRy=TdXRTvM6mffG36u9uHRZWLOkm7a3rCne+Gwg@mail.gmail.com>
References: <CAFFjW4hXEZxTyhnaHLk-URST=6mNfX8kO1aFEVtEvTm8Z-qysw@mail.gmail.com> <CABCOCHS4rRJRy=TdXRTvM6mffG36u9uHRZWLOkm7a3rCne+Gwg@mail.gmail.com>
Date: Tue, 03 Dec 2013 16:39:40 +0100
Message-ID: <CAFFjW4iNX1rG7VnWqvHVz+c6-WdJ3d8aT1qiGbJGVOOA1Afz9A@mail.gmail.com>
From: Wojciech Dec <wdec.ietf@gmail.com>
To: Andy Bierman <andy@yumaworks.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Netconf <netconf@ietf.org>, draft-bierman-netconf-restconf@tools.ietf.org
Subject: Re: [Netconf] Representing URLs
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 15:39:45 -0000
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). Thanks, Wojciech. > >> >> Thanks, >> Wojciech. >> > > Andy >
- [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Juergen Schoenwaelder
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Ladislav Lhotka
- Re: [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Ladislav Lhotka
- Re: [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Ladislav Lhotka
- Re: [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Martin Bjorklund
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Martin Bjorklund
- Re: [Netconf] Representing URLs Ladislav Lhotka
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Martin Bjorklund
- Re: [Netconf] Representing URLs Andy Bierman