This topic explain how REST enables computer to computer communications. Start learning CCNA 200-301 for free right now!!
Note: Welcome: This topic is part of Module 14 of the Cisco CCNA 3 course, for a better follow up of the course you can go to the CCNA 3 section to guide you through an order.
Table of Contents
Video – REST
As you have just learned, REST is currently the most widely used API. This topic covers REST in more detail.
Click play in the video to learn about more about REST.
REST and RESTful API
Web browsers use HTTP or HTTPS to request (GET) a web page. If successfully requested (HTTP status code 200), web servers respond to GET requests with an HTML coded web page, as shown in the figure.
REST is an architectural style for designing web service applications. It refers to a style of web architecture that has many underlying characteristics and governs the behavior of clients and servers. Simply stated, 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 via HTTP protocol such as GET and POST.
Conforming to the constraints of the REST architecture is generally referred to as being “RESTful”. An API can be considered “RESTful” if it has the following features:
Client-Server – The client handles the front end and the server handles the back end. Either can be replaced independently of the other.
Stateless – No client data is stored on the server between requests. The session state is stored on the client.
Cacheable – Clients can cache responses to improve performance.
A RESTful web service is implemented using HTTP. It is a collection of resources with four defined aspects:
The data format supported by the web service. This is often JSON, YAML, or XML but could be any other data format that is a valid hypertext standard.
The set of operations supported by the web service using HTTP methods.
The API must be hypertext driven.
RESTful APIs use common HTTP methods including POST, GET, PUT, PATCH and DELETE. As shown in the following table, these correspond to RESTful operations: Create, Read, Update, and Delete (or CRUD).
In the figure, the HTTP request asks for JSON-formatted data. If the request is successfully constructed according to the API documentation, the server will respond with JSON data. This JSON data can be used by a client’s web application to display the data. For example, a smartphone mapping app show the location of San Jose, California.
URI, URN, and URL
Web resources and web services such as RESTful APIs are identified using a URI. A URI is a string of characters that identifies a specific network resource. As shown in the figure, a URI has two specializations:
Uniform Resource Name (URN) – identifies only the namespace of the resource (web page, document, image, etc.) without reference to the protocol.
Uniform Resource Locator (URL) – defines the network location of a specific resource on the network. HTTP or HTTPS URLs are typically used with web browsers. Other protocols such as FTP, SFTP, SSH, and others can use a URL. A URL using SFTP might look like: sftp://sftp.example.com.
These are the parts of a URI, as shown in the figure:
Protocol/scheme – HTTPS or other protocols such as FTP, SFTP, mailto, and NNTP
Hostname – www.example.com
Path and file name – /author/book.html
Fragment – #page155
Parts of a URI
Anatomy of a RESTful Request
In a RESTful Web service, a request made to a resource’s URI will elicit a response. The response will be a payload typically formatted in JSON, but could be HTML, XML, or some other format. The figure shows the URI for the MapQuest directions API. The API request is for directions from San Jose, California to Monterey, California.
Parts of an API Request
The figure shows part of the API response. In this example it is the MapQuest directions from San Jose to Monterey in JSON format.
Partial JSON Payload Received from an API Request
These are the different parts of the API request:
API Server – This is the URL for the server that answers REST requests. In this example it is the MapQuest API server.
Resources – Specifies the API that is being requested. In this example it is the MapQuest directions API.
Query – Specifies the data format and information the client is requesting from the API service. Queries can include:
Format – This is usually JSON but can be YAML or XML. In this example JSON is requested.
Key – The key is for authorization, if required. MapQuest requires a key for their directions API. In the above URI, you would need to replace “KEY” with a valid key to submit a valid request.
Parameters – Parameters are used to send information pertaining to the request. In this example, the query parameters include information about the directions that the API needs so it knows what directions to return: “from=San+Jose,Ca” and “to=Monterey,Ca”.
Many RESTful APIs, including public APIs, require a key. The key is used to identify the source of the request. Here are some reasons why an API provider may require a key:
To authenticate the source to make sure they are authorized to use the API.
To limit the number of people using the API.
To limit the number of requests per user.
To better capture and track the data being requested by users.
To gather information on the people using the API.
RESTful API Applications
Many web sites and applications use APIs to access information and provide service for their customers. For example, when using a travel service web site, the travel service uses the API of various airlines to provide the user with airline, hotel and other information.
Some RESTful API requests can be made by typing in the URI from within a web browser. The MapQuest directions API is an example of this. A RESTful API request can also be made in other ways.
Click each API application scenario below for more information.
Developers often maintain web sites that include information about the API, parameter information, and usage examples. These sites may also allow the user to perform the API request within the developer web page by entering in the parameters and other information. The following figure shows an example of the MapQuest Directions API web page.
Postman is an application for testing and using REST APIs. It is available as a browser app or a standalone install. It contains everything required for constructing and sending REST API requests, including entering query parameters and keys. Postman allows you to collect and save frequently used API calls in history, or as collections. Postman is an excellent tool for learning how to construct API requests, and for analyzing the data that is returned from an API. The following figure shows an example of using the MapQuest API with Postman.
APIs can also be called from within a Python program. This allows for possible automation, customization, and App integration of the API. The following figure shows an example of part of a Python program used to submit requests to the MapQuest API.
Using protocols such as NETCONF (NET CONFiguration) and RESTCONF, network operating systems are beginning to provide an alternative method for configuration, monitoring, and management. For example, the following output might be the opening response from a router after the user has established a NETCONF session at the command line. However, working at the command line is not automating the network. Instead, a network administrator can use Python scripts or other automation tools, like Cisco DNA Center, to programmatically interact with the router.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.