Part 3: Mastering CRUD Operations in Playwright API Testing

Introduction

In the previous chapter, you learned how to configure Playwright for API testing and send your first HTTP GET request.

Now it's time to build something closer to what you'll find in a real enterprise automation framework.

Every REST API revolves around four fundamental operations:

• Create
• Read
• Update
• Delete

These operations are commonly known as CRUD. Whether you're testing an e-commerce application, banking system, healthcare platform, or SaaS product, you'll spend most of your time automating these API operations.

By the end of this chapter, you'll know how to automate each CRUD operation using Playwright while following enterprise-level best practices.

Understanding CRUD Operations

CRUD represents the four basic operations performed on data.

| Operation | HTTP Method | Purpose                |
| --------- | ----------- | ---------------------- |
| Create    | POST        | Create a new resource  |
| Read      | GET         | Retrieve existing data |
| Update    | PUT / PATCH | Modify existing data   |
| Delete    | DELETE      | Remove data            |

Almost every REST API follows this design. Examples include customer management systems, employee portals, banking applications, inventory systems, social media platforms, and e-commerce websites.

Learning CRUD automation means you've already mastered most of REST API testing.

Test API Used in This Tutorial

To keep things simple, we'll use the public REST API:

https://jsonplaceholder.typicode.com

It provides realistic responses without requiring authentication, which makes it perfect for learning Playwright API automation. Later in this series, we'll work with authenticated enterprise APIs.

Project Structure

Our project now looks like this:

playwright-api-framework/

tests/
   posts.spec.ts

playwright.config.ts

package.json

We'll place all CRUD examples inside a single test file.

CREATE Request (POST)

A POST request creates a new resource. Create the following test.

import { test, expect } from "@playwright/test";

test("Create a new post", async ({ request }) => {

    const response = await request.post("/posts", {

        data: {

            title: "Playwright API Automation",

            body: "Enterprise Framework",

            userId: 1

        }

    });

    expect(response.status()).toBe(201);

    const post = await response.json();

    expect(post.title).toBe("Playwright API Automation");

    expect(post.userId).toBe(1);

});

Understanding the POST Request

The request body is passed using the data property.

data:{
   title:"Playwright API Automation"
}

Playwright automatically converts the JavaScript object into JSON before sending it to the server. No manual serialization is required.

READ Request (GET)

Let's retrieve a specific record.

test("Retrieve a single post", async ({ request }) => {

    const response = await request.get("/posts/1");

    expect(response.status()).toBe(200);

    const body = await response.json();

    expect(body.id).toBe(1);

    expect(body.userId).toBe(1);

});

This verifies the status code, that the resource exists, and the response data.

Retrieving Multiple Records

Fetching collections is equally simple.

test("Retrieve all posts", async ({ request }) => {

    const response = await request.get("/posts");

    expect(response.status()).toBe(200);

    const posts = await response.json();

    expect(Array.isArray(posts)).toBeTruthy();

    expect(posts.length).toBeGreaterThan(0);

});

Instead of validating every record, validate important business rules. Examples include ensuring the collection isn't empty, required fields exist, record count is correct, sorting order is valid, and there are no duplicate values.

UPDATE Request (PUT)

PUT replaces the entire resource.

test("Update a post", async ({ request }) => {

    const response = await request.put("/posts/1",{

        data:{

            id:1,

            title:"Updated Title",

            body:"Updated Body",

            userId:1

        }

    });

    expect(response.status()).toBe(200);

    const body=await response.json();

    expect(body.title).toBe("Updated Title");

});

PUT should generally include every field of the resource. Think of it as replacing the existing object with a brand-new version.

PATCH Request

PATCH updates only selected fields.

test("Patch a post", async ({ request }) => {

    const response = await request.patch("/posts/1",{

        data:{

            title:"Updated Using PATCH"

        }

    });

    expect(response.status()).toBe(200);

    const body=await response.json();

    expect(body.title).toBe("Updated Using PATCH");

});

Unlike PUT, PATCH sends only the fields you want to modify. Most enterprise APIs prefer PATCH for partial updates.

DELETE Request

Deleting data is straightforward.

test("Delete a post", async ({ request }) => {

    const response = await request.delete("/posts/1");

    expect(response.status()).toBe(200);

});

Some APIs return 200 OK, 202 Accepted, or 204 No Content. Always verify the API documentation before asserting the expected status code.

Complete CRUD Test Suite

A professional CRUD suite usually contains the following tests:

• Create Post
• Retrieve Single Post
• Retrieve All Posts
• Update Post
• Patch Post
• Delete Post

Keeping each operation in its own test improves readability and debugging.

Using test.describe()

Grouping related tests makes reports easier to understand.

test.describe("Posts API",()=>{

   test("Create...",async()=>{});

   test("Retrieve...",async()=>{});

   test("Update...",async()=>{});

   test("Delete...",async()=>{});

});

Your HTML report becomes much cleaner.

Using test.step()

Large API tests can become difficult to debug. Break them into logical steps.

test("Verify User Information",async({request})=>{

   await test.step("Retrieve User",async()=>{

      // API Call

   });

   await test.step("Validate Response",async()=>{

      // Assertions

   });

});

When a failure occurs, Playwright clearly shows which step failed.

Enterprise Best Practices

Keep Tests Independent

Never depend on another test. Avoid chains like Create User, then Update User, then Delete User. If Create fails, every remaining test also fails. Instead, every test should prepare its own data. Independent tests are more reliable and can run in parallel.

Validate Business Rules

Don't stop at expect(response.status()).toBe(200). Also validate IDs, names, status, dates, required fields, and business logic. The response body is just as important as the status code.

Use Meaningful Test Names

A descriptive test name makes reports much easier to read. Instead of test("POST"), prefer test("POST /users creates a new active customer").

Avoid Hardcoded Values

Instead of request.get("/users/1"), store reusable IDs inside test data files, environment files, or fixtures. This makes your framework easier to maintain.

Don't Repeat Request Logic

Instead of writing request.post(...) repeatedly across tests, create reusable API client classes. We'll build those later in this series.

Common Beginner Mistakes

Many engineers make these mistakes during their first API automation project:

• Verifying only status codes
• Writing dependent tests
• Hardcoding URLs
• Mixing multiple scenarios into one test
• Ignoring response body validation
• Using fixed wait times
• Repeating request logic across multiple files

Avoiding these habits early will save you hundreds of hours as your automation framework grows.

Interview Question

What is the difference between PUT and PATCH?

PUT replaces the complete resource and usually requires sending every field. PATCH updates only specific fields and sends only the properties that need modification. Most REST APIs use PATCH for partial updates because it's more efficient and reduces payload size.

Summary

Congratulations! You can now automate the complete CRUD lifecycle using Playwright.

In this chapter, you learned:

• Creating resources using POST
• Retrieving resources using GET
• Updating resources using PUT
• Partially updating resources using PATCH
• Deleting resources using DELETE
• Organizing CRUD tests
• Using test.describe() and test.step()
• Enterprise best practices
• Common mistakes to avoid

In the next chapter, we'll move beyond public APIs and learn how to authenticate with secure applications using Bearer Tokens, JWT Authentication, API Keys, OAuth, and reusable authentication fixtures—a critical skill for building enterprise-grade Playwright API automation frameworks.