API: RPC resources located under /restconf/data rather than /restconf/operation about yang HOT 11 CLOSED

from yang.

This seems to be related to what I've opened yesterday: freeconf/restconf#4
The inputs of RPC calls should be formatted differently too: freeconf/restconf#5

from yang.

from yang.

from yang.

Thanks for the quick reply. That was my reading of the specification, yes.

However I have only been reading through the spec today. I can look further into this and post back on this issue. I'm interested in using gconf to learn more about RestCONF and YANG, so would be happy to work on a pull request if it does turn out to be a bug :)

from yang.

According to RFC 7950 Section 7-.15:

The difference between an action and an rpc is that an action is tied
to a node in the datastore, whereas an rpc is not. When an action is
invoked, the node in the datastore is specified along with the name
of the action and the input parameters.

So an action could be thought of as a method on an object, which explains why it is attached to a URI with the format {+restconf}/data/<data-resource-identifier>/<action>.

Looking at the ABNF grammar defined in RFC 7950 Section 14: rpc statements have to be in the "module" level, whereas an action has to be within a list, container or grouping node (they can also be used in uses-augment or augment it seems, though I think this may be for overriding the action statement?).

From my understanding, say you have server farm that models a list of running servers:

module server-farm {

  container servers {
    list servers {
      key name;
      leaf name {
        type string;
      }
      action reset {
        ...
      }
    }
  }

  rpc powerdown {
    ...
  }
}

The reset action is tied to a single server POST http://localhost:8080/restconf/data/server-farm:servers/server=server0/reset, whereas shutting down the server farm itself is an RPC operation that acts on the module level POST http://localhost:8080/restconf/operation/server-farm:powerdown.

from yang.

from yang.

Point 3 only seems to be referenced as a "might" in the specification, so could be separated into a nice-to-have ticket.

from yang.

from yang.

Maybe this could be adapted to add more testcases for freeconf... two years ago I started helping a different restconf project. For this I assembled a list of Restconf testcases derived from the IETF RFCs in machine readable form.

https://github.com/fkie/ietf-restconf-testcases

from yang.

This issue has been resolved in the "compliance" branch which will soon merge into master

from yang.