Why is RESTful API better than SNMP?

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?

Short answer: nothing, apart from familiarity and convenient programming libraries.

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.

Amazingly, there’s an SNMP library for PHP and Ruby … or you could use Erlang (although I still can't figure out whether that's a joke as the manual was published on April 1st).

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.

Summary

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.

18 comments:

  1. HTTP/REST is certainly easier in some respects, but SNMP does have quite a few advantages. It supports types, MIBs are an excellent source of documentation for an API and those APIs tend to be considerably more stable than their RESTful cousins (the RabbitMQ management plugin API has changed in every single version I've deployed and broken nagios checks every time). Many of these APIs are even standardised (and some vendors even stick to them sometimes). There are some missing things, like properly standardised floats and doubles.

    Not to mention traps, a decent (if loathed) security model in v3, no TCP 3 way handshake (unless you want it). Stuff like EVENT-MIB and EXPRESSION-MIB give you standard server-side functionality. net-snmp does a pretty good job of doing most of the really hard stuff for you.

    The real problem for SNMP is that it is something else to learn and doesn't work well if you stick to the bare minimum. Doing tables properly is hard (that's trivial in a XML or JSON based REST API). People don't even think about using things like contexts. MIBs are also scarily close to actually writing documentation, which is never going to go down well with the majority of developers. It hasn't helped that most examples of SNMP usage try and bypass MIBs completely and use numeric oids for everything which makes examples practically impossible to read and gives SNMP a scary, super complicated air about it. You can do without MIBs, but that doesn't mean you should, you can always replace the textual values with the OIDs once you've worked everything out.

    I think SNMP's time may have come, but it has merits that we are losing with HTTP REST APIs, just not ones that people care about that much. How much they should care is open for debate.

    ReplyDelete
  2. Don't forget about bandwidth....
    SNMP GET and HTTP GET doesn't consume the same amount

    On slow links that remain in the wild, it would be a shame that supervision traffic consumes all bandwidth, especially when doing "GET BULK".

    ReplyDelete
  3. Python has excellent SNMP support. I've implemented custom agents in a couple of pages of code, and most of the effort lay in MIB design to implement GETNEXT

    As Tristan points out, SNMP tables are utterly brain-dead, just think of all the hassles with mutable ifIndexes. A text-based protocol is inherently more flexible than something relying on ASN.1 OIDs The original sin of SNMP is its use of OSI technology. Just think of how many security advisories have been caused by ASN.1 bugs over the years.

    ReplyDelete
    Replies
    1. Well, I wouldn't say that ASN.1 bugs were caused by it being an OSI technology ;) Judged by the "quality" of XML parser in Cisco IOS, being a W3C or IETF technology doesn't help much.

      Delete
  4. While I think SNMP will still be with us for some time to come, especially for graphing trends and alerting with traps, I see a lot of vendors moving to the newer http based methods. The bigger problem with snmp was how vendors implemented convoluted MIBs that were not documented well and were difficult to understand. Also every vendor (as well as internal group) had their own way of doing things that was different. I really don't see that same fundamental problem changing with the xml based technologies since everyone will have their own schema that works differently.

    SNMP was suppose to create a unified cross-platform device interaction framework, however it did not. The same thing is being attempted and proposed with these new solutions. I really don't see them fixing it, since it is not the technology that is the limiting factor but rather the way people implement it. I think imaging a grand unified cross platform/vendor interaction framework is really a pipe dream.

    Thanks for the discussion Ivan, I'm really enjoying it. I really enjoy getting people to think about things so we can improve ourselves and each other.

    ReplyDelete
  5. SNMP needs to die.

    Reading and writing awkward two column tables that are never indexed by the value you need is not an API.

    It is fine for counters, but everything else is needlessly complicated.

    This is probably the simplest example of how broken SNMP is as an API: http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00801c9199.shtml

    You need a 6 step process to reproduce "show mac-address-table address 0000.0c07.ac08"

    I have a python module that is few hundred lines of code that parses telnet/ssh output for switches. It lets me do things like write a program that enables dhcp snooping automatically based on the current vlan configuration and network topology.

    I have another program that you can run on a group of switches and give it 1 or more old vlans and 1 or more new vlans. It will automatically add the new vlans to any trunk ports that have the old vlans.

    These are the kinds of things a real API would help with.

    ReplyDelete
    Replies
    1. Not sure why google changed my name to "Unknown" but I think I fixed it :-)

      Delete
  6. Hi Ivan -
    I had just started putting together an article for Packet Pushers concerning a similar topic. Below is the gist of post:

    From what I understand, Cisco will be releasing their OnePK SDN offering as a language-specific API, starting with JAVA, with no clear roadmap afterwards. Instead, Cisco should initially release OnePK as a RESTful API. A Cross-Platform RESTful API would allow programmers and systems-scripters alike to adopt OnePK as their SDN platform from Day One.

    Examples:
    (1) Ethan could write Perl scripts to manage TCAM or routing tables (GET, PUT, POST, DELETE, etc)
    (2) You could write scalable webapps for, say, network monitoring, in Ruby, PHP, etc.
    (3) Enterprises with an internal development team would be able to write .NET applications for integrated inventory and network provisioning.

    Providing OnePK as a cross-platform RESTful API would allow immediate adoption by a considerably broader audience, many of whom influence the decision of which SDN strategy to adopt in their environment.

    -Mike

    ReplyDelete
    Replies
    1. Totally agree with you. Java-specific API is useless (at least for me and a few others).

      Delete
    2. Eh-late to the game on this one, but it is an interesting topic.

      I'm not sure how useless a Java-specific API is, since Java does have a dis-proportioned amount of the enterprise stack. On the whole I agree with you that they could've done better by maybe releasing a binary format like Avro, Thrift, Protocol Buffers, or maybe even Etch, since they did create it and it is supposed to be serialization for "consuming network services"

      Delete
  7. Another benefit of restful could be integrated monitoring client. Since you're already doing HTTP, it shouldn't be hard to serve a set of static (server-wise) webpages with javascript that fetch data and show it in real time. All that just by browsing to (mgmt) ip of device.

    Also regarding a comment about bandwidth requirements vs. snmp; if you're doing a lot of data fetching, you may be able to leverage http's support of compressed content-encoding, making this much less of an issue.

    ReplyDelete
  8. There's a cute descritpion of REST at:

    "How I Explained REST to My Wife"
    http://tomayko.com/writings/rest-to-my-wife

    -Mike

    ReplyDelete
  9. >Short answer: nothing, apart from familiarity and convenient programming libraries.

    Short answer: Do you understand FCAPS
    I find application/host programmers do not share the same experience in fielded products
    that as networking/embedded programmers.
    So if all you have is a hammer clearly its the right tool to use.

    ReplyDelete
  10. Ignoring implementation differences such as programmer familiarity and ease of use (which are of course important!), from a protocol perspective IMO the major difference between SNMP and HTTP is that SNMP specifies not only the transport layer but also the structure of the data in the PDUs - when you request an OID the client already knows what the type of the data is from the MIB.

    HTTP does not enforce this coupling of the transport and the message content. Whilst it is possible to request a particular MIME type encoding (i.e. text/html), the format of the response is not defined by the HTTP protocol specification. Of course, the client and server can use a MIME-type which has the ability to use schema to describe the messages (such as XML) - but then you're starting to look more SOAPy and less RESTy.

    I don't know if there are existing standards that provide schemas for defining the messages content - if there aren't any then the future will be painful for anyone who wants to interact with multiple vendors each of whom is using their own schema.

    To avoid this, I would like to propose the intriguing possibility of adding a new MIME type of text/snmp - allowing the HTTP REST'ful approach to be used with the schema and data types of SNMP!

    For example a HTTP GET with the to the URL:
    http://switch1/get_status/oid/1.3.6.1.2.1.1.3

    would return the ASN1.1 representation of the switches system uptime (or perhaps a JSON representation of the same).

    Perhaps this could be made part of the FCoTR alliance?

    PS. After I had this novel idea (to me anyhow), I searched and found this RFC draft: http://tools.ietf.org/id/draft-mellquist-web-sys-00.txt - which is similar in scope, although they just POST the SNMP PDU in the HTTP body don't use the OID in the path of the URL.

    ReplyDelete
  11. Back in my server admin days, I did a lot of work with SNMP, specifically to get server stats and trend them with MRTG and its offspring (like Cactus).

    I can say with all seriousness: SNMP is a terrible protocol, and should die a horrible death.

    SNMP 1 and 2 are very similar, although SNMP 2 has three distinct versions: 2a, 2b, 2c. Only 2c is really used. The biggest difference is that it enabled 64-bit counters. Both 1 and 2x are unencrypted.

    SNMP 3 changed a lot, including adding very crappy encryption (a simple pre-shared key). It was almost a decade before vendors started to implement SNMP v3 in any significant way.

    MIB files are a huge pain in the ass to parse, especially with your eyeball. The tools available are equally as crappy.

    RESTful APIs allow a much easier way to get access to data and do configuration. XML is a shitload easier to parse than a MIB file. And REST allows PKI (SSL/TLS and certificates and such) which offer much better (potential) security.

    Like modem init strings, OIDs haunt my dreams at night. Both are things I hope I never run into again.

    SNMP: Simple Network Management Protocol. The biggest lying acronym in IT :)

    ReplyDelete
  12. How does the REST/HTTP provide similar mechanism to SNMP notifications (traps)?

    ReplyDelete
    Replies
    1. HTTP callbacks. The REST server (in our case the network device) executes a GET or POST request on an URL provided in an API call.

      Delete
  13. The short answer suggesting that there is no difference between the two because one can do the same thing as the other is a classic logical fallacy. One can, as well, compare FTP file transfer protocol and SNMP, i.e. one can use SNMP to transfer a file, but this would not be the most efficient way to do it, and transferring a files is not what SNMP is good at. This article would serve better purpose if it only explains what SNMP is good for and what it is not good for and what REST is good for and what it is not good for without comparing the two. In a modern equipment, such as a servers, a network controllers, etc., typically you can find both, in ancient equipment SNMP is typically the one and only interface.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.