REST APIs and Data Models (JSON, XML, YANG)
This domain tests how automation talks to devices and controllers over HTTP and how data is modeled. Know REST fundamentals: resources identified by URIs, HTTP methods (GET read, POST create/execute, PUT replace, PATCH partial update, DELETE remove), status codes (200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 409 Conflict, 500 Server Error), statelessness, and common auth (Basic, token/bearer).
Be fluent in JSON (objects, arrays, strings, numbers, booleans, null) and able to read XML (elements, attributes, namespaces). Recognize that XML namespaces affect parsing and that element ordering can matter in some models. Understand YANG as the data modeling language behind NETCONF/RESTCONF: modules, containers, lists, leaves, leaf-lists, keys, and the distinction between configuration data and state data (config false). Know that YANG models drive both the payload structure and validation.
Traps: confusing PUT (full replace) with PATCH (partial); assuming GET is always safe to retry but POST is not necessarily idempotent; ignoring that a 200 does not guarantee the device applied the change (verify afterward); and mixing up JSON null with an absent key. Also expect questions on content negotiation (Accept/Content-Type) and on the difference between a data model (YANG) and an encoding (JSON/XML).
Rule of thumb: YANG defines what the data looks like; JSON/XML define how it is serialized; REST defines how you transport it.
Worked example: To change only a description on an interface, use PATCH with a small JSON body rather than PUT with the full interface object - PUT would replace the resource and could drop unspecified fields.