In RESTCONF, how do YANG containers, lists and leaves become the URI path of a data resource under {+restconf}/data?
answer
- the model fixes every address
- one path segment per data node
- module name on the top node
- list entry written as name=key
basics
~20 sEvery data node from the top of the YANG tree down to the target becomes one path segment under {+restconf}/data: containers and leaves by name, list entries as name=key, and the top-level node prefixed with its module name.
solid answer
~40 sRFC 8040 §3.5.3 builds a data resource identifier left to right from the YANG model. Start at `{+restconf}` (the root the client discovered; the RFC's examples use `/restconf`), add `/data`, then add one segment per data node from the top-level node down to the target. A container or a leaf contributes its name; a list entry contributes `name=key`, with several keys separated by commas in `key`-statement order; a leaf-list entry is `name=value`. The top-level node is written `module-name:node`, and so is any node defined in a different module from its parent, such as one added by `augment`. So the description of interface `eth0` in `ietf-interfaces` is `/restconf/data/ietf-interfaces:interfaces/interface=eth0/description`, and a method on that URI acts on the node and everything beneath it.
code
http · 8 linesGET /restconf/data/ietf-interfaces:interfaces/interface=eth0/description HTTP/1.1
Host: example.com
Accept: application/yang-data+json
HTTP/1.1 200 OK
Content-Type: application/yang-data+json
{ "ietf-interfaces:description": "Uplink to ISP" }go deeper
Recall the shape: the root, /data, one segment per data node, list entries as name=key, and the module name on the first node. Be ready to write a simple path from a model.
Explain exactly when a module name is required, top-level nodes and namespace changes, and why it is the module name rather than the import prefix.
Show that a URI's depth sets how much data a request touches, since methods act on the target and all descendants, and pick targets with that in mind.
Discuss why a predictable, model-derived URI scheme lets clients be generated from YANG, and what that couples them to when models are revised.
## Why the URL can be written from the model RESTCONF (RFC 8040) is an HTTP interface to configuration and state data described by **YANG** modules. Its central promise for this topic is a **predictable location**: because a YANG module gives every data node a fixed, absolute position, a client can write the URL of any piece of data from the model alone, without asking the server for links. RFC 8040 §3.5.3 calls the result a **data resource identifier** and gives its grammar as the `api-path` rule. A few terms first: - **Data node** — a node that can exist in the data tree: a container, a leaf, a leaf-list, a list, an anydata or an anyxml node. - **Data resource** — one targetable instance: a container, a leaf, one leaf-list entry, one list entry, an anydata or an anyxml node (§3.5). - **Datastore resource** — `{+restconf}/data`, the conceptual root holding all the configuration and state data a client can reach (§3.4). - **`{+restconf}`** — URI-template notation (RFC 6570) for the RESTCONF root, which a client discovers rather than assumes; the RFC's examples use `/restconf`. ## The pieces of a data resource URI | Piece | Example | Rule | |---|---|---| | Root | `/restconf` | discovered once, then used at the start of every request | | Datastore resource | `/data` | the mandatory child of the root that holds every data resource | | Top-level node | `ietf-interfaces:interfaces` | always `module-name:` plus the node name, because its parent is the datastore | | Container or leaf below it | `description` | the node name alone, while the namespace stays the same | | List entry | `interface=eth0` | the list name, `=`, then the key value or values | | Leaf-list entry | `allowed=value` | the leaf-list name, `=`, then the value | ## Walking the model to the URL Take `ietf-interfaces` (RFC 8343, which obsoletes RFC 7223). A top-level container `interfaces` holds a list `interface` keyed by the string leaf `name`, and each entry has leaves such as `description`, `type` and `enabled`. To reach the description of `eth0`: 1. Start with the discovered root and the datastore resource: `/restconf/data`. 2. Add the top-level container with its module name: `/ietf-interfaces:interfaces`. 3. Add the list entry with its key: `/interface=eth0`. 4. Add the target leaf: `/description`. The result is `/restconf/data/ietf-interfaces:interfaces/interface=eth0/description`. Stopping one step earlier, at `/interface=eth0`, targets the whole entry; stopping at `/ietf-interfaces:interfaces` targets every interface. ## What a URI targets RFC 8040 §3.5 says the representation of a data resource is its YANG-defined subtree, and that HTTP methods on a data resource affect the targeted node **and all of its descendants**. So the point at which you stop writing the path decides how much data a request touches: - a leaf URI reaches one value; - a list-entry URI reaches that entry with every child node, nested containers included; - a container URI reaches everything nested inside it; - `{+restconf}/data` itself is the datastore resource rather than a data resource, and reaches everything the client may see. ## Module names on the path YANG nodes live in **namespaces**, one per module. RFC 8040 requires `module-name:` before a node in two cases: when its parent is the datastore (the top-level node), and when it is defined in a different module from its parent, typically a node added to another module's tree by `augment`. Every other node is written bare. Two details trip people up: - It is the **module name** (`ietf-interfaces`), not the short **prefix** a YANG file declares when it imports a module (`if`). Prefixes are local to one module's source text; module names are global. - RFC 8040 ties its identifier syntax to the JSON naming rules of RFC 7951 §4, which require the short form wherever the namespace has not changed, so qualifying every segment is not the encoding the specification describes. ## What never becomes a segment Only data nodes become segments. Constructs that exist only in the schema, such as a `choice` and its `case` branches or a `grouping` brought in by `uses`, never take a segment of their own; the data nodes inside them appear directly under their data-node parent. Key values and leaf-list values are written in the canonical form of their YANG type, and reserved characters inside them are percent-encoded, which matters as soon as an interface name contains a `/`. The reply to a GET is shaped by the same model: the top-level member of the returned document carries its module name, as the example below shows.
- Why does the top-level node carry its module name while the nodes beneath it usually do not?Top-level nodes from many modules share one datastore, so two modules could define a top-level node with the same name; the module name removes the ambiguity. Below the top, a node inherits its parent's namespace, so RFC 8040 asks for the module name again only where a node comes from a different module than its parent, as an augmentation does.
- What is the difference between targeting interface=eth0 and interface=eth0/description in ietf-interfaces?The first is the list-entry data resource: a method on it acts on the whole entry, every leaf and child container included. The second is a single leaf. Because a RESTCONF method affects the target and all of its descendants, choosing the deeper URI is how a client limits a read or an edit to one value.
A RESTCONF URI is like a file path on a disk: containers are folders, a list entry is the one file picked out by its name, and the module name is a volume label written on the first folder and again only where the path crosses onto another volume.
saying these in an interview costs you the question
- Every segment of a RESTCONF path must carry its module name.
- The YANG import prefix, such as if, goes in front of the top node.
- A list key goes in its own path segment, as in interface/eth0.
- The RESTCONF root is always /restconf because the specification fixes it.