DEV Community

Aisalkyn Aidarova
Aisalkyn Aidarova

Posted on

API part #1

1. What is API Testing (Core Idea)

  • UI Testing (Frontend) → Testing what user sees (browser)
  • API Testing (Backend) → Testing logic behind the application
  • Database Testing → Testing stored data

Key Point:

  • UI = Presentation layer
  • API = Business logic layer
  • DB = Data layer

2. Types of Applications

There are 3 types:

  1. Desktop Applications
  • Runs locally (Excel, Notepad)
  • No internet required
  1. Web Applications
  • Browser-based
  • Uses client-server architecture
  1. Mobile Applications
  • Apps like WhatsApp, LinkedIn
  • Use APIs heavily

3. Client vs Server (Very Important)

Client

  • Sends request
  • Example: Browser, mobile app

Server

  • Receives request
  • Processes request
  • Sends response

Flow:

Client → Request → Server → Response → Client
Enter fullscreen mode Exit fullscreen mode

4. Architecture Types

1-Tier

  • Everything on one system
  • Example: Notepad

2-Tier

  • Client + Database
  • Example: Bank internal systems

3-Tier (Most Important)

  • Client (UI)
  • Application (API / logic)
  • Database

This is what modern apps use.


5. 3 Layers of Web Application

1. Presentation Layer

  • HTML, CSS, JavaScript
  • UI / browser

2. Application Layer

  • Business logic (APIs)
  • Written in Java, Python, .NET

3. Data Layer

  • Databases (MySQL, Postgres)

Important:
API sits between UI and DB.


6. What is an API (Interview Definition)

API = Application Programming Interface

Simple Definition:

  • A messenger between frontend and backend

Real Flow:

User → UI → API → Database → API → UI
Enter fullscreen mode Exit fullscreen mode

Example:

  • Login → API checks DB → returns success/fail

7. Why API Testing is Important

Old Approach:

  • 70% UI testing
  • 30% API testing

Modern Approach:

  • 70% API testing
  • 30% UI testing

Why?

  • APIs are ready before UI
  • Faster testing
  • More stable
  • Covers core logic

8. Real-Life API Example

Restaurant Analogy

Role Real System
Customer Client
Waiter API
Chef Server

Flow:

Customer → Waiter(API) → Chef(DB/logic) → Waiter → Customer
Enter fullscreen mode Exit fullscreen mode

9. Types of APIs

1. Public (Open APIs)

  • Available to everyone
  • Example: Google Maps API

2. Private APIs

  • Inside company only
  • Not accessible publicly

3. Partner APIs

  • Shared with partners
  • Example: Uber using Google Maps

4. Composite APIs

  • Combine multiple APIs into one request

10. API vs Web Service vs Microservice

API

  • Interface for communication

Web Service

  • API exposed on internet

Microservice

  • Small piece of functionality

Relationship:

Microservices → communicate via APIs → exposed as Web Services
Enter fullscreen mode Exit fullscreen mode

11. REST API (Most Important)

Modern systems use REST APIs (90%)

Why REST?

  • Fast
  • Lightweight (JSON)
  • Flexible

SOAP (Old)

  • Uses XML only
  • Heavy and slower

12. HTTP Methods (CRUD Operations)

Method Meaning
GET Read data
POST Create data
PUT Update data
PATCH Partial update
DELETE Remove data

13. Request vs Response

Request

  • What you send

Response

  • What you receive

Payload

  • Request payload → data you send
  • Response payload → data you receive

14. HTTP vs HTTPS

HTTP HTTPS
Not secure Secure
Plain text Encrypted

Always use HTTPS for sensitive data.


15. Status Codes (VERY IMPORTANT)

1xx → Processing

2xx → Success

3xx → Redirect

4xx → Client error

5xx → Server error

Examples:

  • 200 → OK
  • 404 → Not Found
  • 500 → Server Error

16. What You Validate in API Testing

When testing APIs, always validate:

  • Status Code
  • Response Body
  • Response Time
  • Headers
  • Data correctness

17. API Testing Flow

Client → Request → API → Server → DB → Response → Client
Enter fullscreen mode Exit fullscreen mode

18. Key DevOps Takeaways (Very Important for You)

For a 6+ year DevOps engineer, API knowledge is critical:

  • Debug microservices communication
  • Work with API Gateway, Lambda
  • Automate API testing in CI/CD
  • Troubleshoot distributed systems
  • Validate integrations (SNS, SQS, Kafka, etc.)

1. What is Postman

Postman = API Testing Tool

  • Used for manual API testing
  • Supports automation (basic) using JavaScript
  • Industry standard tool

Key capability:

  • Send request → Get response → Validate response

2. Why DevOps Engineers Must Know Postman

For you (DevOps perspective):

  • Debug microservices
  • Test APIs before deployment
  • Validate API Gateway / Lambda
  • Troubleshoot integrations (Kafka, SNS, SQS)
  • Use in CI/CD pipelines

3. Postman Types

1. Desktop App

  • Installed locally

2. Web Version

  • Runs in browser

Important:

  • Both use Postman Cloud
  • All data stored in cloud (collections, requests)

4. Postman Core Concepts (Very Important)

1. Workspace

  • Like a project environment

2. Collection

  • Group of requests
  • Like a folder or project module

3. Request

  • Actual API call

Structure:

Workspace → Collection → Request
Enter fullscreen mode Exit fullscreen mode

5. What is a Collection

Definition:

  • Collection = group of API requests

Inside collection:

  • Requests
  • Folders (optional)

Example:

Collection: User API
   ├── GET Users
   ├── POST User
   ├── PUT User
   └── DELETE User
Enter fullscreen mode Exit fullscreen mode

6. Types of Requests (Hands-on)

GET

  • Retrieve data

POST

  • Create data

PUT

  • Update full record

PATCH

  • Update partial record

DELETE

  • Remove data

7. Request vs Response (Postman View)

Request

  • URL
  • Method (GET/POST…)
  • Headers
  • Body (payload)

Response

  • Body (data)
  • Status Code
  • Headers
  • Response Time

8. Demo API Used

You used:

https://reqres.in
Enter fullscreen mode Exit fullscreen mode

This is a public testing API (very important for beginners).


9. GET Request Example

URL:

https://reqres.in/api/users?page=2
Enter fullscreen mode Exit fullscreen mode

Result:

  • Returns list of users
  • Status: 200

Important:

  • No payload required

10. POST Request Example

URL:

https://reqres.in/api/users
Enter fullscreen mode Exit fullscreen mode

Body (JSON):

{
  "name": "Aisalkyn",
  "job": "DevOps Engineer"
}
Enter fullscreen mode Exit fullscreen mode

Result:

  • Creates new user
  • Returns:

    • ID
    • Created timestamp

Status:

201 Created
Enter fullscreen mode Exit fullscreen mode

11. PUT Request Example

URL:

https://reqres.in/api/users/76
Enter fullscreen mode Exit fullscreen mode

Body:

{
  "name": "Aisalkyn",
  "job": "Senior DevOps Engineer"
}
Enter fullscreen mode Exit fullscreen mode

Result:

  • Updates record

Status:

200 OK
Enter fullscreen mode Exit fullscreen mode

12. DELETE Request Example

URL:

https://reqres.in/api/users/76
Enter fullscreen mode Exit fullscreen mode

Result:

  • Deletes record

Status:

204 No Content
Enter fullscreen mode Exit fullscreen mode

13. Query vs Path Parameters

Query Parameter

?page=2
Enter fullscreen mode Exit fullscreen mode
  • Used for filtering

Path Parameter

users/2
Enter fullscreen mode Exit fullscreen mode
  • Direct resource access

14. Request Payload vs Response Payload

Request Payload

  • Data you send
  • Example: JSON body

Response Payload

  • Data you receive

15. Where Payload is Used

Request Type Payload
GET Usually no
POST Yes
PUT Yes
DELETE No

16. Postman UI Important Sections

  • URL bar
  • Method dropdown
  • Body tab
  • Headers tab
  • Authorization tab
  • Response panel

17. Why NOT Use Browser for API Testing

Browser only shows:

  • Response data

But Postman shows:

  • Status code
  • Headers
  • Cookies
  • Response time
  • Full validation

18. Key DevOps Insight

In real projects:

  • APIs may require:

    • API keys
    • Tokens (JWT)
    • OAuth
  • You will test:

    • Security
    • Performance
    • Integration

19. Important Interview Points

Be ready to answer:

  • What is Postman?
  • Difference between PUT and PATCH
  • What is payload?
  • What is collection?
  • What is status code 200 / 201 / 204?
  • Difference between query vs path param

20. What You Should Practice Now

Do this before next step:

  1. Install Postman
  2. Create:
  • 1 Workspace
  • 1 Collection

    1. Add:
  • GET request

  • POST request

  • PUT request

  • DELETE request

    1. Test with reqres.in

1. Why DevOps Engineers Need This

This lecture is VERY IMPORTANT because:

  • You won’t always get real APIs
  • You must:

    • Mock APIs
    • Test locally
    • Validate responses
    • Debug pipelines

So this topic = real DevOps work


2. How to Create Your Own API (Local API)

Required Components

You need 3 things:

1. Node.js

  • Runtime to run JavaScript

2. npm (Node Package Manager)

  • Comes with Node.js

3. JSON Server

  • Tool to convert JSON → API

Installation Flow

Step 1 — Install Node.js

  • Download → install

Step 2 — Verify

node --version
npm --version
Enter fullscreen mode Exit fullscreen mode

Step 3 — Install JSON Server

npm install -g json-server
Enter fullscreen mode Exit fullscreen mode

3. Creating Your First API

Step 1 — Create JSON File

Example: students.json

{
  "students": [
    {
      "id": 1,
      "name": "John",
      "location": "India"
    },
    {
      "id": 2,
      "name": "Anna",
      "location": "USA"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Step 2 — Run API

json-server --watch students.json
Enter fullscreen mode Exit fullscreen mode

Output:

  • API runs on:
http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Step 3 — Available Endpoints

Action URL
Get all /students
Get one /students/1
Create POST /students
Update PUT /students/1
Delete DELETE /students/1

IMPORTANT

  • API runs only while terminal is open
  • Close terminal → API stops

4. Testing in Postman (Real DevOps Workflow)

GET Single

GET /students/1
Enter fullscreen mode Exit fullscreen mode

→ Returns one record


GET All

GET /students
Enter fullscreen mode Exit fullscreen mode

→ Returns list


POST (Create)

Body:

{
  "name": "Aisalkyn",
  "location": "USA"
}
Enter fullscreen mode Exit fullscreen mode

→ Status: 201 Created


PUT (Update)

PUT /students/4
Enter fullscreen mode Exit fullscreen mode

→ Replace data


DELETE

DELETE /students/4
Enter fullscreen mode Exit fullscreen mode

→ Status:

  • 200 OK
  • or 204 No Content

5. What DevOps Must Validate (CRITICAL)

When you send request → validate:

1. Status Code

  • 200 → OK
  • 201 → Created
  • 404 → Not Found

2. Response Time

  • Performance check

3. Response Size

  • Data correctness

4. Headers

  • Content-Type
  • Auth

5. Body (MOST IMPORTANT)

  • Data correctness

6. Cookies (if applicable)


6. What is JSON

Definition

JSON = JavaScript Object Notation

Used for:

  • Data exchange
  • API communication

Why JSON (DevOps reason)

  • Lightweight
  • Fast
  • Human-readable
  • Works with REST APIs

7. JSON Data Types (VERY IMPORTANT)

1. String

"name": "John"
Enter fullscreen mode Exit fullscreen mode

2. Number

"age": 30
Enter fullscreen mode Exit fullscreen mode

3. Boolean

"isActive": true
Enter fullscreen mode Exit fullscreen mode

4. Null

"value": null
Enter fullscreen mode Exit fullscreen mode

8. JSON Structures

1. Object

{
  "name": "John",
  "city": "NY"
}
Enter fullscreen mode Exit fullscreen mode

→ Key-value pairs


2. Array

"skills": ["Java", "Python"]
Enter fullscreen mode Exit fullscreen mode

→ Multiple values


3. Nested Object

"address": {
  "city": "NY",
  "zip": "10001"
}
Enter fullscreen mode Exit fullscreen mode

4. Array of Objects

"books": [
  { "title": "Java" },
  { "title": "Python" }
]
Enter fullscreen mode Exit fullscreen mode

9. JSON Path (VERY IMPORTANT FOR DEVOPS)

Why Needed?

Because:

  • You must extract data
  • Then validate it

Example JSON

{
  "store": {
    "book": [
      { "title": "Java" },
      { "title": "Python" }
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

JSON Path Basics

Root

$
Enter fullscreen mode Exit fullscreen mode

Access Field

$.store
Enter fullscreen mode Exit fullscreen mode

Access Array

$.store.book[0]
Enter fullscreen mode Exit fullscreen mode

Access Value

$.store.book[1].title
Enter fullscreen mode Exit fullscreen mode

→ Output: "Python"


Important Symbols

Symbol Meaning
$ Root
. Child
[] Array index
* All elements

10. Real DevOps Example

You get response:

{
  "name": "John",
  "location": "India"
}
Enter fullscreen mode Exit fullscreen mode

You validate:

pm.test("Check location", function () {
    pm.expect(pm.response.json().location).to.eql("India");
});
Enter fullscreen mode Exit fullscreen mode

11. Key Interview Questions

Be ready:

  • What is JSON?
  • Difference JSON vs XML?
  • What is JSON Path?
  • How to extract array value?
  • What is PUT vs PATCH?
  • What validations do you perform on API?

12. DevOps Real-World Mapping

You will use this in:

  • CI/CD pipelines
  • API Gateway testing
  • Lambda debugging
  • Microservices validation
  • Kafka / Event-driven systems
  • Terraform outputs validation

13. Most Important Takeaways

  • You can create your own API (no backend needed)
  • JSON = core of API communication
  • JSON Path = required for validation
  • Postman = testing tool
  • Validation = DevOps responsibility

After receiving API response → we must validate everything
using Postman + JavaScript + Chai assertions


2. Types of API Response Validations (DevOps Standard)

You MUST know these 6 categories (interview critical):

1. Status Code

2. Headers

3. Cookies

4. Response Time

5. Response Body

6. Schema Validation

This is exactly what senior DevOps / QA engineers do.


3. Where Do We Write Validations in Postman?

In Postman:

  • Pre-request script → runs BEFORE request
  • Post-response script → runs AFTER response (VALIDATIONS HERE)

So:

All validations = inside Post-response script


4. Core Syntax (VERY IMPORTANT)

Everything starts with:

pm.test("Test Name", () => {
   // validation
});
Enter fullscreen mode Exit fullscreen mode

Inside → we use:

pm.expect(...)
Enter fullscreen mode Exit fullscreen mode

This comes from Chai assertion library


5. Status Code Validation

Exact match

pm.test("Status is 200", () => {
    pm.response.to.have.status(200);
});
Enter fullscreen mode Exit fullscreen mode

Multiple possible status codes

pm.test("Status is valid", () => {
    pm.expect(pm.response.code).to.be.oneOf([200, 201, 202]);
});
Enter fullscreen mode Exit fullscreen mode

Status text

pm.test("Status text is OK", () => {
    pm.response.to.have.status("OK");
});
Enter fullscreen mode Exit fullscreen mode

6. Header Validation

Check header exists

pm.test("Content-Type exists", () => {
    pm.response.to.have.header("Content-Type");
});
Enter fullscreen mode Exit fullscreen mode

Validate header value

pm.test("Content-Type is JSON", () => {
    pm.expect(pm.response.headers.get("Content-Type"))
        .to.eql("application/json");
});
Enter fullscreen mode Exit fullscreen mode

Partial match (IMPORTANT)

pm.test("Content-Type contains JSON", () => {
    pm.expect(pm.response.headers.get("Content-Type"))
        .to.include("json");
});
Enter fullscreen mode Exit fullscreen mode

7. Cookies Validation

Cookie exists

pm.test("Language cookie exists", () => {
    pm.expect(pm.cookies.has("language")).to.be.true;
});
Enter fullscreen mode Exit fullscreen mode

Cookie value

pm.test("Language cookie value", () => {
    pm.expect(pm.cookies.get("language")).to.eql("en-GB");
});
Enter fullscreen mode Exit fullscreen mode

8. Response Time Validation

pm.test("Response time < 200ms", () => {
    pm.expect(pm.response.responseTime).to.be.below(200);
});
Enter fullscreen mode Exit fullscreen mode

IMPORTANT:

  • You NEVER check exact time
  • Always check threshold

9. Response Body Validation

Step 1 — Capture response

const jsonData = pm.response.json();
Enter fullscreen mode Exit fullscreen mode

Step 2 — Validate structure

pm.test("Response is object", () => {
    pm.expect(jsonData).to.be.an("object");
});
Enter fullscreen mode Exit fullscreen mode

Step 3 — Validate data types

pm.test("Data types", () => {
    pm.expect(jsonData.name).to.be.a("string");
    pm.expect(jsonData.id).to.be.a("number");
    pm.expect(jsonData.courses).to.be.an("array");
});
Enter fullscreen mode Exit fullscreen mode

Step 4 — Validate values

pm.test("Data validation", () => {
    pm.expect(jsonData.name).to.eql("John");
    pm.expect(jsonData.location).to.eql("India");
});
Enter fullscreen mode Exit fullscreen mode

10. Array Validation (VERY IMPORTANT)

Check value exists

pm.test("Course contains Java", () => {
    pm.expect(jsonData.courses).to.include("Java");
});
Enter fullscreen mode Exit fullscreen mode

Check multiple values

pm.test("Courses match", () => {
    pm.expect(jsonData.courses).to.have.members(["Java", "Selenium"]);
});
Enter fullscreen mode Exit fullscreen mode

11. Schema Validation (INTERVIEW FAVORITE)

What is Schema?

Schema = structure of data

Example:

Field Type
id number
name string
courses array

Why Important?

Instead of validating each field →
you validate entire structure at once


How it works

  1. Generate schema (tool)
  2. Compare response with schema

Example (TV4 library)

pm.test("Schema validation", () => {
    pm.expect(tv4.validate(jsonData, schema)).to.be.true;
});
Enter fullscreen mode Exit fullscreen mode

12. Real DevOps Flow

When API response comes → you validate:

1. Status → OK?
2. Headers → correct?
3. Time → fast enough?
4. Body → correct data?
5. Schema → structure valid?
Enter fullscreen mode Exit fullscreen mode

13. Interview Answer (IMPORTANT)

If they ask:

“What do you validate in API response?”

Answer:

I validate status codes, headers, cookies, response time, response body data, and schema. I also verify data types, values, and structure using JSON path and Postman scripts.


14. Most Important Takeaways

  • Postman uses JavaScript + Chai
  • All validations = pm.test()
  • Always validate:

    • Status
    • Headers
    • Time
    • Body
    • Schema
  • Use:

    • pm.response
    • pm.expect()
    • pm.response.json()
  • Variables = placeholders to store reusable data

  • Scripts = automation logic using JavaScript

  • Two script types:

    • Pre-request script → before API call
    • Post-response script → after API response

🧠 2. What is a Variable (DevOps Definition)

A variable is:

A container that stores data and can be reused across requests to avoid duplication and hardcoding


🚀 3. Why Variables Are CRITICAL in DevOps

You use variables for:

  • Base URLs (dev / QA / prod)
  • API keys / tokens
  • Dynamic IDs (userId, orderId)
  • Reusable test data

Example:

Instead of this:

https://api.dev.company.com/users
Enter fullscreen mode Exit fullscreen mode

You use:

{{base_url}}/users
Enter fullscreen mode Exit fullscreen mode

🧱 4. 5 Types of Variables (VERY IMPORTANT)

1. Global Variable

  • Scope: entire workspace
  • Use case: shared across all collections

2. Environment Variable

  • Scope: depends on selected environment (QA / DEV / PROD)
  • Must switch environment to use it

3. Collection Variable

  • Scope: inside one collection only

4. Local Variable

  • Scope: single request
  • Created using script only

5. Data Variable

  • From CSV / JSON (data-driven testing)

📊 5. Variable Hierarchy (INTERVIEW GOLD)

From lowest → highest:

Local < Collection < Environment < Global
Enter fullscreen mode Exit fullscreen mode

Meaning:

  • Local overrides everything
  • Global is accessible everywhere

⚙️ 6. How to Use Variables

Syntax (same for all types):

{{variable_name}}
Enter fullscreen mode Exit fullscreen mode

💻 7. Creating Variables Using JavaScript (REAL DEVOPS WAY)

🔹 Global Variable

pm.globals.set("user_id_global", "2");
Enter fullscreen mode Exit fullscreen mode

🔹 Environment Variable

pm.environment.set("user_id_env", "2");
Enter fullscreen mode Exit fullscreen mode

⚠️ Works only if environment is selected


🔹 Collection Variable

pm.collectionVariables.set("user_id_collection", "2");
Enter fullscreen mode Exit fullscreen mode

🔹 Local Variable

pm.variables.set("user_id_local", "2");
Enter fullscreen mode Exit fullscreen mode

🔁 8. Accessing Variables in Request

Example:

https://api.com/users/{{user_id_global}}
Enter fullscreen mode Exit fullscreen mode

🧩 9. Where Variables Are Created (IMPORTANT)

👉 Always in:

Pre-request Script

Why?

Because variables must exist BEFORE request is sent


🔥 10. Scripts in Postman

Two types:

1. Pre-request Script

  • Runs BEFORE request
  • Used for:

    • Creating variables
    • Generating tokens
    • Dynamic data

2. Post-response Script

  • Runs AFTER response
  • Used for:

    • Validations
    • Assertions
    • Cleanup (delete variables)

🧠 11. Execution Order (VERY IMPORTANT)

If scripts exist at:

  • Collection
  • Folder
  • Request

Execution order:

BEFORE request:

Collection → Folder → Request
Enter fullscreen mode Exit fullscreen mode

AFTER response:

Collection → Folder → Request
Enter fullscreen mode Exit fullscreen mode

🧹 12. Getting & Deleting Variables

Get value

pm.globals.get("user_id_global");
Enter fullscreen mode Exit fullscreen mode

Delete variable

pm.globals.unset("user_id_global");
Enter fullscreen mode Exit fullscreen mode

📦 13. Using Variables in Request Body

Example (POST API)

Pre-request:

pm.variables.set("name", "Aisalkyn");
pm.variables.set("job", "DevOps Engineer");
Enter fullscreen mode Exit fullscreen mode

Body:

{
  "name": "{{name}}",
  "job": "{{job}}"
}
Enter fullscreen mode Exit fullscreen mode

✅ 14. Validations (Post-response)

pm.test("Status code is 201", () => {
    pm.response.to.have.status(201);
});
Enter fullscreen mode Exit fullscreen mode

Validate Response Body

const jsonData = pm.response.json();

pm.test("Validate data", () => {
    pm.expect(jsonData.name).to.eql("Aisalkyn");
    pm.expect(jsonData.job).to.eql("DevOps Engineer");
});
Enter fullscreen mode Exit fullscreen mode

🔥 15. Real DevOps Scenario

Example flow:

  1. Login API → get token
  2. Save token in variable
  3. Use token in next API
// Post-response (login)
const res = pm.response.json();
pm.environment.set("token", res.token);
Enter fullscreen mode Exit fullscreen mode

🎯 16. Interview Questions (You MUST Know)

Q1: Where do you create variables?

👉 Pre-request script


Q2: Where do you validate responses?

👉 Post-response script


Q3: Difference between global and environment variable?

👉 Environment requires switching, global does not


Q4: Why use variables?

👉 Avoid hardcoding + reuse + dynamic data


Q5: What is execution order of scripts?

👉 Collection → Folder → Request


🧠 17. Most Important Takeaways

  • Variables = reusable dynamic data
  • Scripts = automation logic
  • Pre-request = create data
  • Post-response = validate + clean
  • Use JavaScript (not UI in real projects)
  • Always use {{variable}} syntax

🔥 1. What is API Chaining

Definition:

API chaining is executing multiple API requests in sequence where the output of one request becomes the input of another


🧠 2. Simple Real Flow (VERY IMPORTANT)

POST → GET → PUT → DELETE
Enter fullscreen mode Exit fullscreen mode

Step-by-step:

  1. POST → Create resource → returns id
  2. GET → Use id → fetch resource
  3. PUT → Use same id → update resource
  4. DELETE → Use same id → remove resource

📊 3. Why API Chaining is Critical for DevOps

You will use this in:

  • Microservices communication
  • CI/CD API validation
  • AWS Lambda workflows
  • Kafka event pipelines
  • Integration testing

⚙️ 4. Real Example (From Your Lecture)

Step 1 — Create User (POST)

Request:

{
  "name": "{{user_name}}",
  "email": "{{user_email}}",
  "gender": "male",
  "status": "active"
}
Enter fullscreen mode Exit fullscreen mode

Pre-request Script (Create dynamic data)

pm.collectionVariables.set("user_name", "abcxyz");

const text = Math.random().toString(36).substring(2);
const email = text + "@gmail.com";

pm.collectionVariables.set("user_email", email);
Enter fullscreen mode Exit fullscreen mode

Post-response Script (Capture ID)

const jsonData = pm.response.json();

pm.collectionVariables.set("user_id", jsonData.id);
Enter fullscreen mode Exit fullscreen mode

🔑 5. Authentication (VERY IMPORTANT)

You used Bearer Token

Where to add:

👉 Collection level (best practice)

Authorization → Bearer Token → paste token
Enter fullscreen mode Exit fullscreen mode

✔ Applies to all requests automatically


🔗 6. Step 2 — Get User (Using ID)

URL:

/users/{{user_id}}
Enter fullscreen mode Exit fullscreen mode

Post-response Validation

const jsonData = pm.response.json();

pm.test("Validate user data", () => {
    pm.expect(jsonData.id)
        .to.eql(pm.collectionVariables.get("user_id"));

    pm.expect(jsonData.name)
        .to.eql(pm.collectionVariables.get("user_name"));

    pm.expect(jsonData.email)
        .to.eql(pm.collectionVariables.get("user_email"));
});
Enter fullscreen mode Exit fullscreen mode

🔄 7. Step 3 — Update User (PUT)

Body:

{
  "name": "{{user_name}}",
  "email": "{{user_email}}",
  "status": "active"
}
Enter fullscreen mode Exit fullscreen mode

Pre-request (Generate NEW data)

const text = Math.random().toString(36).substring(2);

pm.collectionVariables.set("user_name", "updated_" + text);
pm.collectionVariables.set("user_email", text + "@gmail.com");
Enter fullscreen mode Exit fullscreen mode

Validation (same as GET)


🗑️ 8. Step 4 — Delete User

URL:

/users/{{user_id}}
Enter fullscreen mode Exit fullscreen mode

Post-response (Cleanup variables)

pm.collectionVariables.unset("user_name");
pm.collectionVariables.unset("user_email");
pm.collectionVariables.unset("user_id");
Enter fullscreen mode Exit fullscreen mode

🔁 9. Full Flow (IMPORTANT)

1. Create user → get ID
2. Store ID in variable
3. Use ID in next requests
4. Validate data
5. Update same resource
6. Delete resource
7. Clean variables
Enter fullscreen mode Exit fullscreen mode

🧠 10. Key DevOps Concepts Behind This

1. Dynamic Data Handling

  • No hardcoding
  • Always generate runtime data

2. State Management

  • Variables store state between APIs

3. Dependency Handling

  • Request depends on previous response

4. Automation Ready

  • Can run in CI/CD pipelines

⚠️ 11. Common Mistakes (Interview Trap)

❌ Using local variables (won’t work across requests)
✔ Use collection/environment variables

❌ Hardcoding IDs
✔ Always extract from response

❌ Not handling auth globally
✔ Add token at collection level


🎯 12. Interview Questions (MUST KNOW)

Q1: What is API chaining?

👉 Using response of one API as input for another


Q2: Where do you store ID?

👉 In collection/environment variable


Q3: Why not local variable?

👉 Scope is limited to one request


Q4: Where do you capture response?

👉 Post-response script


Q5: Where do you generate dynamic data?

👉 Pre-request script


🧠 13. Real DevOps Scenario

Example:

Login API → get JWT token
↓
Store token
↓
Call protected APIs using token
↓
Validate responses
Enter fullscreen mode Exit fullscreen mode

🔥 14. Most Important Takeaways

  • API chaining = sequence + dependency
  • Always use variables
  • Capture response → store → reuse
  • Pre-request = prepare data
  • Post-response = validate + store
  • Collection variables = best for chaining

🧠 2. Execution Order in Postman

Default Behavior

Requests run in the order they are created
Enter fullscreen mode Exit fullscreen mode

Problem

Sometimes you need custom flow:

Create Token → Submit Order → Get Order → Update → Delete
Enter fullscreen mode Exit fullscreen mode

NOT the default order.


⚙️ 3. How to Control Execution Order

Method:

pm.execution.setNextRequest("Request Name");
Enter fullscreen mode Exit fullscreen mode

Example Flow

Create Token → next = Submit Order

pm.execution.setNextRequest("Submit Order");
Enter fullscreen mode Exit fullscreen mode

Submit Order → next = Get Single Order

pm.execution.setNextRequest("Get Single Order");
Enter fullscreen mode Exit fullscreen mode

Last Request → STOP

pm.execution.setNextRequest(null);
Enter fullscreen mode Exit fullscreen mode

🔥 IMPORTANT

If you DON’T use null:

  • Postman may execute next request automatically
  • Especially if more requests exist

🧠 4. Why DevOps Engineers Use This

  • Control workflows
  • Build pipelines
  • Simulate real system behavior

Example:

Auth → Create Resource → Validate → Cleanup
Enter fullscreen mode Exit fullscreen mode

📊 5. Data-Driven Testing (VERY IMPORTANT)

Problem

You don’t want:

Run same API 5 times manually ❌
Enter fullscreen mode Exit fullscreen mode

Solution

Run 1 request with multiple data sets ✅
Enter fullscreen mode Exit fullscreen mode

📁 6. Supported Data Files

  • CSV
  • JSON

📄 7. Example CSV

bookId,customerName
1,John
2,Alice
3,Bob
4,Emma
5,David
Enter fullscreen mode Exit fullscreen mode

🧠 8. Key Rule (VERY IMPORTANT)

Column names MUST match variables:

{
  "bookId": "{{bookId}}",
  "customerName": "{{customerName}}"
}
Enter fullscreen mode Exit fullscreen mode

⚙️ 9. How It Works (NO CODE REQUIRED)

You DO NOT write JavaScript to read file.

Postman does it automatically.


🚀 10. Running Data-Driven Collection

Steps:

  1. Click Run Collection
  2. Set:

Iterations

= number of rows in file
Enter fullscreen mode Exit fullscreen mode

Delay

1–2 seconds (recommended)
Enter fullscreen mode Exit fullscreen mode

Select File

  • Upload CSV / JSON

📊 11. Example Execution

If:

  • 5 rows
  • 3 requests

Then:

Total executions = 5 × 3 = 15 requests
Enter fullscreen mode Exit fullscreen mode

📈 12. Validation Count Logic

Example:

  • Submit Order → 1 test
  • Get Order → 2 tests
  • Delete Order → 1 test

Total per iteration:

1 + 2 + 1 = 4 tests
Enter fullscreen mode Exit fullscreen mode

For 5 iterations:

4 × 5 = 20 tests
Enter fullscreen mode Exit fullscreen mode

🧠 13. DevOps-Level Understanding

What is happening internally:

Loop:
  Take row 1 → run all requests
  Take row 2 → run all requests
  ...
Enter fullscreen mode Exit fullscreen mode

🔄 14. Full Flow Example

Iteration 1:
  Submit Order → Get Order → Delete

Iteration 2:
  Submit Order → Get Order → Delete

...
Enter fullscreen mode Exit fullscreen mode

⚠️ 15. Common Mistakes

❌ Column name mismatch
✔ Must match exactly


❌ No delay → API failures
✔ Add delay


❌ Hardcoded data
✔ Use external files


❌ Forgetting token
✔ Add auth properly


🔐 16. Token Handling (Best Practice)

Instead of hardcoding:

Bearer {{access_token}}
Enter fullscreen mode Exit fullscreen mode

✔ Store once → reuse everywhere


🧠 17. Real DevOps Use Cases

This is used in:

1. CI/CD Pipelines

  • Run API tests with datasets

2. Load Simulation

  • Multiple users/orders

3. Integration Testing

  • Microservices validation

4. E-commerce Systems

  • Orders → payments → delivery

🎯 18. Interview Questions (VERY IMPORTANT)

Q1: What is data-driven testing?

👉 Running same API with multiple datasets


Q2: How does Postman read CSV?

👉 Automatically during collection run


Q3: Do you need scripting?

👉 No (only variable mapping)


Q4: What is iteration?

👉 Number of times collection runs


Q5: Why delay is important?

👉 Prevent API throttling / failures


Q6: How to control execution order?

👉 pm.execution.setNextRequest()


🔥 19. Most Important Takeaways

  • Execution order can be customized
  • Data-driven testing = real-world automation
  • No scripting needed for CSV/JSON
  • Variables must match column names
  • Iterations control execution count
  • Delay prevents failures

🔥 1. File Upload APIs (VERY IMPORTANT)

🧠 What Happens Internally

When you upload a file from UI:

UI → API → Server → Storage (disk/cloud)
Enter fullscreen mode Exit fullscreen mode

👉 API is doing the real work


📤 2. Single File Upload (Postman)

Request

POST /uploadFile
Enter fullscreen mode Exit fullscreen mode

Body (IMPORTANT)

👉 NOT JSON
👉 Use form-data

Key: file
Type: File
Value: choose file
Enter fullscreen mode Exit fullscreen mode

Response Example

{
  "fileName": "test.txt",
  "fileDownloadUri": "...",
  "fileType": "text/plain",
  "size": 770
}
Enter fullscreen mode Exit fullscreen mode

🔥 Key DevOps Point

  • File upload = multipart/form-data
  • Not JSON
  • Works for:

    • txt
    • csv
    • pdf
    • excel

📥 3. File Download

Request

GET /download/{filename}
Enter fullscreen mode Exit fullscreen mode

Response

  • Returns file content
  • Or triggers download (browser)

📤📤 4. Multiple File Upload

Request

POST /uploadMultipleFiles
Enter fullscreen mode Exit fullscreen mode

Body

Key: files
Type: File
Select multiple files
Enter fullscreen mode Exit fullscreen mode

Response

[
  { "fileName": "file1.txt" },
  { "fileName": "file2.txt" }
]
Enter fullscreen mode Exit fullscreen mode

⚠️ Common Mistakes

❌ Using JSON body
✔ Use form-data

❌ Wrong key name
✔ Must match API (file / files)


🔐 5. Authentication vs Authorization

Difference

Concept Meaning
Authentication Who are you
Authorization What you can access

🔥 6. Types of Authentication (MUST KNOW)

From your lecture, these are the main ones:


1️⃣ Basic Authentication

How it works

Client → username/password → Server → Response
Enter fullscreen mode Exit fullscreen mode

In Postman

Authorization → Basic Auth
Enter fullscreen mode Exit fullscreen mode

Key Points

  • Encoded (not secure)
  • Used in simple systems

2️⃣ Digest Authentication

Difference from Basic

  • Uses encryption
  • More secure

Flow

Client → encrypted credentials → Server
Enter fullscreen mode Exit fullscreen mode

DevOps Tip

👉 Rarely used in modern systems


3️⃣ API Key Authentication

Example: Weather API

Request

GET /weather?q=Chicago&appid=API_KEY
Enter fullscreen mode Exit fullscreen mode

In Postman

Authorization → API Key
Key: appid
Value: <your_key>
Add to: Query Params
Enter fullscreen mode Exit fullscreen mode

Flow

Client → API Key → Server → Response
Enter fullscreen mode Exit fullscreen mode

🔥 Real Use Cases

  • Weather APIs
  • Payment APIs
  • SaaS platforms

4️⃣ Bearer Token (VERY IMPORTANT)

Flow

Login → Get Token → Use Token in requests
Enter fullscreen mode Exit fullscreen mode

Example

Authorization: Bearer <token>
Enter fullscreen mode Exit fullscreen mode

Where used

  • GitHub API
  • AWS APIs
  • Microservices

DevOps Reality

👉 MOST COMMON in production


5️⃣ OAuth 2.0 (VERY IMPORTANT)

🔥 Key Concept

Requires 3 things:

1. Client ID
2. Client Secret
3. Access Token
Enter fullscreen mode Exit fullscreen mode

Flow

1. Login to app
2. Register app
3. Get client_id + client_secret
4. Generate token
5. Use token to call API
Enter fullscreen mode Exit fullscreen mode

In Postman

Authorization → OAuth 2.0 → Get New Access Token
Enter fullscreen mode Exit fullscreen mode

🔥 Real Systems Using OAuth2

  • Google APIs
  • Facebook
  • LinkedIn
  • PayPal

📊 7. Comparison (INTERVIEW GOLD)

Type Security Usage
Basic Low Legacy
Digest Medium Rare
API Key Medium Public APIs
Bearer Token High Microservices
OAuth 2.0 Very High Enterprise

🧠 8. DevOps Real-World Mapping

You will use:

CI/CD Pipelines

  • API key / token for deployments

Microservices

  • Bearer tokens between services

Cloud APIs

  • AWS / Azure → token-based auth

External Integrations

  • OAuth2 (Google, Slack, etc.)

🔥 9. Internal Flow Summary

Basic

Request → Username/Password → Response
Enter fullscreen mode Exit fullscreen mode

Token

Login → Token → Request → Response
Enter fullscreen mode Exit fullscreen mode

OAuth2

Login → Client ID/Secret → Token → API Call
Enter fullscreen mode Exit fullscreen mode

⚠️ 10. Interview Questions

Q1: Difference Basic vs Bearer?

👉 Basic uses credentials
👉 Bearer uses token


Q2: Why OAuth2?

👉 More secure, delegated access


Q3: Where is API key sent?

👉 Query params or headers


Q4: What is Bearer token?

👉 Access token used in Authorization header


Q5: File upload API content type?

👉 multipart/form-data


🚀 11. Most Important Takeaways

  • File upload = form-data
  • Authentication is critical in APIs
  • Bearer + OAuth2 = most important
  • API keys = common for external services
  • OAuth2 = enterprise-level security

🚀 FULL API PROJECT FLOW (REAL DEVOPS PROCESS)

This is NOT just Postman — this is how real companies work.


🧭 1. Where Do You Start?

👉 NOT Postman
👉 NOT automation

✅ You start from:

Technical Design Document
Enter fullscreen mode Exit fullscreen mode

Because:

  • You need to understand APIs first
  • You cannot test what you don’t understand

📄 2. Technical Document (VERY IMPORTANT)

From your file:

👉 It defines:

  • Endpoints
  • Request types
  • Data models
  • Functional requirements

🧠 Key Concept: Endpoint

Base URL + Endpoint = Full API URL
Enter fullscreen mode Exit fullscreen mode

Example:

https://api.store.com   → Base URL
/products               → Endpoint
Enter fullscreen mode Exit fullscreen mode

👉 Endpoint = resource (data you want)


🧱 3. Modules in Project

From your doc:

1. Product Module

  • Get products
  • Add product
  • Update product
  • Delete product

2. Cart Module

  • Add to cart
  • Get cart
  • Filter cart

3. User Module

  • Login
  • Get user
  • Create user

🔥 4. CRUD Mapping (INTERVIEW MUST)

Operation API Method
Create POST
Read GET
Update PUT / PATCH
Delete DELETE

📊 5. Data Model (VERY IMPORTANT)

Example:

{
  "id": 1,
  "title": "Product",
  "price": 100
}
Enter fullscreen mode Exit fullscreen mode

👉 Used for:

  • Validation
  • Schema testing

🧪 6. Test Case Design (CRITICAL SKILL)

From your doc, structure:


Template

Field Meaning
Test ID Unique
Description What to test
Method GET/POST
Endpoint API path
Auth Token/API key
Query Params limit, sort
Headers JSON, auth
Body POST data
Expected Response
Status Code 200/201
Validation Assertions

🔥 Example

Get All Products

Method: GET
Endpoint: /products
Expected: Array of products
Status: 200
Enter fullscreen mode Exit fullscreen mode

Add Product

POST /products
{
  "title": "...",
  "price": 100
}
Enter fullscreen mode Exit fullscreen mode

⚠️ IMPORTANT RULE (DEVOPS GOLD)

❌ NEVER hardcode values
✔ ALWAYS use variables
Enter fullscreen mode Exit fullscreen mode

🧠 7. Variables Strategy

Types

1. Global Variables

Used everywhere:

base_url
username
password
Enter fullscreen mode Exit fullscreen mode

2. Collection Variables

Used per module:

product_id
title
price
Enter fullscreen mode Exit fullscreen mode

📁 8. External Data (VERY IMPORTANT)

From your file:

👉 Data comes from:

  • JSON → single dataset
  • CSV → multiple datasets (data-driven)

Example JSON

{
  "id": 1,
  "title": "Phone",
  "price": 500
}
Enter fullscreen mode Exit fullscreen mode

Example CSV

id,title,price
1,Phone,500
2,Laptop,1000
Enter fullscreen mode Exit fullscreen mode

🔁 9. Data-Driven Testing

JSON → 1 iteration

CSV → multiple iterations

👉 Example:

12 requests × 2 rows = 24 executions
Enter fullscreen mode Exit fullscreen mode

🧪 10. Postman Collection Flow

Step-by-step

1. Create Workspace
2. Create Collection
3. Add Requests
4. Add Variables
5. Add Scripts (validation)
6. Run Collection
Enter fullscreen mode Exit fullscreen mode

🔥 11. Validations (MOST IMPORTANT)

From your doc:


Must-have validations

1. Status Code

pm.response.to.have.status(200);
Enter fullscreen mode Exit fullscreen mode

2. Response Not Empty

pm.expect(jsonData).to.not.be.empty;
Enter fullscreen mode Exit fullscreen mode

3. Schema Validation

pm.expect(jsonData).to.be.jsonSchema(schema);
Enter fullscreen mode Exit fullscreen mode

4. Business Logic Validation

Example:

pm.expect(jsonData.id).to.eql(expectedId);
Enter fullscreen mode Exit fullscreen mode

5. Array Length

pm.expect(jsonData.length).to.eql(20);
Enter fullscreen mode Exit fullscreen mode

🔥 12. Advanced Validation (VERY IMPORTANT)

From your lecture:

👉 Loop through response:

jsonData.forEach(item => {
    pm.expect(item).to.have.property("id");
});
Enter fullscreen mode Exit fullscreen mode

🚀 13. Running Collection

Manual Run

Run Collection → Select Data File → Run
Enter fullscreen mode Exit fullscreen mode

Results

  • Total tests
  • Passed
  • Failed
  • Execution time

📊 14. Output Example

Iterations: 2
Total tests: 100
Passed: 100
Failed: 0
Enter fullscreen mode Exit fullscreen mode

⚠️ 15. Important Behavior

If one request fails:

  • Independent → others continue
  • Dependent → chain fails

🔗 16. Dependency Example

POST product → PUT product → DELETE product
Enter fullscreen mode Exit fullscreen mode

👉 If POST fails → others fail


📦 17. Export & Sharing

You can export:

  • Collection
  • Results (JSON)

🔥 18. Real DevOps Integration

From your doc:

  • GitHub → store collections
  • Jenkins → run tests
  • Newman → CLI execution

🧠 19. Important Concepts You Learned

You now understand:

  • API design
  • Test case writing
  • Postman collections
  • Variables
  • Data-driven testing
  • Validation scripting

🔥 1. WHAT IS NEWMAN?

👉 From your file:

  • Newman = CLI tool for running Postman collections
  • Built on Node.js
  • Used for automation + CI/CD

💡 Simple Definition (Interview)

Newman is a command-line tool used to run Postman collections outside Postman,
mainly for automation and CI/CD pipelines.
Enter fullscreen mode Exit fullscreen mode

🧱 2. WHY DEVOPS NEEDS NEWMAN

Because:

Without Newman With Newman
Manual testing Automated testing
UI only CLI + pipeline
No reports HTML reports
No CI/CD Jenkins integration

⚙️ 3. PREREQUISITES (VERY IMPORTANT)

From your lecture:

You MUST install:

  1. Node.js
  2. Newman
  3. Newman HTML Reporter

Commands:

npm install -g newman
npm install -g newman-reporter-html-extra
Enter fullscreen mode Exit fullscreen mode

📦 4. BEFORE RUNNING — EXPORT FROM POSTMAN

You CANNOT run directly.

You must export:

Required files:

1. Collection → products.json
2. Data file → JSON / CSV
3. Global variables → global.json
4. (Optional) Environment variables
Enter fullscreen mode Exit fullscreen mode

🧠 KEY RULE

Collection variables → automatic
Global & Environment → must export manually
Enter fullscreen mode Exit fullscreen mode

🚀 5. CORE NEWMAN COMMAND

Basic:

newman run collection.json
Enter fullscreen mode Exit fullscreen mode

With Data + Variables:

newman run collection.json \
-d data.json \
-g globals.json
Enter fullscreen mode Exit fullscreen mode

With Report (VERY IMPORTANT):

newman run collection.json \
-d data.json \
-g globals.json \
-r html-extra
Enter fullscreen mode Exit fullscreen mode

📊 6. OUTPUT TYPES

1. CLI Output

✔ Requests passed
✔ Assertions passed
✔ Execution time
Enter fullscreen mode Exit fullscreen mode

👉 Visible in terminal


2. HTML Report (IMPORTANT)

👉 Generated file:

/newman/report.html
Enter fullscreen mode Exit fullscreen mode

👉 Contains:

  • Full request details
  • Response body
  • Assertions
  • Errors

🔥 7. ADVANCED REPORT CUSTOMIZATION

From your file:

--reporter-html-extra-export ./result/report.html
--reporter-html-extra-title "API Report"
--reporter-html-extra-browserTitle "Store API"
Enter fullscreen mode Exit fullscreen mode

👉 You can control:

  • Folder
  • File name
  • UI title

🔁 8. DATA-DRIVEN EXECUTION

JSON → 1 iteration

CSV → multiple iterations

Example:

CSV with 10 rows → 10 executions
Enter fullscreen mode Exit fullscreen mode

⚠️ IMPORTANT DEVOPS INSIGHT

Postman = Development
Newman = Automation
Enter fullscreen mode Exit fullscreen mode

🔗 9. DEVOPS FLOW (REAL WORLD)

From your lecture:

Postman → Export → Newman → GitHub → Jenkins → Reports
Enter fullscreen mode Exit fullscreen mode

📦 FULL PIPELINE

Step-by-step:

1. Create collection in Postman
2. Export JSON files
3. Store in GitHub
4. Jenkins pulls repo
5. Jenkins runs Newman
6. Generate report
Enter fullscreen mode Exit fullscreen mode

🧰 10. GIT FLOW (VERY IMPORTANT)

From your file:

git init
git remote add origin <repo>
git add .
git commit -m "message"
git push origin master
Enter fullscreen mode Exit fullscreen mode

👉 DevOps must know this.


🔥 11. JENKINS EXECUTION

In Jenkins:

Build Step:

newman run collection.json -d data.json -g globals.json -r html-extra
Enter fullscreen mode Exit fullscreen mode

Plugins REQUIRED:

  • NodeJS plugin
  • HTML Publisher plugin

📊 12. REPORT IN JENKINS

👉 After build:

Post-build → Publish HTML report
Enter fullscreen mode Exit fullscreen mode

👉 You will see:

  • Report link in Jenkins UI
  • Same HTML dashboard

🧠 13. TWO REAL DEVOPS SCENARIOS


🔹 Scenario 1 (LOCAL READY)

You already have:

  • Node.js
  • Newman

👉 Jenkins just runs command


🔹 Scenario 2 (PRODUCTION)

You DON'T have anything

👉 Jenkins installs:

  • Node.js
  • Newman
  • Reporter

👉 Runs pipeline


🔥 14. MOST IMPORTANT DEVOPS INTERVIEW POINT

How do you automate API testing in CI/CD?

Answer:
- Create Postman collection
- Export JSON
- Use Newman CLI
- Integrate with Jenkins
- Generate HTML reports
Enter fullscreen mode Exit fullscreen mode

🚀 FINAL SUMMARY (VERY IMPORTANT)

You now know:

  • API testing automation
  • Newman CLI usage
  • Data-driven testing
  • Report generation
  • Git + GitHub integration
  • Jenkins pipeline execution

🔥 1. CORE DIFFERENCE (MOST IMPORTANT)

🧠 Newman vs Postman CLI

🔹 Newman (OLD WAY)

Postman → Export JSON → Run via CLI → GitHub → Jenkins
Enter fullscreen mode Exit fullscreen mode

✔ Needs export
✔ Uses JSON file
✔ Needs GitHub


🔹 Postman CLI (NEW WAY)

Postman → Share → Get URL/ID → Run directly → Jenkins
Enter fullscreen mode Exit fullscreen mode

✔ NO export
✔ Uses cloud
✔ NO GitHub needed

👉 THIS is the biggest difference.


⚡ 2. EXPORT vs SHARE (CRITICAL CONCEPT)

Export (Newman)

Collection → JSON file → physical file
Enter fullscreen mode Exit fullscreen mode

👉 You run file locally or via Jenkins


Share (Postman CLI)

Collection → Cloud → URL + Collection ID
Enter fullscreen mode Exit fullscreen mode

👉 You run directly from cloud


🔥 Interview Answer

Newman uses exported JSON files,
Postman CLI uses shared collections from Postman cloud.
Enter fullscreen mode Exit fullscreen mode

🔐 3. REQUIRED FOR POSTMAN CLI

From your lecture:

👉 You MUST have:

  1. Postman CLI installed
  2. API Key
  3. Collection ID

🧠 VERY IMPORTANT

API Key ≠ API authentication

This is NOT for API request,
This is for Postman login via CLI
Enter fullscreen mode Exit fullscreen mode

🔑 4. HOW EXECUTION WORKS

Step 1 — Login

postman login --api-key YOUR_KEY
Enter fullscreen mode Exit fullscreen mode

Step 2 — Run Collection

postman collection run COLLECTION_ID
Enter fullscreen mode Exit fullscreen mode

Step 3 — With Data + Variables

postman collection run COLLECTION_ID \
-d data.json \
-g globals.json
Enter fullscreen mode Exit fullscreen mode

⚠️ CRITICAL LIMITATION

👉 Even though collection is in cloud:

Data files (CSV/JSON) → MUST be local
Variables → MUST be local
Enter fullscreen mode Exit fullscreen mode

🔥 5. WHAT YOU ACHIEVE

From your file:

✔ Run collection from CLI
✔ Run in Jenkins
✔ Generate reports
✔ No GitHub required


🚀 6. REPORTING (DIFFERENCE)

Newman

✔ HTML EXTRA (beautiful report)


Postman CLI

✔ Only basic HTML / JSON / XML
❌ No HTML-extra


🔥 7. HUGE ADVANTAGE OF POSTMAN CLI

👉 THIS IS VERY IMPORTANT

Postman CLI automatically uploads results to Postman cloud
Enter fullscreen mode Exit fullscreen mode

✔ You see results inside Postman UI
✔ No external reporting needed


🔄 8. DEVOPS PIPELINE FLOW

With Postman CLI

Postman Cloud
     ↓
CLI Login (API Key)
     ↓
Run Collection (ID)
     ↓
Jenkins Pipeline
     ↓
Results auto-uploaded
Enter fullscreen mode Exit fullscreen mode

🧱 9. JENKINS PIPELINE (IMPORTANT)

From your file:

3 stages:

1. Install CLI
2. Login to Postman
3. Run collection
Enter fullscreen mode Exit fullscreen mode

Example Flow

stage('Login') {
    postman login --api-key KEY
}

stage('Run') {
    postman collection run ID -d data.json -g globals.json
}
Enter fullscreen mode Exit fullscreen mode

🧠 10. DEVOPS INTERVIEW GOLD ANSWER

Question:

How do you automate API testing?

Answer:

We use Postman for API development,
Newman or Postman CLI for automation.

Newman requires exporting collections,
Postman CLI runs directly from cloud using API key and collection ID.

We integrate it with Jenkins pipelines
to automate API testing in CI/CD.
Enter fullscreen mode Exit fullscreen mode

📊 11. NEWMAN vs POSTMAN CLI (FINAL TABLE)

Feature Newman Postman CLI
Requires export Yes No
Uses cloud No Yes
Needs GitHub Yes No
API key required No Yes
Open source Yes No
Reports Advanced Basic
Postman integration No Yes

📚 12. FINAL PROJECT FLOW (VERY IMPORTANT)

From your lecture summary:

1. Requirements
2. Test cases
3. Collections
4. Requests + validations
5. Run:
   - Postman UI
   - Newman CLI
   - Postman CLI
6. Jenkins CI/CD
7. Documentation
Enter fullscreen mode Exit fullscreen mode

🔥 13. LAST PART: SWAGGER (IMPORTANT)

Two types of documentation:

1. Static

Word / Excel / Notes
Enter fullscreen mode Exit fullscreen mode

❌ Cannot execute API


2. Interactive (Swagger)

Swagger UI
Enter fullscreen mode Exit fullscreen mode

✔ Send request
✔ Get response
✔ Test APIs


🔥 Why Swagger is important

Used by developers + testers
Single source of truth
Helps write test cases
Supports API testing directly
Enter fullscreen mode Exit fullscreen mode

🚀 FINAL SUMMARY

You now understand:

✔ Newman vs Postman CLI
✔ Export vs Share
✔ API Key usage
✔ Collection ID usage
✔ Jenkins pipeline integration
✔ Swagger basics

🚀 PART 1 — MOCKING (VERY IMPORTANT CONCEPT)

🔹 What is Mocking?

👉 Mocking = Simulation of API behavior

From your file:

  • Mocking = simulate API request/response

🧠 Simple DevOps Explanation

Real API → Not ready ❌
Mock API → Simulated response ✅
Enter fullscreen mode Exit fullscreen mode

👉 You create a fake server (mock server) that behaves like real API.


🔥 Real Flow (Without Mocking)

Client → API → Database → Response
Enter fullscreen mode Exit fullscreen mode

🔥 With Mocking

Client → Mock Server → Fake Response
Enter fullscreen mode Exit fullscreen mode

⚡ WHY MOCKING IS USED

From your lecture:

✔ API not developed yet
✔ Development delayed
✔ QA wants to start testing
✔ You already have:

  • endpoints
  • request format
  • expected response

💡 REAL DEVOPS SCENARIO

👉 Backend team is late
👉 QA / DevOps cannot wait

So you:

✔ Create mock server
✔ Simulate API
✔ Start automation + pipeline


🔥 KEY POINT (INTERVIEW GOLD)

Mocking allows testing API behavior without real backend.
Enter fullscreen mode Exit fullscreen mode

⚠️ IMPORTANT LIMITATION

👉 Mock API is:

❌ NOT real
❌ NOT dynamic
✔ STATIC response

From your file:

  • response is hardcoded
  • same output every time

🧠 Example

GET /employee/5
Enter fullscreen mode Exit fullscreen mode

👉 Mock response:

{
  "id": 3,
  "name": "John"
}
Enter fullscreen mode Exit fullscreen mode

Even if ID = 5 → still returns 3

✔ Because it's fake


🔄 WHEN REAL API IS READY

👉 You DO NOT change logic

Just:

Change Base URL
Mock → Real API
Enter fullscreen mode Exit fullscreen mode

✔ Same collection
✔ Same tests
✔ Same validations


🔥 SUPER IMPORTANT (DevOps Insight)

Mock → 90% work done early
Real API → final validation
Enter fullscreen mode Exit fullscreen mode

🧱 MOCKING = STUB CONCEPT

From your file:

👉 Mock = Stub

Temporary replacement of real component
Enter fullscreen mode Exit fullscreen mode

🚀 PART 2 — PERFORMANCE TESTING (CRITICAL FOR DEVOPS)


🔹 What is Performance Testing?

👉 Testing speed + scalability of API


🧠 Difference

Type Meaning
Functional Does it work?
Performance How fast under load?

⚡ KEY IDEA

👉 1 user test ≠ real world

Real world:

1000 users → same time → same API
Enter fullscreen mode Exit fullscreen mode

🚨 BIG PROBLEMS (REAL WORLD)

From your lecture:

❌ Problem 1

Need many machines

❌ Problem 2

Cannot hit API at same exact time


💡 SOLUTION → VIRTUAL USERS

🔹 What is Virtual User?

👉 Fake user behaving like real user

✔ No physical machine
✔ Scales easily


🧠 Example

3 virtual users → 3 parallel requests
Enter fullscreen mode Exit fullscreen mode

🔥 KEY PARAMETERS

1. Virtual Users

Number of simulated users

2. Duration

How long test runs


🚀 LOAD PROFILES (VERY IMPORTANT)

This is INTERVIEW CRITICAL


1️⃣ FIXED

Same users all the time
Enter fullscreen mode Exit fullscreen mode

Example:

10 users → constant → 5 min
Enter fullscreen mode Exit fullscreen mode

2️⃣ RAMP-UP

Gradually increase users
Enter fullscreen mode Exit fullscreen mode

Example:

1 → 2 → 3 → ... → 10
Enter fullscreen mode Exit fullscreen mode

3️⃣ SPIKE

Increase → then decrease
Enter fullscreen mode Exit fullscreen mode

Example:

1 → 10 → 1
Enter fullscreen mode Exit fullscreen mode

4️⃣ PEAK

Increase → stay → decrease
Enter fullscreen mode Exit fullscreen mode

Example:

1 → 10 → stay → 1
Enter fullscreen mode Exit fullscreen mode

🔥 VISUAL UNDERSTANDING

Fixed     ─────────────

Ramp-up   /---------

Spike     /\

Peak      /───\
Enter fullscreen mode Exit fullscreen mode

📊 WHAT METRICS YOU GET

From your testing:

✔ Total requests
✔ Requests/sec
✔ Avg response time
✔ Error rate


🔥 MOST IMPORTANT METRIC

Error Rate = 0% → GOOD
Enter fullscreen mode Exit fullscreen mode

🧠 DEVOPS INTERVIEW ANSWER

Question:

How do you test API performance?

Answer:

We use tools like Postman or JMeter.

We simulate multiple users using virtual users,
apply load profiles like fixed, ramp-up, spike, and peak,
and analyze metrics like response time, throughput, and error rate.

If performance is poor, developers optimize APIs.
Enter fullscreen mode Exit fullscreen mode

🚀 REAL INDUSTRY TRUTH

From your lecture:

✔ Functional team → basic testing
✔ Performance team → specialized


💡 DevOps Role

👉 You may:

✔ Run tests
✔ Generate reports
✔ Share results

❌ Not deep analysis


🧾 FINAL SUMMARY

Mocking

✔ Simulates API
✔ Used before backend ready
✔ Static response
✔ Saves time


Performance Testing

✔ Tests speed under load
✔ Uses virtual users
✔ Uses load profiles
✔ Generates metrics

Top comments (0)