Brian Christopher Raaen asked a great question in a comment to my OpenStack/Quantum SDN-Based Virtual Networks post:
Other than some syntax difference what do these new HTTP-based APIs add that SNMP couldn't already do?
What is a RESTful service
If you’re not familiar with the concept of Representation State Transfer (REST) you might want to read this Wikipedia entry that describes REST as an architectural solution, not a specific protocol or data format.
The most interesting part of the article is the description of the REST constraints. A RESTful service should be a stateless client-server service – clearly SNMP fits that role well. It’s harder to shoehorn SNMP into other constraints (cacheable layered system), but these constraints aren’t that important in the network programming space.
Moving forward to the guiding principles of a REST interface, the differences with SNMP become more pronounced. SNMP requires an external schema (MIB) to describe the data model, whereas a REST interface should provide self-descriptive messages.
Finally, while you could (in principle) run a RESTful service over an RFC 1149-based infrastructure, most real-life implementations run over HTTP(S), reuse existing Web services authentication/authorization mechanisms (HTTP authentication or cookies), and use JSON or XML as the data transfer format.
Why is REST better than SNMP?
Imagine you’re looking for someone to write detailed technical documentation for your new SDN gizmo. Would it be simpler to find someone fluent in English or in Elbonian?
The situation is no different in the programming world – anyone can write a client script that uses HTTP(S) to send form data to a web server and process JSON response (XML-based requests and responses might already represent significant mental challenges to some youngsters).
HTTP(S) client is usually included with modern programming languages and available (at least as a library) in every single language I’ve tried to use in the last decade (before you ask: there was no HTTP client in Turbo Pascal, PL/I or Fortran IV when I was still using them), and a lot more programmers were exposed to HTTP than to SNMP, some of them probably never realizing where the HTTP part of the XMLHttpRequest object comes from.
The situation is no different on the server side. You can implement a RESTful server in any programming language using any open-source web server, from standalone PERL scripts and lightweight options to full-blown web servers. SNMPv3 server? Not so easy.
I can’t see a major functional difference between a RESTful service and SNMP (if I’ve missed something fundamental, please write a comment). Also, I can’t see where SNMP would be better than a RESTful interface now that we’re past the days of Z80 processors being used in networking devices.
BTW, don’t tell me most SNMP MIBs are read-only. I’m well aware of that – but that’s not a limitation of the SNMP protocol, but of its implementations in specific network devices. Wellfleet was more than happy to have their routers fully configurable through SNMP … unfortunately that was the only configuration mechanism they offered, and their SNMP-based CLI was a royal pain.
However, regardless of what our opinions might be, REST is clearly a mainstream solution and SNMP is limited to a very specific field. Which one do you think will be used more?
This post was written more than a week ago (it took me a while to publish it); in the meantime John Gruber wrote a great reply to the above question.