Showing results for 
Search instead for 
Did you mean: 

Access leaf-list entries via REST

I have a simple YANG file with a list and a leaf-list loaded on NSO.

I'm able to GET/DELETE specific list entry with:

GET /uri/list_entry/1

But I'm unable to access the specific leaf-list entry with:

GET /uri/leaf_list_entry/1

What am I missing?




I think that's because, as opposed to lists, which contain multiple instances, a leaf-list is treated as a single, indivisible entity, whose type happens to be something like an array rather than something scalar like a string or integer.

Also, you can't necessarily access list elements via a sequential index (e.g. /list_entry/1, /list-entry/2, etc..).  You need to use the value of the key field in the list (e.g., /list_entry/KEYVALUE).  I'm guessing you just happened to choose a numeric key value for your example list above.  Leaf-lists have no key field, however, so they can't be accessed in the same way.

That said, there's no reason I could think of that NSO couldn't be changed to implement a sequential indexing of leaf-lists to allow them to be accessed in the way you're trying, as long as the order of the elements remains fixed regardless of how the leaf-list is accessed, which seems to be an RFC requirement anyway (RFC 6020 - YANG - A data modeling language for NETCONF)

I know none of this helps you solve your problem, but hopefully it explains the behavior you're seeing.  I think the solution for your use case is that you just need to fetch the entire leaf-list and do post-processing in your script to extract individual elements.

Thanks for the response.

I did use the KEY-VALUE to access the leaf-list, but no luck. Is there anyway to debug it on NSO?

Here are the logs:

txslmacl2215:~ agrahki$ curl -i -u admin:admin -X GET -H "Accept: application/vnd.yang.collection+xml"

HTTP/1.1 200 OK


Date: Fri, 04 Aug 2017 15:37:06 GMT

Last-Modified: Fri, 04 Aug 2017 14:23:13 GMT

Cache-Control: private, no-cache, must-revalidate, proxy-revalidate

Etag: 1501-856593-907956

Content-Type: application/vnd.yang.collection+xml

Transfer-Encoding: chunked

Pragma: no-cache

<collection xmlns:y="">

  <vlan xmlns="">1</vlan>

  <vlan xmlns="">1091</vlan>


txslmacl2215:~ agrahki$ curl -i -u admin:admin -X GET -H "Accept: application/"

HTTP/1.1 404 Not Found


Date: Fri, 04 Aug 2017 15:37:27 GMT

Cache-Control: private, no-cache, must-revalidate, proxy-revalidate

Content-Length: 178

Content-Type: text/xml

Vary: Accept-Encoding

Pragma: no-cache

<errors xmlns="">



    <error-message>invalid path</error-message>



leaf-lists don't actually have keys.  If you absolutely must access individual elements via the REST API, you should probably consider remodeling your leaf-list as a list.

That did not work

I have a CLI like below:

port trunk permit vlan 9 130 146

I have used the following YANG to handle this CLI:


            leaf-list vlan {

              tailf:cli-flat-list-syntax; <----------------------

              type uint16 {

               range "1..4024";

               tailf:info "<1-4024>;;VLAN ID";




If I convert it to a list, the tailf:cli-flat-list-syntax command will no longer work.

Any workarounds for that?



Since ability to access individual elements in a leaf-list is an RFC requirement, how do I raise a request for NSO to support it?

   If a data node in the path expression is a YANG leaf-list node, then the leaf-list value MUST be encoded according to the following rules:  o  The identifier for the leaf-list MUST be encoded using one path segment [RFC3986].  o  The path segment is constructed by having the leaf-list name, followed by an "=" character, followed by the leaf-list value. (e.g., /restconf/data/top-leaflist=fred). 

I filed a ticket on this, and placed you on cc.