HTTP Methods for RESTful Services (Part 1)

HTTP Methods -- one of the commonly asked interview topics for web developers.

What are they? Why do they exist? How are they useful for web development? If you are preparing for your tech interview, I hope this article will be helpful to you!

I am splitting this into two parts to avoid the article getting too lengthy as I would like to discuss some common interview questions as we continue our discussion!

Introduction

According to MDN,

HTTP defines a set of request methods to indicate the desired action to be performed for a given resource.

If you are familiar with full-stack, you probably know the CRUD operation, which stands for Create, Read/Retrieve, Update, Delete. The HTTP methods are closely associated with CRUD and are used to communicate with servers whenever there's data involved.

A common example where you will see these actions is when a platform involves users, like Twitter and Facebook. However, a lot of resources have used this as examples. Therefore, I would use recipes as example.

HTTP Methods	CRUD	What For?	Example Request URIs
GET	Read/Retrieve	Retrieve the recipes from our server	http://www.example.com/recipes or http://www.example.com/recipes/1
POST	Create	Create a new recipe that is sent from client side	http://www.example.com/recipes/new
PUT	Update/Replace	Update an existing recipe that is sent from client side	http://www.example.com/recipes/{:id}
PATCH	Update/Modify	Update an existing recipe partially that is sent from client side	http://www.example.com/recipes/{:id}
DELETE	Delete	Remove/Delete an existing recipe from the resource	http://www.example.com/recipes/{:id}

Let's break down each of them one by one!

---

GET

We use GET requests to retrieve information only -- not to modify the information in any way. Since the GET request does not modify anything, it is considered a "safe method". On top of that, GET APIs should be idempotent, which means making multiple identical requests must and will produce the same result.

---

✋🏻Sidebar✋🏻

Question 1️⃣ : What does "idempotent" mean?
Answer: Something Idempotent (or idempotence in noun form) in RESTful API standpoint means the client can make as many requests as they want and the fetch result will still be the same, i.e. the resource is not going to be modified just because someone make multiple calls. We will see this keyword again later in this article.

Question 2️⃣ : Why is GET method defined as "safe"?
Answer: A method is defined as "safe" when they are intended to retrieve data only, which makes the method idempotent in other words, since multiple identical requests will behave the same. HEAD, OPTIONS and TRACE in REST are also defined as "safe" methods. However, we will not cover these three methods in this article -- hopefully something I will cover in future articles!
My resource for the definition of idempotent and safe method (REST API tutorial)

---

(And continue)
Whenever we make any GET request, if the resource is found on the server, it must return HTTP response code 200 (OK) -- along with the response body, which is usually XML or JSON content. If the resource is not found, the server must return the infamous HTTP response code 404 (NOT FOUND). If the resource is determined that the GET request is incorrectly formed, the server will return 409 (BAD REQUEST).

Syntax

axios({
  method: 'get',
  url: 'https://geek-jokes.sameerkumar.website/api?format=json',
});

(This is a working API, here's the repo for this API!)

---

POST

We would use the POST method because we want to create a new (subordinate) resource into the collection of resources, e.g. adding a newly found recipe to our collection of recipe! When creating new resource, the server will automatically assign an ID (new resource URI) to this new resource.

If successfully created, the server will return the HTTP status code 201 (CREATED), returning a location header with a link to the newly-created resource with the 201 HTTP code. (like https://www.example.com/recipes/1)

POST methods are neither safe nor idempotent and invoking two identical POST requests will result in two different resources containing the same information.

Syntax

axios('/login', {
  firstName: 'Megan',
  lastName: 'Lo'
});

---

PUT

We use the PUT method primarily to update existing resource. If the resource does not exist, then the API may decide to create a resource or not. On a successful update, the server will return 200 (OK), or 204 (NO CONTENT). If PUT is used for creation and success, the server will return 201 (CREATED), like POST.

PUT is not a safe operation, since it modifies (or creates) states within the resource, however it is idempotent. If you create or update a resource with the same cal again, the resource is still there and has the same state as it did in the same call. (It is however not idempotent, if you are trying to increment a state.)

Syntax

const article = { title: 'React PUT Request Example' };
axios.put('https://reqres.in/api/articles/1', article)
  .then(response => this.setState({ updatedAt: response.data.updatedAt }));

(Code Example from here)

---

There you go! You learned what GET, POST, PUT are in this article. In the next article, I will like to dive into the difference between POST and PUT (common interview question). We will also discuss what PATCH and DELETE are.

Stay tuned and see you in the next article!!

---

Further Readings

What happens when you submit an article? (A Real-World Example Breakdown by Antony Garand published in dev.to)

Understanding and Using REST APIs (and My Resources)

• Using HTTP Methods for RESTful Services (REST API Tutorial)
• HTTP Methods (REST API Tutorial)
• Consuming REST APIs In React With Fetch And Axios (Smashing Magazine)
• Understanding And Using REST APIs (Smashing Magazine)
• How to make HTTP requests with Axios (LogRocket)

HTTP Response Codes

• 418 I'm a teapot (MDN -- some tech humor lol)
• HTTP STATUS DOGS (Super adorable dog pics with the corresponding HTTP codes)
• Classic, Shady, Funny : What is your Page’s HTTP Status Code? (Oncrawl)

Random and Fun

• A Curated List of 100 Cool and Fun Public APIs to Inspire Your Next Project (by Angelica Dietzel on Medium/Better Programming)