Following on from our previous article around NETCONF and YANG, we will look at the RESTCONF protocol.

As per RFC 8040 (RESTCONF Protocol), the IETF describes RESTCONF as,

β€œan HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).”

Protocol Stack

First lets look at the protocol stack. Compared to NETCONF, the RESTCONF protocol stack it is far simpler, in many ways. Lets step through the layers,

  • Content - Unlike NETCONF where we much use XML. RESTCONF allows for either JSON or XML to be used.
  • Operations - Each of the operations are aligned to the various HTTP methods, providing the required suite of CRUD based operations (Create, Replace, Update and Delete).
  • Transport - The transport protocol is HTTP, allowing us to use HTTPS. Providing the security benefits that TLS has to offer.


Figure 1 - RESTCONF Protocol Stack.


RESTCONF provides the ability to query and perform operations upon either the configuration or operational state. This is achieved by RESTCONF splitting the datastore into config and operational. Both of which are accessed via the URI`s:

  • /restconf/config  
  • /restconf/operational


Let's look at the RESTCONF operations to that of NETCONF,

GET <get>, <get-config> application/
GET <create-subscription> text/event-stream
POST any <rpc> operation application/yang.operation
PUT replace application/
PATCH any edit operation application/yang.patch
PATCH merge application/
DELETE delete application/


The first thing to mention is that RESTCONF listens on port 8080 for HTTP requests.  Furthermore the HTTP headers Content-Type and Accept are used (by the client) to instruct the server of the  data type (i.e XML or JSON).

For further details on how the URI is constructed check out Cisco Live - DEVNET-1721 - Introduction to NETCONF, RESTCONF and YANG (2017 Las Vegas).

Further Reading


About the Author


R Donato

Rick Donato is the Founder and Chief Editor of He currently works as an SDN/NFV Solutions Architect and has a keen interest in automation and the cloud.

You can find Rick on Twitter @f3lix001