Postman for API Testing: Workspace Setup and Core Request Building

1) Define a Target API and Base URL Conventions

To build reliable API tests in Postman, start by choosing a single target API and standardizing how you represent its base URL. This prevents “works on my machine” issues and makes it easy to switch between local, staging, and production later.

Choose a sample API for practice

For the hands-on exercises in this chapter, use the public JSONPlaceholder API:

• Base URL: https://jsonplaceholder.typicode.com
• Common resources: /posts, /posts/{id}, /users, /comments

Base URL conventions

Adopt conventions that keep requests consistent and readable:

• Always use HTTPS when available.
• Keep the base URL separate from the endpoint path in your mental model (and later, in environments).
• Use a consistent path style: plural nouns for collections (e.g., /posts), IDs for single resources (e.g., /posts/1).
• Document assumptions in request descriptions (e.g., “JSONPlaceholder returns fake data; POST/PUT simulate writes”).

Workspace structure (clean and test-focused)

Create a dedicated workspace for testing and keep artifacts organized so you can scale from a few requests to a full suite:

• Workspace: API Testing - Practice
• Collection: JSONPlaceholder - Core Requests
• Folders inside the collection:
  • 01 - Read (GET)
  • 02 - Create (POST)
  • 03 - Update (PUT/PATCH)
  • 04 - Delete (DELETE)
• Naming convention for requests: METHOD + space + endpoint + short intent (e.g., GET /posts - list posts)

2) Create Requests Using the Main HTTP Methods

In Postman, each request should clearly express: method, URL, parameters, headers, and (if applicable) body. Build requests one at a time and validate the response before moving on.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

Hands-on exercise set (build 6 requests)

Create these requests in your collection. For each, send it and compare expected vs actual behavior.

Request 1: GET list of posts

Goal: Retrieve a collection resource.

• Method: GET
• URL: https://jsonplaceholder.typicode.com/posts

Expected: Status 200; JSON array with many post objects.

Actual check: Confirm the response body is an array and each item has id, userId, title, body.

Request 2: GET a single post by ID

Goal: Retrieve a single resource.

• Method: GET
• URL: https://jsonplaceholder.typicode.com/posts/1

Expected: Status 200; JSON object with id = 1.

Actual check: Verify the id field equals 1 and fields are present.

Request 3: GET posts filtered with query parameters

Goal: Practice query parameters and confirm filtering behavior.

• Method: GET
• URL: https://jsonplaceholder.typicode.com/posts
• Query param: userId=1

Expected: Status 200; JSON array where every item has userId = 1.

Actual check: Confirm all returned items match the filter.

Request 4: POST create a new post (JSON body)

Goal: Create a resource using a JSON request body.

• Method: POST
• URL: https://jsonplaceholder.typicode.com/posts

Body: In Postman, choose Body > raw > JSON and paste:

{"title":"Postman request building","body":"Practicing POST with JSON body","userId":1}

Expected: Status 201; response echoes fields and includes an id (commonly 101 in JSONPlaceholder).

Actual check: Confirm Content-Type is JSON and the response contains title/body/userId matching what you sent.

Request 5: PUT update a post (full update)

Goal: Replace/update a resource representation.

• Method: PUT
• URL: https://jsonplaceholder.typicode.com/posts/1

Body (raw JSON):

{"id":1,"title":"Updated title","body":"Updated body","userId":1}

Expected: Status 200; response contains id = 1 and updated fields.

Actual check: Confirm the response body reflects your submitted values.

Request 6: DELETE a post

Goal: Delete a resource.

• Method: DELETE
• URL: https://jsonplaceholder.typicode.com/posts/1

Expected: Status 200 (JSONPlaceholder typically returns an empty object).

Actual check: Confirm the status code and that the body is empty or {}.

3) Configure Headers, Query Parameters, and Request Bodies

Consistent request configuration reduces ambiguity and makes debugging faster. In Postman, you’ll mainly use the Params, Headers, and Body tabs.

Headers: what to set and why

Headers describe how the server should interpret your request and what you accept back. Common testing habits:

• Accept: application/json (what you want back)
• Content-Type: application/json (what you are sending, for JSON bodies)
• Authorization: Bearer <token> (for authenticated APIs; not needed for JSONPlaceholder)

In Postman, when you choose Body > raw > JSON, Postman usually sets Content-Type: application/json automatically. Still, verify it in the Headers tab so you build the habit of checking what is actually sent.

Query parameters: use the Params tab

Instead of manually typing ?userId=1 into the URL, use Params so Postman URL-encodes values correctly and keeps the request readable.

• Open the request
• Go to Params
• Add key userId with value 1
• Confirm the URL updates automatically

Request bodies: JSON vs form-encoded

APIs commonly accept JSON, but some endpoints (especially auth/token endpoints) accept form-encoded data. Practice both formats so you can recognize and configure them quickly.

JSON body (raw)

Use for most REST APIs:

• Body > raw > JSON
• Ensure Content-Type is application/json

Example JSON body:

{"name":"Alice","role":"tester"}

Form-encoded body (x-www-form-urlencoded)

Use when the server expects key/value pairs:

• Body > x-www-form-urlencoded
• Postman sets Content-Type: application/x-www-form-urlencoded
• Add keys/values in the table UI

Example form fields:

username=tester@example.com&password=secret

Even if your practice API doesn’t require form-encoded bodies, knowing where to configure them in Postman is essential for real-world APIs (login, token exchange, legacy endpoints).

4) Read and Validate Response Components

After sending a request, validate the response systematically. This is the foundation for later automated checks and for quickly diagnosing failures.

Status code

Use status codes to confirm the high-level outcome:

• 200 OK: successful GET/PUT/PATCH/DELETE (varies by API)
• 201 Created: successful POST creating a resource
• 400 Bad Request: validation or malformed request
• 401/403: auth/permission issues
• 404: resource not found
• 500: server error

In your exercises, compare expected vs actual status codes. If they differ, inspect headers and body for error details.

Headers

Open the Headers section in the response to validate:

• Content-Type matches what you expect (e.g., application/json; charset=utf-8)
• Caching headers if relevant (Cache-Control, ETag)
• Server behavior hints (rate-limit headers, request IDs) when present

Body

Use the response body to validate data shape and key fields:

• Is it an object or array as expected?
• Are required fields present?
• Do IDs and echoed fields match what you sent?
• Are error messages informative when a request fails?

For JSON responses, use the Pretty view to inspect structure and the Raw view to see the exact payload.

Timing and size

Postman shows response time and size near the response panel. For functional testing, timing is a signal:

• Sudden spikes can indicate network issues, server load, or inefficient endpoints.
• Very small responses when you expect large payloads can indicate filtering, pagination, or errors.

Exercise: expected vs actual checklist

For each of the 6 requests you built, record:

• Expected status code vs actual
• Expected Content-Type vs actual
• Expected body shape (array/object) vs actual
• One key field validation (e.g., id=1, userId=1, title matches)
• Response time (note anything unusually slow)

5) Save Requests with Clear Naming, Descriptions, and Documentation Fields

Well-documented requests are easier to review, reuse, and test as a team. Treat each request as a test asset, not a one-off experiment.

Naming rules that scale

• Start with the HTTP method: GET, POST, PUT, PATCH, DELETE
• Include the endpoint path: /posts, /posts/:id
• Add a short intent: “list posts”, “create post”, “update post 1”

Examples:

• GET /posts - list posts
• GET /posts/:id - get post by id
• GET /posts - filter by userId
• POST /posts - create post
• PUT /posts/:id - replace post
• DELETE /posts/:id - delete post

Descriptions: what to write

In the request’s description/documentation area, capture the information someone needs to understand and validate it quickly:

• Purpose: what the request verifies
• Inputs: required params, headers, body fields
• Expected results: status code and key response fields
• Notes: special behavior (e.g., “JSONPlaceholder simulates create; data not persisted”)

Exercise: document one request fully

Pick your POST /posts - create post request and add a description like:

Purpose: Create a new post resource. Inputs: Body JSON requires title, body, userId. Headers: Content-Type application/json, Accept application/json. Expected: 201 Created; response contains title/body/userId matching request and includes an id. Notes: JSONPlaceholder simulates creation; resource is not persisted.