How To Test API CRUD Operations In Postman(The Better Way)

CRUD (Create, Read, Update and Delete) operations are the fundamentals of API’s.In this article, we will delve into the process of testing CRUD operations in Postman.

What is Rest

Representational state transfer known as Rest is an architecture style, that was created to guide the development of the APIs. It uses XML or JSON to send or receive data and transfer is over HTTP only.

CRUD operations:

CRUD stands for Create, Read, Update and Delete. These are four primitive database operations that map well to the HTTP verbs most frequently used in Rest Services.

• Create : (Post) Used to create a new resource, but can also modify the underlying state of a system.
• Read : (Get) This operation is used to retrieve a representation of the resource.
• Update : (Put/Patch) Update an existing resource.
• Deleted : (Delete) Delete or remove a resource.

Getting Started with Postman

Postman is a very popular API testing tool that provides a user-friendly interface for sending HTTP requests and analyzing responses. Download the Postman on your local or use the web-based version of the Postman tool for testing purposes.

I am using Spotify’s open-source API to demonstrate the CRUD operations. A complete set of APIs can be accessed from Here. To use these APIs we need to get a user ID and OAuth token. You can also use other publicly available API’s as per your choice.

Base URL: https://api.spotify.com/v1

This base URL will be common for all the operations and based on the different requirements additional params will be added. We will create an end-to-end test framework in Postman to test Rest services.

In the first step, we will create a Collection and save all the requests there.

What is the Postman collection?

Postman collections are a group of requests/API endpoints we can organize into folders. It is very useful in keeping the workspace organized. Other benefits of working with the collection are :

1. Saves time in transferring the requests as it is very easy to import or export a collection.
2. Setting any variable for collections will automatically apply the same to the folders generated under the collection.
3. it is very easy to pass the data between requests in the collection.
4. Data sharing is very convenient among APIs using collection variables.
5. Test written at the collection level will apply to all the requests inside the collection, no need to write common test cases again and again for different requests.
6. All requests can be executed at once using a collection runner.
7. Data-driven testing can be done using CSV or Excel files.
8. Continuous integration can be done easily with the help of collection and Newman.

How to Create a Collection?

• Launch Postman Application
• Click on New > Collection > Provide the name of the collection
• Click on the three dots in front of your collection > Add Request > Add URL and save the request.

As the collection has been created, we will now set up the authorization type as ‘Bearer Token’ at the collection level which will be used for every request in our collection (SpotifyTest).

Setup Spotify account to get Bearer Token:

Navigate to the Spotify developer console and Go to User Profile. Set up a user profile and get Bearer Token.

EndPoints to be used:

1. Get user ID: https://api.spotify.com/v1/me
2. Create a playlist : https://api.spotify.com/v1/users/{{user_id}}/playlists
3. Update a playlist description: https://api.spotify.com/v1/playlists/{playlist_id}
4. Remove items from a Playlist: https://api.spotify.com/v1/playlists/{playlist_id}/tracks

We can see that the base URL https://api.spotify.com/v1 is the same for every request. So let’s store it as a collection variable by clicking on the variable tab of collection and adding the variable key as “URL” and the initial value as “https://api.spotify.com/v1”.

Click on Save this variable. After successful saving, it is accessible for every API request inside our collection. We don’t need to write the base URL again and again even if we add a new request to the collection. If the base URL changes then it need not be updated in every request thus it is a time-saving and clean approach to maintain the integrity of the test framework.

In the next step replace the base URL of all the requests with the collection variable {{url}} and change the authorization type to ‘inherit auth from parent’. It means that the requests use the same auth that we’ve specified at the folder or the collection level.

Scenarios

Scenario_1: Fetch user-id (For testing the Read operation)

Endpoint : {{url}}/me

Method: Get

Verify that the response status code indicates success (e.g., 200 OK).

Response: JSON body that contains display name, followers, and a unique ID.

Scenario_2: Create a playlist (To test the Create operation)

Endpoint : {{url}}/users/{{user_id}}/playlists

Method: Post

Request body :

{
  "name": "Test Playlist",
  "description": "New playlist description",
  "public": true
}

Send the request and verify that the response status code indicates success (e.g., 201 Created).

Response body: JSON body containing unique playlist id.

We can either directly pass the user ID in the endpoint URL which we get from the previous request or we can set it as a global variable in the pre-request script.

A pre-request script is a piece of code that will run before the execution of the request. We have set the user ID as a global variable using the pre-request script so before calling the Post request it will set its value in the global environment and during execution will fetch the value from there.

Inside the Test tab set Playlist id as a global variable that will be used to update or delete a playlist in subsequent requests.

var jsonData = pm.response.json();
pm.globals.set("PlaylistId", jsonData.id);

Scenario_3: Update the already created playlist

Endpoint : {{url}}/playlists/{{playlist_id}}

Method: PUT

Request body:

{
  "name": "Updated Playlist Name",
  "description": "Updated playlist description",
  "public": false
}

Response: 200 OK and verify the response body to validate that changes have been applied.

Scenario_4: Delete a playlist

Endpoint : {{url}}/playlists/{{playlist_id}}/tracks 

Method: Delete

Response: 200 OK or 204

Ensure the deleted resource is no longer accessible through read(Get) requests.

These basic CRUD operations demonstrate the building blocks of a robust and dynamic collection framework that can be easily maintained and shared among the teams.

Collection Runner:

The collection runner allows running a set of requests in a specified sequence. It logs the test results and test scripts can pass data between requests.

To Run a collection, open a collection and click run on the overview tab, By default requests will run in the sequence they are listed in the collection but we can change the sequence by dragging and moving. Next, click the run button to execute it and you will see the test results in real time along with the request execution status and response time. Results can be filtered out based on the pass and fail status.

Share collection:

Collection run results can be shared by clicking on the share > Export tab so that other people can analyze them.

Conclusion

Testing CRUD operations in Postman is essential for verifying the functionality and reliability of the API’s. API testing ensures that API behaves as expected and handles data manipulation accurately.