📘Cisco DevNet Associate (200-901 DEVASC)

1. Introduction

Modern networks use APIs to communicate with network devices and controllers. Instead of manually logging into routers or switches, engineers can query devices programmatically to retrieve information or configuration.

Two important protocols used for this purpose are:

RESTCONF
NETCONF

Both protocols allow a program to send a request to a network device and receive structured data in response.

After sending a query, the device returns a response message.
The ability to read and understand that response is called interpreting the query results.

For the DEVASC exam, you must understand:

How RESTCONF and NETCONF responses look
How data is structured
How to identify configuration and operational data
How to understand status codes and messages
How to read the returned data fields

2. What Is a Query?

A query is a request sent to a network device asking for information.

Examples of information that can be requested:

Interface configuration
Interface operational state
Routing table
Device hostname
Network statistics

The device processes the request and returns a structured response.

3. Data Models and Structured Data

Both RESTCONF and NETCONF use data models to organize device data.

The most common modeling language is:

YANG data modeling language

A YANG model defines how network data is structured.
Because of this structure, responses returned by RESTCONF or NETCONF are predictable and organized.

Data is usually returned in structured formats such as:

JSON
XML

Understanding the structure helps interpret the result correctly.

4. RESTCONF Query Results

4.1 What RESTCONF Returns

RESTCONF uses the HTTP protocol. When a query is sent, the device responds with:

HTTP Status Code
Headers
Body containing structured data

The body usually contains JSON or XML.

4.2 Example RESTCONF Response

Example JSON response for an interface query:

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet1",
    "description": "Uplink Interface",
    "enabled": true,
    "oper-status": "up",
    "statistics": {
      "in-octets": 245000,
      "out-octets": 320000
    }
  }
}

4.3 How to Interpret This Result

When interpreting this response, read each field carefully.

Interface Name

"name": "GigabitEthernet1"

Meaning:

This identifies the interface being queried.

Description

"description": "Uplink Interface"

Meaning:

Administrative description configured on the interface.

Enabled State

"enabled": true

Meaning:

The interface is administratively enabled.

If it was false, the interface would be shut down.

Operational Status

"oper-status": "up"

Meaning:

The interface is currently working.

Possible values:

Value	Meaning
up	Interface operational
down	Interface not active
testing	Interface in testing state

Statistics Section

"statistics": {
  "in-octets": 245000,
  "out-octets": 320000
}

Meaning:

Field	Meaning
in-octets	Bytes received
out-octets	Bytes transmitted

These counters help monitor network traffic.

5. RESTCONF HTTP Status Codes

RESTCONF responses also include HTTP status codes.

Understanding these codes is important for interpreting query results.

Status Code	Meaning
200 OK	Request successful
201 Created	Resource created
204 No Content	Request successful but no data returned
400 Bad Request	Invalid request
401 Unauthorized	Authentication required
404 Not Found	Resource not found
500 Internal Server Error	Server error

Example interpretation:

HTTP/1.1 200 OK

Meaning:

The query succeeded and the returned data is valid.

6. NETCONF Query Results

Unlike RESTCONF, NETCONF uses XML-based messages over SSH.

Responses are returned inside XML structures.

6.1 Basic NETCONF Response Structure

A typical NETCONF reply contains:

<rpc-reply>
   <data>
      ...
   </data>
</rpc-reply>

Components:

Element	Purpose
rpc-reply	Response to the request
data	Returned information

6.2 Example NETCONF Response

Example response for interface information:

<rpc-reply>
  <data>
    <interfaces>
      <interface>
        <name>GigabitEthernet1</name>
        <enabled>true</enabled>
        <oper-status>up</oper-status>
      </interface>
    </interfaces>
  </data>
</rpc-reply>

6.3 How to Interpret This Result

Interface Name

<name>GigabitEthernet1</name>

Meaning:

The interface being reported.

Enabled State

<enabled>true</enabled>

Meaning:

The interface is administratively enabled.

Operational Status

<oper-status>up</oper-status>

Meaning:

The interface is operational and functioning correctly.

7. NETCONF Error Responses

If the request fails, NETCONF returns an error message.

Example:

<rpc-error>
  <error-type>protocol</error-type>
  <error-tag>invalid-value</error-tag>
  <error-message>Invalid interface name</error-message>
</rpc-error>

Important fields:

Field	Meaning
error-type	Type of error
error-tag	Error category
error-message	Human-readable explanation

Example interpretation:

The interface name used in the query is incorrect.

8. Configuration vs Operational Data

RESTCONF and NETCONF queries may return two types of data.

Configuration Data

Configuration data represents settings applied to the device.

Examples:

Interface enabled/disabled
VLAN configuration
IP address

Operational Data

Operational data represents real-time device state.

Examples:

Interface status
Traffic counters
CPU usage

Example operational fields:

oper-status
statistics
packet counters

Understanding the difference is important when interpreting results.

9. Filtering Query Results

Queries often include filters to limit the returned data.

Example NETCONF filter:

<filter>
   <interfaces/>
</filter>

This tells the device to return only interface data.

Interpreting results requires checking whether the returned data matches the requested filter.

10. Common Things to Check When Interpreting Results

When reading RESTCONF or NETCONF query responses, always check:

1. Response Status

Determine if the request succeeded.

Example:

200 OK

2. Data Structure

Check how the data is organized.

Example:

interface → statistics → counters

3. Key Fields

Look for important configuration or state fields such as:

name
status
enabled
statistics
counters

4. Error Messages

If the query fails, check:

error message
error code
error tag

11. RESTCONF vs NETCONF Response Comparison

Feature	RESTCONF	NETCONF
Protocol	HTTP	SSH
Data format	JSON or XML	XML
Response structure	HTTP response + body	XML RPC reply
Error handling	HTTP status codes	rpc-error messages

12. Why Interpreting Query Results Is Important

Network automation systems must process device responses automatically.

Examples of IT uses include:

Network monitoring systems collecting interface statistics
Automation scripts validating device configuration
Controllers checking device operational state
Troubleshooting tools retrieving device information

Correct interpretation ensures the automation system makes accurate decisions based on device data.

13. Key Exam Points to Remember

For the **Cisco DevNet Associate (200-901 DEVASC) exam, remember these important concepts:

RESTCONF responses include HTTP status codes and JSON/XML data.
NETCONF responses use XML RPC messages.
RESTCONF errors are shown through HTTP codes.
NETCONF errors appear inside rpc-error messages.
Data returned by both protocols follows YANG data models.
Query responses may contain configuration data or operational data.
Always interpret field names, values, and structure in the returned data.