skip to content

On a RESTCONF server, what does each HTTP method — GET, POST, PUT, PATCH and DELETE — do to YANG-modelled configuration data?

level: juniorimportance: must knowfreq 22%

answer

  1. one verb per CRUD job
  2. each verb has a NETCONF twin
  3. replace versus merge
  4. POST names the parent, not the child
  5. delete, not remove

basics

~20 s

RESTCONF (RFC 8040) maps HTTP methods onto YANG data: GET reads a subtree, POST creates a child or invokes an operation, PUT creates or replaces the target, plain PATCH merges into it, and DELETE removes an existing node.

solid answer

~40 s

RFC 8040 §4 ties each method to a NETCONF equivalent. `GET` (and `HEAD`) is `<get-config>`/`<get>` and returns the target node with all its descendants. `POST` on the datastore or a data resource creates one child inside it — `201 Created` with a `Location` header, `409 Conflict` if the child already exists — while `POST` on an operation resource runs the operation. `PUT` is an `<edit-config>` create-or-replace of the node it names (`201` when it creates, `204` when it replaces) and a `<copy-config>` when aimed at `/data` itself. Plain `PATCH` is a `merge`: it adds or updates children but cannot delete them, and it never creates the target. `DELETE` is NETCONF `delete`, not `remove`, so the node must already exist.

go deeper

for a junior

Recall the five verbs and what each does to a YANG subtree: GET reads, POST creates under a parent, PUT replaces, plain PATCH merges, DELETE removes an existing node.

for a middle

Explain the NETCONF operation behind each method and the status codes that prove it: 201 with Location for POST, 201 versus 204 for PUT, 409 for a duplicate create.

for a senior

Show you know which method an automation job should use for a partial change, and why a PUT on a parent node is the dangerous default.

for a principal

Discuss how one method-to-operation mapping keeps RESTCONF and NETCONF edits consistent on a device, and when a team should mandate merge-style edits.

## What RESTCONF does with HTTP **RESTCONF** (RFC 8040, Standards Track, January 2017) exposes a network device's configuration and state data — data whose shape is defined by **YANG** modules — as HTTP resources. Every YANG container, list entry, leaf, leaf-list entry, anydata and anyxml node under `{+restconf}/data` is a **data resource** with its own URI; `{+restconf}/data` itself is the **datastore resource**; every YANG `rpc` is an **operation resource** under `{+restconf}/operations`. RFC 8040 §4 then gives each HTTP method one job on those resources and ties that job to a NETCONF operation, so a device that speaks both protocols treats a change the same way whichever protocol carried it. Two rules frame everything that follows: - **A method acts on the whole subtree.** RFC 8040 §3.5 says a method on a data resource affects the targeted node *and all of its descendants*. Reading a container returns everything inside it; replacing a container replaces everything inside it. - **The server owns the transaction.** The client sends no lock and no commit. Transaction management is the server's, and each successful edit is saved to non-volatile storage if the device has it. ## The method table | Method | Target | NETCONF equivalent | Success | Watch out for | |---|---|---|---|---| | `GET`, `HEAD` | datastore or data resource | `<get-config>`, `<get>` | `200 OK` | `404` for a missing instance; `405` on an operation resource | | `POST` | datastore or data resource (the parent) | `<edit-config>` with `create` | `201 Created` + `Location` | `409 Conflict` if the child exists | | `POST` | operation resource | the `rpc` itself | `200 OK` with output, `204` without | it is not a data write at all | | `PUT` | data resource | `<edit-config>` create or replace | `201` if created, `204` if replaced | omitted children are deleted | | `PUT` | datastore resource | `<copy-config>` | as for any `PUT` | the whole datastore is replaced | | `PATCH` (plain) | existing datastore or data resource | `<edit-config>` `merge` | `200` with a body, `204` without | the target is never created | | `DELETE` | one data resource instance | `<edit-config>` `delete` | `204 No Content` | fails if the node does not exist | ## Reading: GET and HEAD `GET` returns the target node with its descendants, filtered by access control: content the user may not read is left out of the response. A request for a list instance that does not exist gets `404 Not Found`; a `GET` on an operation resource gets `405 Method Not Allowed`, because an `rpc` is invoked, not read. `HEAD` returns the same header fields — including any `ETag` and `Last-Modified` the server keeps — without the body. ## Writing: POST, PUT and PATCH 1. **`POST` creates.** The URI names the *parent*; the body carries exactly one child instance, key values included. Success is `201 Created` with a `Location` header naming the new child and no body. If the child already exists the request fails with `409 Conflict`, so `POST` is create-only. A `POST` to an operation resource is its other mode: it invokes the operation. 2. **`PUT` creates or replaces.** The URI names the resource itself. If it did not exist it is created (`201`); if it did, its whole subtree is replaced by the body (`204`), and children the body leaves out are gone afterwards. A `PUT` to `{+restconf}/data` replaces the entire datastore. A `PUT` may not change a list entry's keys: the key values in the body must match those in the URI. 3. **Plain `PATCH` merges.** The body — `application/yang-data+json` or `application/yang-data+xml` — is merged into the target: missing children are created, present ones updated, unmentioned ones left alone. It cannot delete a child, and if the target itself does not exist the server must not create it. Richer patch formats such as **YANG Patch** (RFC 8072) are optional; a server lists the ones it accepts in the `Accept-Patch` header of its `OPTIONS` response. ## Removing: DELETE `DELETE` maps to NETCONF `delete`, not `remove`: RFC 8040 says the resource must exist or the method fails, where `remove` would have ignored a missing node. A `DELETE` also removes exactly one instance — aimed at a list or leaf-list, it must identify a single entry. Success is `204 No Content`. ## What every method shares - The server converts the URI into a YANG instance identifier and applies **NACM** (RFC 8341, which obsoletes RFC 6536) to it. A refused write normally returns `403 Forbidden` with error-tag `access-denied`; a server may answer `404` instead. - Errors come back as an `errors` structure carrying NETCONF-style fields such as `error-type`, `error-tag` and `error-message`. - `OPTIONS` is mandatory and tells the client which methods a resource supports. The version a candidate should be able to say without notes: **GET reads, POST creates under a parent or runs an operation, PUT replaces what it names, plain PATCH merges into what it names, and DELETE removes one thing that must already exist.**

  • Why does RESTCONF offer both POST and PUT for creating data?
    They differ in who names the resource and what happens on a repeat. `POST` targets the parent, carries the new child (keys included) in the body, and fails with `409 Conflict` if that child exists — a strict create. `PUT` targets the new resource's own URI and creates or replaces it, so repeating it converges on the same state. Use `POST` when a duplicate must be an error, `PUT` for an idempotent upsert of a node you fully describe.
  • How does a RESTCONF client discover which PATCH formats a server accepts?
    It sends `OPTIONS` to the resource. RFC 8040 requires the server to return an `Accept-Patch` header listing the patch media types: plain patch uses `application/yang-data+json` or `application/yang-data+xml`, and a server that supports YANG Patch (RFC 8072) also lists `application/yang-patch+json` or `+xml` and advertises the `:yang-patch` capability in its monitoring data.

saying these in an interview costs you the question

  • PUT and PATCH both just update the fields you send.
  • A RESTCONF DELETE of a missing node quietly succeeds, like NETCONF remove.
  • To create a list entry with POST, send it to the new entry's own URI.
  • A plain PATCH creates the target resource if it does not exist yet.
  • A plain PATCH can delete a child by sending it with an empty value.