Table of contents
1.
Introduction
2.
Get Request
3.
POST request
4.
PUT request
5.
DELETE request
6.
Frequently asked questions:
7.
Key takeaways
Last Updated: Mar 27, 2024

Handling requests in RESTFul API - Get, Put, Delete | Part 2

Career growth poll
Do you think IIT Guwahati certified course can help you in your career?

Introduction

In architectural design, there are two main viewpoints. The first is starting with a blank slate and constructing an architecture out of standard components until it meets the system's requirements. The second is starting with the system's demands, with no limitations, and then incrementally identifying and applying constraints to system elements, allowing the forces that impact system behaviour to flow naturally. 

 

The first promotes unconstrained vision and creativity, while the second emphasises the system environment's restraint and knowledge. The latter method was used to create REST.

 

REST is an acronym for REpresentational State Transfer, and this is an architectural style for distributed hypermedia systems. A RESTFul API is an application programming interface that adheres to the REST architectural style's constraints and allows interaction with RESTful web services. 

 

RESTFul APIs allow you to design any online application that supports all CRUD (create, retrieve, update, and delete) actions. In this article, we'll be seeing how to handle requests in RESTFul APIs.

Get Request

GET queries are used to get resource representations or information only, not to modify it. GET requests are believed to be safe because they do not modify the state of the resource.

 

Furthermore, GET APIs should be idempotent, which implies that repeating identical searches should always return the same response unless another API (POST or PUT) alters the status of the server resource.

 

If the data-producing process is being referred to by Request-URI, the produced data, not the process's source text, should be returned as the entity in the response unless that text is the process's output.

 

  • If the resource is on the server, the HTTP GET API must return HTTP response code 200 (OK) and the response body, commonly XML or JSON content (due to their platform-independent nature).

 

  • If the resource is not on the server, it must return the HTTP response code  404 (NOT FOUND).

 

  • Similarly, if the server determines that the GET request is not correctly structured, it will return HTTP response code 400. (BAD REQUEST).

 

For example:

app.get("/", function(req,res){
  res.render("home");
});

POST request

The POST requests are used to build new subordinate resources. A file, for example, is subordinate to the directory in which it resides and a record to a database table. When speaking strictly in terms of REST, POST methods add a new resource to the collection of resources.

 

Suppose a resource has been generated on the origin server. In that case, the response SHOULD include an entity that explains the request's status and references to the new resource and a Location header.

 

Often, the POST method's operation does not result in a resource that a URI can identify. In that case, the proper response status is either HTTP response code 200 (OK) or 204 (No Content).

 

This method's responses are cacheable only if the responses include the necessary Cache-Control or Expires header fields.

 

If we send two identical POST requests, it will result in two separate resources containing the same data (except resource ids) because POST is not secure nor idempotent.

 

For example:

app.post("/register", function(req, res){
//.body ..//
});

 

PUT request

PUT requests are typically used to update an existing resource. In case a resource does not exist, then the API decides to create a new resource or not.

 

If the PUT request creates a new resource, the origin server MUST inform the user agent via HTTP response code 201 (Created). If an existing resource is updated successfully, then either the 200 (OK) or 204 (No Content) response codes SHOULD be returned to signify successful completion.

 

Entries are considered stale if the request is cached and the Request-URI specifies one or more currently cached entities. The PUT method's responses are not cacheable.

 

For example:

app.put('/', (req, res) => {
  res.send("PUT Request Called")
})

 

DELETE request

DELETE requests are used to delete resources, as the name implies (identified by the Request-URI).

 

If the response includes an entity specifying the status, the HTTP response code should be 200 (OK), 202 (Accepted) if the action has been queued, or 204 (No Content) if the action has been done, but the answer does not include an entity.

 

The DELETE command is idempotent. A resource is no longer a part of the collection when we DELETE a resource. 

 

Repeatedly using the DELETE API request on that resource will have no effect. However, using DELETE on that resource for a second time will result in a 404 (NOT FOUND) error because the resource has already been removed.

 

If the request is cached and the Request-URI specifies one or more currently cached entities, those entries SHOULD be considered stale. This method's responses are not cacheable.

 

For example:

app.delete('/', (req, res) => {
  res.send("DELETE Request Called")
})

 

Frequently asked questions:

1). Explain what is REST and RESTFUL API?

Answer: REST stands for REpresentational State Transfer, and it's a new way of designing web APIs. RESTful APIs are web services created using the REST architectural concept, which focuses on system resources and how those resources are communicated across HTTP protocol to various clients written in multiple languages. 


HTTP methods such as GET, POST, PUT, and DELETE are used to conduct CRUD tasks in a RESTFUL web service, 


2). Mention whether you can use GET requests instead of PUT to create a resource?

Answer: No, PUT isn't designed to be used for GET. GET operations should only have read access, whereas PUT operations are intended to update data.


3). What are resources in a REST architecture?

Answer: REST architecture treats every content as a resource. These resources can be Text Files, Html Pages, Images, Videos or Dynamic Business Data.

Key takeaways

RESTful Web Services are Web Services that are built on the REST Architecture. RESTful web services are often used to construct APIs for web-based applications because they are lightweight, scalable, and maintainable. 

 

In this article, we've seen some of the fundamentals of RESTful API, like handling requests. You can refer to Part 1 of this series to know more about RESTFul APIs.

 

Happy Learning!

Live masterclass