5.4Interpreting responses and models

In model-driven automation, what you exchange with a device is not human-oriented show output but a structured response (JSON/XML) and the model (YANG) that governs it. To judge whether automation "worked," you must read success/failure from the response shape, grasp what each part of the model represents, and read what a change diff actually changes. This section trains that reading skill as the interpretation of a given response, model, and diff, not memorization.

5.4.1Reading RESTCONF/NETCONF responses

• RESTCONF maps CRUD to HTTP methods over HTTP (GET = read / POST = create / PUT = replace / PATCH = partial update / DELETE = delete). Responses are an HTTP status plus a JSON/XML body: 200 OK/201 Created are success, 204 No Content is success with no body, 401 is unauthenticated, 404 is a missing path (data), and 409 is a conflict. Read success/failure from both status and body.
• NETCONF exchanges XML over SSH (usually port 830); success is <ok/> inside <rpc-reply> and failure is <rpc-error> (cause in <error-tag>). It separates datastores as candidate (for editing) -> commit -> running (live), finalized by <commit> after <edit-config>. Judge success/failure by whether the reply is <ok/> or <rpc-error>.
• Read JSON response keys with their namespace: e.g., "ietf-interfaces:interface": [{ "name": "GigabitEthernet2", "enabled": true }] reads as "in the interface list of the ietf-interfaces model, there is an enabled entry named GigabitEthernet2." Calmly map which model, which element, what value.