RESTful API: The ABCs of Network Visibility
Everyone in IT and the tech industries have seen the absolute explosion in the use of web-based application programming interfaces (APIs) in the last few years. Part of this increased usage is due to the maturing of the Internet. Ten years ago, everyone was still learning how to use this new creation. The usage is understood now. Another reason for increased usage is that web APIs enable websites and applications to interact with each other in a consistent and easy manner. This in turn allows developers to create specialized applications that can take advantage of the existing website capabilities and not have to create/recreate products, services and capabilities from the beginning all the time. For enterprises, this creates applications and services with minimal delays along and real cost savings for the IT department.
What is a RESTful API?
One of the most important APIs to emerge is called REST. This doesn’t mean that the previously reigning web API called SOAP (Simple Object Access Protocol) is dead. It still has some uses in the enterprise as part of existing service oriented architectures (SOA). At the same time though, the need for SOAP continues to fade as RESTful, service oriented architecture implementations take over.
So what is REST? REST is an acronym for REpresentational State Transfer and was an architecure created by the W3C that works in conjunction with the IETF HTTP protocol (RFC 2616). A “RESTful“ web service is one that is implemented using HTTP and the principles of REST. One of the differences between SOAP and REST is that SOAP is a specification while REST is a set of architectural principles.
The REST architecture is a collection of resources, with three defined aspects:
- The service uses verbs which are defined by HTTP methods like DELETE, GET, POST, and PUT
- These verbs are used to act upon resources
- The resources are addressed with URLs
A RESTful architecture is typically defined as one that is, or includes, the following:
- Client-server model
- Layered system
- Uniform interface
- Code on demand (optional)
Typical Use Cases
Here are some specific situations in which RESTful interfaces are particularly useful.
Component manageability – When it comes to visibility and security, there are many components that need to operate in a synchronized manner. REST allows a network management system (NMS), orchestration system, or security information and event management (SIEM) to communicate with these components and direct them. For instance, a SIEM could request a network packet broker (NPB) to activate a filter that captures specific data packets and routes those packets to a security tool for inspection.
The following are some things to keep in mind about using RESTful interfaces:
Understand your use case for REST – Use cases for NPBs, NMS, SIEM, orchestration systems, security tools, and network monitoring tools can all be different. You need to understand which components need to interface with each other and how those connected devices will behave using REST.
Make sure the vendor has tested interoperability – While many vendors will claim to support REST, and they probably do in some fashion, make sure you test the interface before you buy. You don’t want to find out that some function you need is non-standard. This is especially true if you are interfacing different components to management systems or other components. With different types of systems (like the NMS, SIEM, and orchestration systems mentioned earlier), this could be an important activity to conduct. For instance, Ixia did specific testing with vendors like Splunk to validate that the interface to the Ixia network packet broker works correctly and that Splunk creates the correct types of reports.
More Information on REST APIs
Further information about REST APIs can be found here. More information about Ixia network performance, network security and network visibility solutions and how they can help generate the insight needed for your business is available on the Ixia website.