HTTP Methods and RESTful APIs

It really is a peanut butter and jelly moment when we examine the HTTP methods (or verbs) and their compatibility with RESTful API calls. This article will explain this for you in detail.

The HTTP verbs (also known as methods) are compatible with REST (Representational State Transfer) API calls because they align with the principles of RESTful architecture and provide a standardized way to interact with resources over the web.

Here’s an explanation of how the main HTTP verbs map to REST API operations:

  1. GET: The GET method is used to retrieve a representation of a resource or a collection of resources. In RESTful APIs, GET requests are typically used for reading or retrieving data. For example, you can use GET to retrieve a specific user’s information or to fetch a list of products.
  2. POST: The POST method is used to submit data to the server to create a new resource. It is commonly used for creating or adding new data to the API. For instance, you can use POST to create a new user or to add a new item to a shopping cart.
  3. PUT: The PUT method is used to update or replace an existing resource with new data. It sends the entire representation of the resource to the server. PUT requests are often used for updating existing records. For example, you can use PUT to update a user’s details or to modify a specific item’s information.
  4. PATCH: The PATCH method is similar to PUT, but it is used for making partial updates to a resource instead of sending the entire representation. It allows you to modify specific fields or properties of a resource. PATCH requests are useful when you only need to update specific attributes of a resource without sending unnecessary data.
  5. DELETE: The DELETE method is used to remove a resource from the server. It instructs the server to delete the specified resource. DELETE requests are commonly used to remove user accounts, delete files, or delete entries from a database.

These HTTP verbs align with the core principles of REST, which emphasizes the use of uniform interfaces, stateless communication, and resource-based interactions.

By using the appropriate HTTP verb, RESTful APIs provide a consistent and standardized way to perform CRUD (Create, Read, Update, Delete) operations on resources over the web.

Open Authentication (OAuth)

OAuth is defined in RFC 6749. It was designed with HTTP in mind and permits a user to login to multiple web sites using a single user account credentials. A classic example is logging in to a corporate website using the credentials available in Facebook.

NOTE: There are two versions of OAuth (1.0 and 2.0) and these versions are not compatible. OAuth 2.0 is the current adopted standard.

OAuth defines four roles:

  • Resource owner – this is typically the end user, but it can be any system or computer
  • Resource server – the host of the secured accounts; the server responds to the client
  • Client – the application making a resource request
  • Authorization server – the server that issues access tokens to the client once identity is verified

There are two flows types with OAuth. There is a two-legged authentication style that does not feature a resource owner. This is the type of flow you will often find when APIs are in use. This post focuses on the DevNet Pro exam objective of the three-legged authentication style that does feature the resource owner.

Here are the steps we must know in this OAuth three-legged authentication process:

Step 1 – the resource owner sends a request to the OAuth client application

Step 2 – the client application sends the resource owner a “redirect” to the authorization server 

Step 3 – the resource owner connects directly with the authorization server and authenticates

Step 4 – the authorization server presents a form to the resource owner to grant access

Step 5 – the resource owner submits the form to allow access

Step 6 – the authorization server sends the client a redirection with the authorization grant code or an access token

Step 7 – the client application sends the authorization grant code, client ID, and the certificate to the authorization server 

Step 8 – the authorization server sends the client an access token and optionally a refresh token

Step 9 – the client sends the access token to the resource server to request protected resources

Step 10 – the client can now access the protected resources on the resource server