An Introduction to REST
WHAT IS REST API?
An API stands for Application Programming Interface. It defines a set of rules used to communicate with different programs. APIs can be private, partnered, or even public. Lets us expand this concept for REST API. REST is one of the ways through which you send the data over HTTP. It is an architectural style and methodology that has its own set of constraints and practices.
REST API stands for Representational State Transfer Application Programming Interface. For example, we request against a public API, WorldTimeAPI. The API gets our request, checks if there is anything wrong with it, and sends back the response. The response here is a time object and is as follows.
For a specific time zone, the API returns the state of that time zone, its time, location, abbreviation, etc. This response or ‘state-representation’ can be in JSON, HTML or XML format. Numerous other public APIs are available over the internet. I suggest you try similar other ones to be more comfortable with the concept in the general.
REST is usually preferred over other similar technologies. This is because REST uses less bandwidth which ultimately makes it more useful for Internet usage. You can create REST APIs using programming languages such as Python, JavaScript, etc.
Six Constraints of REST
Client Server Architecture → There needs to be a clear separation between the client and server. Request gathering and UI is managed by the client while data storage concerns are confined within the server. This enables them to be developed and enhanced independently.
Statelessness → Any state management that is required should be done on the client side, not the server.
Resource Caching → Resources should be allowed caching unless explicitly defined otherwise.
Layered system → The client shouldn’t be aware of it being connected to either the server or a CDN or mirror.
Code on demand → It is possible for the server to send executable code to the client.
Uniform Interface → Resources exposed may be uniquely identifiable through a single URL. Moreover, only the underlying methods of the network protocol, GET, and DELETE with HTTP can the resource be manipulated.
How does a REST API work?
A REST request is made up of an HTTP method, header, body, and endpoint.
HTTP methods identify the type of request sent to the server. The types include:
- GET requests data from a specified resource
- POST creates a new resource
- PUT updates or replaces resource
- PATCH applies partial modification to a resource
- DELETE removes or deletes the specified resource
*alongside the types mentioned above, customs types can be made as well
The header is used for authentication, caching, sending data, and more.
The body contains the information the client sends to the server, also referred to as the payload.
An endpoint is a URI (Uniform Resource Identifier) that helps in identifying the resource.
Working with REST API
We can use *https://jsonplaceholder.typicode.com/* for working with REST APIs. It comes with a set of resources. Some of the URI for testing are included below.
For demonstration, here the free Postman app is being used to send the request to the user.
To ‘get’ a specific post you can initiate an HTTP GET request against the URI ‘*https://jsonplaceholder.typicode.com/todos/1*’. The ‘1’ represents the id for the todo that you are requesting. The expected response is a single todo object whose id is ‘1’.
Let us now perform an HTTP POST request. The URI used is ‘*https://jsonplaceholder.typicode.com/todos*’. The request method is set for the POST. Since it is a POST request we have to add the payload to the request. Payload refers to the information the server might need for processing the API request. Since we want to create a new ‘todo’, we send the request with the ‘todo’ object, which contains the title and completion status. The server checks the object attributes and if everything checks in, this is what you should receive as a response.
Similar to the ‘GET’ and ‘POST’ requests simulated above, you can explore other HTTP methods in a similar fashion.
API Parameters
These refer to the options that are sent alongside the endpoint to modularize the response. For GET requests, they are found at the end of the API URL path while for POST requests, they are in the request body.
*here the content after .com is referred to as the parameter(s)
They work as your search filters and for the value of the parameters they give you a different response. We can append multiple parameters together using ‘&’. The example below uses the ‘name’ parameter from the URL and sends back the response containing it.
Note in both ‘GET’ and ‘POST’ requests, we receive a status code. On properly created REST APIs, we get accurate status codes that represent the status of the request. The status codes can co-relate with the response type and you can get a general idea in case something goes wrong as well. In our examples, we got a 200 status code for the GET request and a 201 status code for the following POST request. it means everything worked fine. You can compare the status codes from the image attached below to know more about what they mean.
Where to go from here?
Now that you have a basic understanding of how API, REST API works. I suggest you read more about the request-response cycle of the web. There are multiple types of APIs, the one used above is a public API, which means to access it, we don’t need an authentication token. Other private APIs may need tokens in order to access them. You can look into different types of authentication for this. Finally experiment with multiple APIs, perform different requests and check how they differ in their response.