There has been lot of talk about the need for networking personnel to evolve their skillsets, as open networking, programmable networking, and SDN proliferate. Do network engineers need to become full-fledged programmers – No. However, do they need to pick up additional scripting and “programmability” skills – Yes.
One key aspect of hooking things together in the software-defined anything (SDx) world is APIs. APIs are, in essence, the new IP/Ethernet – the new way to hook systems together. We call this the “API Economy”, but not all APIs are created equal.
Nowadays, nearly all networking vendors have an API, but ample differentiation exists between them. So, in taking a page form our software-oriented brethren (app developers) as they’ve been dealing with APIs for years…here are some questions you can ask to help interrogate your networking vendor’s APIs.
- What percent of the product features are exposed via the API, versus the graphical user interface (GUI) or command line interface (CLI)?
- Is the API easy to use and/or RESTful?
- Is the API open (published to the public)?
- Is the API well-documented?
- Is there an active or growing community to assist with usage and/or to provide a self-sustaining model?
- Are there samples to help me start (including sample integrations for common usage scenarios or with commonly used tools)?
- Is the latest API reverse-compatible with prior versions, and is there a guarantee that future APIs will be reverse-compatible?
- Is there an associated software development kit (SDK)?
I’m sure there are other good questions, but here’s a start.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.