Don't Get Obsessed with REST API
REST API is the way of the world and all network devices should support it, right? Well, Ken Duda (Arista) disagreed with this idea during his Networking Field Day presentation, but unfortunately there wasn’t enough time to go into the details that would totally derail the presentation anyway.
Fixing that omission: should we have REST API on network devices or not?
Before going into the details:
- Well-defined and well-behaved API is obviously the best way to implement an interface to a system, and a great foundation for a robust automation solution… but you might not need a REST API.
- REST is so loosely defined that it could mean anything (it doesn’t even have to run over HTTP). For the purpose of this discussion we’ll assume that we’re talking about the common understanding of REST as an API providing CRUD functionality: you can Create, Read, Update or Delete individual objects known by the system you’re interfacing with.
Now consider how you’d like to manage a network device. Would you like to create/update/delete individual objects (interfaces, neighbors, ACL entries, static routes) the way we’re doing today with the CLI, or would it be better to treat the network device as a single-purpose system with a configuration that can be replaced and reloaded as needed?
If you think we need REST API to manage network devices, then you’re effectively trying to replicate existing workflow where we spend inordinate amount of time considering the right sequence of steps to get from here to there, and replace it with a faster version of the same choreography. See also: CRUD hell.
Wouldn’t it be better to tell the device how it should work (intent, anyone?), and tell it to reload the “how it should work” document as needed?
Looking for analogies beyond networking: do you want your network device to look like an orchestration system with a REST API (OpenStack comes to mind) or like a web server (configured with text configuration and no API)? What do you think?
For a more in-depth discussion of this topic, watch the Intent-Based Networking section of Network Automation Concepts webinar.
This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.
I think RPCs are much cleaner (and most vendor implementations of REST are just wrappers around the RPC anyway) and make more sense, especially to a network engineer who is trying to automate something.
REST has some things going for it, such as language freedom, the tools that I mentioned before and there are a plethora of tutorials on using REST on the web that can give someone enough information on "how" to use REST so they can at least attempt it with a device without ever knowing exactly what the vendor has implemented.
However, REST has overhead, IMO is only a couple steps ahead of SOAP (which sucks) and as a network engineer, if I have to read my own or someone else's code, looking at RPCs is much cleaner than all the crap you have to use to create a REST call.
I'd say given a lack of anything else there should at least be a REST API to interface with.
Also agree that in my experience it is enough to have the capability to replace the whole running configuration without any service interruption like juniper offers, at least if you are going to do all of your configuration changes through a custom built application. You can just create a full configuration each time you make a change and replace it instead of figuring out different api calls based on the change you made and this also makes it easy to monitor for difference between the real running configuration and the configuration from your database. In addition you only need to use other api calls for some show commands to monitor state that cannot be seen in the configuration.
I also made the experience that automation using screen scraping is possible (HP Provision) but takes much longer and is prone to errors. You also have to solve stupid problems like timing errors during login and command execution, etc. so I would only recommend that if you have a lot of those devices which are too expensive to replace and are not planning to implement too many complex features in your automation solution (we only use it for l2 switches for example).
So I don’t think REST is needed but you should look for devices which have a good interface for automation if you have any possible plans in that direction.
& protocol buffers are a bonus
but to answer your question, if I were given the choice between REST API & CLI/config file, well, CLI/conf wins hands down
Thanks for the wonderful post.
Since I haven’t been deep into Automation and API yet myself but have spent some time digging into those areas in general for my understanding, so wanted to check if my understanding is correct or I am missing something while I am waiting for a REST API webinar of yours. ��
To me REST is just another fancy interface and not very different from the way currently CLI works.
We essentially make REST calls which needs to follow :
- URL
- Authentication
- Some REST command "essentially again syntax defined by vendor in documentation " - Well sounds like old days " Alias " to me ��
- Obviously it doesn't necessarily define format such as JSON, XML (which are my choices but not sure if those are consistent across vendors and platforms )
In order for multiple devices to work as a system, we are looking for essentially REST as way to provide standard interface. But you still have pretty much same set of challenges that " CLI " poses.
- REST commands are platform and vendor specific
- You still need to get the order of operation or sequence right to ensure you " Intent " can be consumed by end device
And if I am not wrong until this point :)
- We can similarly consider " CLI " as universal interface - SSH is enough secure too (Atomic function might be a requirement but Juniper has fixed it right from beginning while status codes are easy to define as long as vendor would want to)
- The sequence still needs to be followed
- We can talk to pretty much any device (pretty old ones too) - Most Orchestrator vendors realized it at some point including guys from Ansible ��
- Yes we need to follow every vendors " CLI " structure but I guess that is same problem with REST too
Now question is how to do it better ?
I know Open Config, YANG (Little I know about ) are trying to fix the problems in terms of how we push/pull the configurations/stats. Though I am not sure if it’s easy to standardize this across Vendors. But this approach still doesn’t solve the problem I described above for most part.
Also I quickly wanted to know your take on troubleshooting a device with Just REST API interface. Shall the Engineer memorize now REST commands instead of CLI commands for given platform as we know most GUI based systems are far less flexible today in terms of customization support or else it comes at price.
And did I suggest that the data returned by REST call such as GET is not standardized either and many vendors just send and receive old CLI commands over REST and claim they offer REST interface for interaction.
Thanks!
Evil CCIE