Interacting with NetApp APIs, Part 3

In Part 2 of this series we made our first API call and received over 200 lines of XML as a result. The reason why we received so much output is because we didn’t remove any desired-attributes  and therefore the call retrieved about 90 pieces of information. When you multiply that by the number of queries we ran (2), you get 180 pieces of information being requested.

This post will discuss why you should limit your queries to only the pieces of information you’re interested in. It will also cover how you can use ZExplore to convert its XML configuration to languages such as Python, Perl and Ruby.

Converting Code

As discussed previously in this series, ZExplore outputs your queries into the “Execute” tab in XML. However, you can also have it convert the queries to any one of the following languages:

  • C#
  • C
  • Java
  • Perl
  • Python
  • Ruby

You do this by navigating to “Preferences -> Languages”. Once you’ve selected a language the converted code is available in the “Develop” tab.

This is a fantastic feature because it allows you to add your NetApp API calls to your scripts simply by copying and pasting the generated code. Using this feature I’m able to combine my NetApp API calls with my Cisco MDS code which will enable me to automate the provisioning of storage for new hosts connected to the SAN network.

Cleaner Code

Cleaner code means you and anyone else who works with your code, is able to do their job more efficiently.  For example, say I’m only interested in retrieving:

  • A list of nodes who own aggregates with the name “aggr0*”.

Instead of generating over 140 lines of XML code:

and over 200 lines of Python code:

I can achieve the same results using less than 20 lines of XML:

And less than 50 lines of Python code:

This is a massive reduction of code and complexity. It is a much welcomed result considering the fact that you’ll likely be combining this code with other intelligence (e.g configuring MDS switches) and/or other API calls.

Further to this, even without any comments in the code it is clear what the latter script is achieving as opposed to the former script.

Network Traffic

I’ll now put my network engineer hat on for a moment to show what goes on behind the scenes with our API calls.

To make the information in my Wireshark captures more informative, I’ve connected to CDoT simulators through HTTP as opposed to HTTPS:

Please do not do this on production equipment though as it is completely insecure. Your username and password will be transmitted in clear text, as will all data that is requested and received.

Looking at the capture from our full, unedited query, we can see seven full sized packets (1514 bytes) being sent from the cluster to my PC:

On the other hand, when we modify the request to include only the pieces of information we want, we don’t even see one full sized packet:

The difference between the two is massive.

You’d be forgiven for thinking that it isn’t that much data in the grand scheme of things, but when you consider the fact that some of your remote sites might have high latency, low bandwidth and/or lossy connection, you begin to see the benefits of reducing the payload size.

Treat APIs like SNMP

My final point on this subject is that you should treat APIs like SNMP. You wouldn’t walk an entire SNMP tree just to get a device’s hostname, nor should you make unnecessary API calls.

Knowledge Base

See the Python section of my Knowledge Base for more information.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Leave a Reply