Are you having the automation, programmability, ACI, SDN conversation and hearing the words API and REST being thrown around? Ever wondered what they are and why they are so relevant in the Data Centre? Well (hopefully) to fix that, this post is a brief introduction to what is becoming a very relevant subject.
Firstly let’s look at the API or Application Programming Interface.
Consider the diagram below, where we are looking at the more common Web API. Here the client-side (think application inside your Web Browser) communicates by a set of HTTP request messages with the API that the server-side application (think the Web Page) presents.
Here the API provides the base building blocks of the service (functionality, definitions and implementations) that the application/service programmer can develop against in a standard and consistent way.
So what’s the value of using a Web API and what benefits does it deliver? Some of the below are often stated:
- Provides programmable interfaces to different application services being consumed by different consumers
- Delivers a consistent programmatic method for development teams to access resources
- Structured way of exposing reusable application services
- Supports a defined and open interface (beware of closed API’s!!)
We are seeing a significant proliferation of API’s across our customers, such as:
- Tesco offering users access to the grocery catalog with the ability to search for products by department/aisle/shelf categories
- Walgreens offers Balance Rewards API, Photo Prints API, Pharmacy Prescription Refill API, amongst others
- Cisco’s API Console allows partners and customers to easily integrate Cisco data services within their tools, systems and applications
All this looks really good, however without a standard way to name, structure and implement how we communicate and interact between these two independent systems things can get a little messy.
Here’s where REST comes to the party, delivering that uniform interface.
To give REST its full title we are talking about REpresentational State Transfer, although let’s stick with REST as the common term.
A service that is based on REST is called a RESTful service. REST is not dependent on any protocol, however a RESTful service uses HTTP as its communication protocol using common HTTP operations such as GET, POST, PUT, DELETE.
As in the below diagram the client sends a HTTP request to the server that is running a REST service, requesting resources. The server then responds with the status of that request, can it be fulfilled or not. This response (success or error) is in the format of a HTTP status code, for example ‘200 OK’.
Consider ACI where we utalise a RESTful API as the means to communicate with the APIC:
- Automation tooling (the client) sends a HTTP Request (POST) to the APIC requesting capability the fabric needs to deliver for an application/service requirement. “Can I have the following resources”
- The URL details the APIC’s IP Address and the resources required
- The instructions for how those resources will be modified/utilised (the payload) are describe in either XML or JSON (as the programmer prefers)
- The APIC (the server) responds with a HTTP status code, either success “Yes you can have the resources” or error explaining the reason why
| Transport | HTTP/HTTPS |
| Id of Resources | URL |
| Formatting | JSON, XML |
By working in this programmatic API driven way allows IT to significantly increase operational efficiencies, offer greater consistency, easier integration and increased automation whilst delivering against the Application/Service demands with Cloud like speed with Enterprise class assurance.
Authors
1 Comments