ENAUTO – RESTful APIs and RESTCONF completely reviewed, some much needed comparison to NETCONF, and configs!

RESTCONF is the cousin of NETCONF which both use YANG Data Modeling to talk, although while I know NETCONF prefers XML as its choice of encoding data to communicate and SSHv2 via TCP Port 830 to communicate, I assume that is where we will see some differences between RESTCONF and NETCONF protocols.

With that lets look at the Fundamentals of REST APIs (not specifically RESTCONF)

REST = Representational State Transfer

An architectural style for distributed hypermedia systems developed be Roy Fielding in his 2000 dissertation, which basically was Roy thinking “We already have HTTP Protocol with functions that work fine to interact with web servers, why not translate that over to the network to perform similar but network related functions?”

(I don’t think you really NEED to know all that info, but there for some background).

REST APIs utilize standard HTTP Verbs such as GET, PUT, POST, DELETE when talking to devices, and can use either JSON or XML to encode the data, JSON preferred with REST.

REST API Verbs are used to perform actions on “resources” which the target file the action is being executed against on the remote device, good terminology to know.

A good Acronym to know is CRUD – Create, Read, Update, Delete
This maps out to these HTTP Verbs – Post, Get, Put, Delete

Not sure if that helps much remember that REST APIs using HTTP Verbs maps to CRUD or how they interact at this point, but wanted to get that noted somewhere here.

Moving onto RESTCONF Intro topics specifically

RESTful APIs were introduced at the same time as NETCONF, and someone decided that REST already had such a great working model that could be applied to what NETCONF sets out to accomplish, they decided to marry the two together (kind of) to create RESTCONF.

Some of the changes of NETCONF to RESTCONF:

• Removed SSH Transport, added HTTPS in its place
• Uses HTTP Verbs rather than RPC in communication
• Added JSON as the data encoding method, though it does support XML
• Defined in standard RFC 8040

So which should I use, NETCONF or RESTCONF?

To demonstrate some decisions in making this decision:

• RESTCONF is a functional sub-set of NETCONF, but does not have full functionality of all NETCONFs features (not sure exactly what features are missing)
• Being HTTPS Based all messages are independent of each other, like how REST APIs in general are a series of Send / Receive and thats its, whereas NETCONF maintains a TCP Session via RPC messages
• This means REST APIs CANNOT track “state” while NETCONF can via its TCP Session
• REST operations do not track what has happened previously or what is coming next in the config, it just delivers single messages to accomplish an entire task

That last bullet point is an important of RESTCONF is that it completely forgets the message exchange after it happens, so for example if you issue a command that requires a password it will fail, as you might type in a command and it returns a password required response.

You then type in the password and send it back using RESTCONF and the device is wondering “Why is this password being send to me?” and returns an error message.

In contrast, because NETCONF establishes a TCP Session that remembers previous / next expected commands, this operation would be successful as part of the session.

^^^ That is probably the most important point of RESTCONF to understand 100%

A quick comparison of RESTCONF (and RESTful API) verbs vs NETCONF messages

GET        =     <get>, <get-config>
POST      =     <edit-config> (operation=”create”)
PUT        =      <edit-config> (operation=”create / replace”)
PATCH   =      <edit-config> (operation=”merge”)
DELETE =      <edit-config> (operation=”delete”)

So its HTTPS Verbs on the left (REST APIs) and RPC shown on the right (NETCONF)

Some quick RESTCONF configs I cannot execute myself due to lack of Nexus OS

Its about 99.9% the same as NETCONF where we enter “ip http secure-server” to create a self-assigned TrustPoint / Certificate, also requires a username/password with priv 15, however with RESTCONF you simply type “restconf” in Global Config to enable it!

The demonstration I saw was a fairly unimpressive WireShark capture using Postman to catch the packets going back and forth, but its using HTTPS (Encrypted) so wasn’t a whole lot to see so it was pretty not amazing.

In conclusion of both RESTCONF and NETCONF

I think NETCONF is the clear winner because it can track “state” of devices if needed, it establishes a TCP Session to accomplish tasks with multiple steps, though RESTCONF or RESTful API’s could definitely come in handly for light weight one and done changes.

I am now moving onto something other than Intro’s to Automation, not sure what yet, but whatever it is I will see you there 🙂