Understanding Rest APIs

00:00 REST APIs and Web Services. Before getting into the details of APIs and web services, it’s time to take a look at what REST means and its architecture. REST stands for Representational State Transfer and is a software architecture style that defines a pattern for client and server communications over a network.

00:19 REST provides a set of constraints for software architecture to promote performance, scalability, simplicity, and reliability in the system.

00:29 REST defines the following architectural constraints. Stateless: the server won’t maintain any state between requests from the client. Client-server: the client and server must be decoupled from each other, allowing each to develop independently. Cacheable: the data retrieved from the server should be cacheable either by the client or by the server. Uniform interface: the server will provide a uniform interface for accessing resources without defining their representation.

00:57 Layered system: the client may access the resources on the server indirectly through other layers, such as a proxy or load balancer. Code on demand: the server may transfer code to the client that it can run, such as JavaScript for a single-page application.

01:13 Note: REST is not a specification, but a set of guidelines on how to architect a network-connected software system.

01:22 A REST web service is any web service that adheres to REST architecture constraints. These web services expose their data to the outside world through an API.

01:31 REST APIs provide access to web service data through public web URLs. For example, on screen is one of the URLs for GitHub’s REST API. This URL allows you to access information about a specific GitHub user.

01:47 You access data from a REST API by sending an HTTP request to a specific URL and processing the response.

01:55 You can see a typical response on screen. Its appearance will depend on the browser you are using, and in this case, you’re seeing Firefox’s interpretation of the data that’s received.

02:06 REST APIs listen for HTTP methods, like GET, POST, and DELETE to know which operations to perform on the web service’s resources. A resource is any data available in the web service that can be accessed and manipulated with HTTP requests to the REST API.

02:23 The HTTP method tells the API which action to perform on the resource.

02:29 While there are many HTTP methods, the five methods seen on screen are the most commonly used with REST APIs. A REST API client application can use these five HTTP methods to manage the state of resources in the web service.

02:45 Once a REST API receives and processes an HTTP request, it will return an HTTP response. Included in this response is an HTTP status code. This code provides information about the results of the request. An application sending results to the API can check the status code and perform actions based on the result.

03:06 These actions could include handling errors or displaying a success message to the user.

03:12 Status codes are numbered based on the category of the result as you can see in the table on screen. In more detail, on screen you can see a list of the most common status codes returned by REST APIs.

03:25 These codes represent only a small subset of the available HTTP status codes.

03:32 Status codes come in handy when working with REST APIs, as you’ll often need to perform different logic based on the results of the request.

03:40 A REST API exposes a set of public URLs that the client applications use to access the resources of a web service. These URLs in the context of an API are called endpoints.

03:52 To clarify this, take a look at the table on screen. Here you’ll see API endpoints for a hypothetical CRM system. These endpoints are for a customer resource that represents potential customers in the system.

04:06 Each of the endpoints seen here performs a different action based on the HTTP method. Note that the base URL for the endpoints has been omitted for clarity.

04:15 In reality, you’ll need the full URL path to access an API endpoint. The base URL is everything besides customers.

04:25 You’ll note that some endpoints have <customer_id> at the end. This notation means you need to append a numeric customer_id to the URL to tell the REST API which customer you’d like to work with.

04:37 The endpoints listed in the table represent only one resource in the system. Production-ready REST APIs often have tens or even hundreds of different endpoints to manage the resources in the web service.

04:51 So now that you know what REST APIs are, next, you’ll take a look at how you can consume them with Python.