APIs allow programs to exchange data. Some APIs are for inter-program communications within a single operating system (OS). Other APIs are available to programs that run on other computers. These APIs must define the networking protocol. Many are based on REST.
REST is an architecture style for designing web service applications.
REST API: A REST API is an API that works on top of the HTTP protocol. It defines a set of functions developers can use to perform requests and receive responses through HTTP. The REST API (or RESTful API) is one of the Northbound APIs supported by NSO, and the client can operate NSO using HTTP(S). The REST API itself is used not only in NSO but also in other products, and because it is easy to call from Javascript, it is often used in web portals and so on.
The token is used to authenticate you to the restful API service. Restful API does not support authorization. An API can be considered RESTful if it has the following features.
1. Client/Server: The client handles the front end, and the server handles the back end. Either can be replaced independently of the other.
2. Stateless: No client data is stored on the server between requests. The session state is stored on the client.
3. Cacheable: Clients can cache responses to improve performance.
REST APIs and HTTP: The creators of REST-based APIs often choose HTTP because HTTP’s logic matches some of the concepts defined more generally for REST APIs. HTTP uses the same principles as REST it operates with a client/server model; it uses a stateless operational model; and it includes headers that clearly mark objects as cacheable or not cacheable. It also includes verbs - words that dictate the desired action for a pair HTTP Request and Reply – which matches how applications like to work.
Software CRUD Actions and HTTP Verbs
The software industry uses a memorable acronym - CRUD - for the four primary actions performed by an application. Those actions are
1. Create: Allows the client to create some new instances of variables and data structures at the server and initialize their values as kept at the server
2. Read: Allows the client to retrieve (read) the current value of variables that exist at the server, storing a copy of the variables, structures, and values at the client.
3. Update: Allows the client to change (update) the value of variables that exist at the server
4. Delete: Allows the client to delete from the server different instances of data variables
For instance, if using the northbound REST API of a DNA controller, “Cisco Software-Defined Access (SDA),” you might want to create something new, like a new security policy. From a programming perspective, the security policy exists as a related set of configuration settings on the DNA controller, internally represented by variables. To do that, a REST client application would use a create action, using the DNA Center RESTful API, that created variables on the DNA Controller via the DNA Center REST API. The concept of creating new configuration at the controller is performed via the API using a create action per the CRUD generic acronym. Other examples of CRUD actions include a check of the status of that new configuration (a read action), an update to change some specific setting in the new configuration (an update action), or an action to remove the security policy definition completely (a delete action).
HTTP uses verbs that mirror CRUD actions. HTTP defines the concept of an HTTP request and reply, with the client sending a request and with the server answering back with a reply. Each request/reply lists an action verb in the HTTP request header, which defines the HTTP action. The HTTP messages also include a URI, which identifies the resource being manipulated for this request. As always, the HTTP message is carried in IP and TCP, with headers and data, as represented in below fig.
