This article illustrates what the server may reply with upon GET request on a list or leaf-list entry. 

The result may depend on what data is getting retrieved, either configuration data or operational data.


Let us go through simple examples that will illustrate what to expect from the server upon GET requests. First we need a YANG module. Consider this simplified, but functional, example.


module example {
  yang-version 1.1;
  namespace "http://yumaworks.com/ns/example";
  prefix ex;

  container interfaces {

    list interface {
      key "name";

      leaf name {
        type string;
      }

      leaf description {
        type string;
      }

      leaf type {
        type string;
        mandatory true;
      }
    }
  }

  container interfaces-state {
    config false;

    list interface {
      key "name";

      leaf name {
        type string;
      }
    }
  }
}


Configuration Data

In case the target of a request is a configuration list, the server will follow the RFC8040:


If a retrieval request for a data resource represents an instance
that does not exist, then an error response containing a "404 Not
Found" status-line MUST be returned by the server. The error-tag
value "invalid-value" is used in this case.

Thus, upon a GET request on non-existent list entry the server will return:


GET /restconf/data/interfaces/interface HTTP/1.1
Host: hostname
Accept-Type: application/json



Content-Type: application/json
Status: 404 Not Found
Cache-Control: no-cache
Pragma: no-cache

{
 "ietf-restconf:errors": {
  "error": [
   {
    "error-type":"rpc",
    "error-tag":"invalid-value",
    "error-app-tag":"data-invalid",
    "error-message":"invalid value",
    "error-info": {
     "error-number":258
    }
   }
  ]
 }
}


Operational Data

In case of operational data the reply will depend on whether there is a GET callbacks for the data node or not. If there is no any callbacks registered for the target list or leaf-list node the server will follow the same rules as for configuration data and will reply the same Not Found error.


However, if there are GET SIL callbacks for the target operational node the server cannot know if the data exist or not until it actually starts to build the reply. At that time it contacts the SIL GET callbacks and verifies that the data exist and outputs

it or if nothing is returned from the SIL code then the server outputs an empty result.

GET /restconf/data/interfaces-state/interface HTTP/1.1
Host: hostname
Accept-Type: application/json



Content-Type: application/json
Status: 200 OK
Cache-Control: no-cache
Pragma: no-cache

{
 "interface": [   ]
}


There could be a possibility to change this behaviour to be as for config nodes but that would take to much extra processing power and also would require to call callback(s) more extra time(s). Which is questionable to implement to solve this difference.