Postman Basics for Beginners

Common HTTP Methods:

GET     → read data (safe, no side effects)
POST    → create data
PUT     → replace data entirely
PATCH   → update part of the data
DELETE  → remove data

Every request consists of:
- Method (GET, POST, etc.)
- URL (e.g. https://api.example.com/users)
- Headers (metadata: auth, content type)
- Body (for POST / PUT / PATCH)
- Query params (?key=value)

Example:
POST https://api.example.com/users
Headers:
  Content-Type: application/json
  Authorization: Bearer 
Body:
  {
    "name": "Aarav",
    "email": "aarav@example.com"
  }

HTTP Status Codes (most important ones):

2xx — Success
200 OK         → request succeeded
201 Created    → new item created
204 No Content → succeeded, empty response

3xx — Redirect
301 Moved Permanently
302 Found (temporary)

4xx — Client error (your fault)
400 Bad Request       → invalid input
401 Unauthorized      → no auth
403 Forbidden         → authenticated but blocked
404 Not Found         → resource missing
422 Unprocessable     → validation failed

5xx — Server error (their fault)
500 Internal Server Error
503 Service Unavailable

Rule of thumb:
2xx → Good
4xx → Fix the request
5xx → Report the bug

In Postman:
- Green pill in the response panel = 2xx
- Red pill = 4xx or 5xx

Your first GET request (5 steps):

1. Open Postman → click "New" → "HTTP Request"
2. Method: GET (default)
3. URL: https://jsonplaceholder.typicode.com/users
4. Click Send
5. Look at the response panel:
   - Status: 200 OK
   - Time: 320 ms
   - Body: JSON list of users

What you just did:
- Sent a GET request to a real API
- Received a JSON response

Practice exercise:
- Change the URL to .../users/1
- Run again
- Notice: you get a single user object instead of a list

Great test APIs to practice on:
- https://jsonplaceholder.typicode.com
- https://reqres.in
- https://httpbin.org

Your first POST request:

1. New request → set method to POST
2. URL: https://jsonplaceholder.typicode.com/posts
3. Open the "Body" tab
4. Select "raw" + "JSON"
5. Paste:
   {
     "title": "My first post",
     "body": "Testing Postman",
     "userId": 1
   }
6. Click Send

Expected response:
Status: 201 Created

{
  "id": 101,
  "title": "My first post",
  "body": "Testing Postman",
  "userId": 1
}

What you just did:
- Sent data to an API (POST)
- Received a 201 Created with the new resource

Common beginner mistakes:
- Forgetting Content-Type: application/json
- Sending form-data when the API expects JSON
- Using GET when the API docs say POST

Tip:
Always read the API documentation before
sending a request. Half of all beginner
issues are just wrong endpoints or methods.

Create your first collection (2 minutes):

1. In Postman, click "Collections" on the left
2. Click "New Collection"
3. Name it "User API Tests"
4. Inside it, add folders:
   - Auth
   - Users
   - Posts
5. Drag your existing requests into folders

Why collections matter:
- Save requests so you don't retype them
- Share with your team
- Run entire folders as a test suite
- Export/import for version control

Real-world structure:
📁 My API Tests
  📁 Auth
    POST /login
    POST /refresh
  📁 Users
    GET /users
    GET /users/:id
    POST /users
  📁 Posts
    GET /posts
    POST /posts

Use variables (the beginner breakthrough):

Why?
- Base URL changes between dev, staging, prod
- Tokens expire and need to be updated
- Hardcoded values break easily

Steps:
1. Click "Environments" → "Create Environment"
2. Add variables:
   baseUrl   = https://jsonplaceholder.typicode.com
   token     = abc123

3. Click "Save"

4. In your requests, use:
   {{baseUrl}}/users
   {{baseUrl}}/posts/1

5. When you run the collection, Postman replaces
   {{baseUrl}} with the actual value.

Using variables in body:
   {
     "title": "Hello",
     "userId": 1,
     "token": "{{token}}"
   }

Automatically set variables from a response:
   Tests tab of a request:
   const data = pm.response.json();
   pm.environment.set("userId", data.id);

Now {{userId}} is available for the next request.
This is how you chain requests (login → use token).

Common Assertions (Tests tab):

// 1. Status code
pm.test("Status is 200", () => {
  pm.response.to.have.status(200);
});

// 2. Response time
pm.test("Response is fast", () => {
  pm.expect(pm.response.responseTime).to.be.below(500);
});

// 3. Body contains a value
pm.test("Contains success flag", () => {
  const data = pm.response.json();
  pm.expect(data.success).to.be.true;
});

// 4. Array length
pm.test("Returns 10 users", () => {
  const data = pm.response.json();
  pm.expect(data).to.have.lengthOf(10);
});

// 5. Field exists
pm.test("User has an id", () => {
  const data = pm.response.json();
  pm.expect(data).to.have.property("id");
});

// 6. Content type header
pm.test("Returns JSON", () => {
  pm.response.to.have.header("Content-Type");
});

Where to write them:
- Open the request
- Click the "Tests" tab
- Paste JS code
- Click "Send"
- Look at the "Test Results" tab

Green check = pass, red X = fail

Save variables from the response:

Scenario:
- POST /login returns { "token": "abc123" }
- You want to use that token in the next request

Tests tab of the login request:
const data = pm.response.json();
pm.environment.set("token", data.token);

Now in later requests:
Headers:
  Authorization: Bearer {{token}}

Why this matters:
- No manual copying tokens
- Whole collections run end-to-end
- CI tests behave like real users

Common pitfall:
- Forgetting the variable name in
  {{double braces}}
- Running the login request first
  (dependency!)

Pro tip:
- Also clear the token at the end of a run:
  pm.environment.unset("token");
  This prevents stale data in CI.

Chaining requests (real QA pattern):

Flow:
1. POST /login → returns token
2. GET /users → uses token
3. POST /posts → creates a post
4. GET /posts/:id → confirms creation

In Postman:
- Store the created post ID from step 3:
  pm.environment.set("postId", data.id);

- Use it in step 4:
  {{baseUrl}}/posts/{{postId}}

To run the whole flow automatically:
1. Click the collection name
2. Click "Run"
3. Choose "Run collection"
4. Postman runs every request in order
5. Assertions report pass/fail
6. Variables chain between requests

This is where QA testing starts to feel
like automation — a real user journey
tested in seconds.