Session 2: API Testing | Postman | Environment Setup & Types of HTTP Requests

Overview of Postman (what it is + why use it)

• Postman is an API testing tool used for manual testing of APIs.
• It’s also used for developer documentation of APIs (participants mentioned creating API documentation using Postman).
• Supports testing of both REST APIs and SOAP APIs.
• Main goal of the session:
  • Download/install Postman
  • Review core features
  • Learn setup concepts and HTTP request types for API testing

---

Postman versions + environment setup

• Postman is available in two forms:
  • Desktop app
  • Web app (accessed via a URL in a browser)
• The UI/features are the same, and workspaces are synced:
  • Changes in desktop reflect in web
  • Changes in web reflect in desktop

Account requirement

• A Postman account is required.
• The session emphasized creating/signing in using a Gmail account.
• During installation, Postman prompts for login/sign-up.

---

Install/download highlights (Windows + Mac)

• From the official Postman site, download is free.
• Windows: download Windows 64-bit
• Mac: download separately, with selection for Apple chip (e.g., Intel vs Apple)
• Installation produces:
  • Windows: executable installer
  • Mac: DMG installer

---

Postman workspace (core concept)

• Workspace is the first/basic entity required in Postman.
• A workspace is the place where Postman saves:
  • test cases, requests, test data, and related work
• Workspaces are created based on the logged-in Gmail account.

Workspace operations covered

• Create workspace
• Rename workspace
• Delete workspace (requires confirming with the workspace name)

Workspace visibility types (4 options)

• Personal: only you can access
• Private: you can invite team members (invitation-based access)
• Team: team members have default access (requires adding team members)
• Public: anyone can view/import and perform actions (as described)

---

Collections (how requests are organized)

• Collections act like folders inside a workspace.
• A collection contains:
  • folders/subfolders
  • HTTP requests

Collection operations covered

• Create collection
• Rename collection
• Delete collection
• Duplicate collection
• Export collection as .json
• Run a collection (executes requests inside it)

Hierarchy emphasized

• Workspace → Collections → (Folders) → Requests

A collection must exist before creating HTTP requests.

---

HTTP requests supported + CRUD-style meaning

The session focused on these commonly used request types:

• GET: retrieve resource/data
• POST: create a resource
• PUT: update/replace an existing resource
• DELETE: delete a resource

Additional mention:

• PATCH: partial update of a resource (only some fields)
• PUT updates the entire resource, while PATCH updates part of it.

---

Request URL parts (URI anatomy)

Typical URI components explained:

• Host/Domain: server/domain
• Path parameters: segments after the domain (separated by /)
• Query parameters: after ?, used for filtering (e.g., page=2)

Notes:

• Query parameters may be absent depending on API design.
• Multiple query parameters can exist.

---

What gets sent + what gets validated in Postman

What you send

When sending an API request in Postman:

• Request type (GET/POST/PUT/DELETE/PATCH)
• URL/URI
• Request payload (body) where applicable
  • Often not needed for GET
  • Needed for POST/PUT (create/update)
  • DELETE commonly has no payload

What you receive

• Response payload (body)
• Status code, timing, headers, cookies, etc.

Validation points emphasized (response-focused)

• Status code validation
• Response time validation
• Response size validation
• Response body validation
  • handles JSON and XML
  • conceptually uses JSONPath/XMLPath for content validation
• Cookies validation (temporary browser/server state data)
• Headers validation (e.g., content-type, date, encoding, etc.)
• Test results appear after validations:
  • pass/fail messages in a “test results” area

---

Demonstrated flow: sending GET/POST/PUT/DELETE in Postman

GET

• Add request → set URL → send request
• Review response tabs such as:
  • body, headers, cookies, etc.

POST

• Set body → raw → JSON
• Send payload fields (example mentioned: name, job)
• Response includes:
  • auto-generated ID
  • creation time details
• Suggested validations:
  • match sent fields
  • ensure ID exists
  • check status code/time/size

PUT

• Send record ID in the URL (path parameter)
• Send updated content in body
• Response reflects the updated resource

DELETE

• Send the ID in the URL
• Successful deletion returns 204 No Content

---

HTTP status code series (important for testing)

Status codes were categorized into series:

• 2xx (success): request succeeded
  • examples cited: 200, 201, 204
• 4xx (client/auth/errors): issues with request or authorization
  • examples: 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 400 Bad Request
• 5xx (server errors): server-side failures
  • examples: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, timeouts, etc.

The session emphasized memorizing common codes for interview/testing questions.

---

Running requests in bulk

Instead of running requests one-by-one, you can:

• Run a collection (auto-executes all requests sequentially)
• Use options such as:
  • which requests to include
  • iteration settings (delay mentioned conceptually, e.g., milliseconds between iterations)

---

Learning plan for next session (future work)

After covering basics (workspace, collections, requests, and validation fundamentals), the next parts will include:

• creating custom/demo APIs
• testing them with different request types and response validations

The speaker suggested relying on self-created APIs, since external demo APIs can be inconsistent/unreliable.

---

Main speakers / sources

• Main speaker (source): Lecture presenter/instructor for “Session 2: API Testing | Postman | Environment Setup & Types of HTTP Requests”
• External documentation/source mentioned: Postman official website (download/install)
• Demo API source mentioned: A demo API provider page (sample APIs, request/response examples, and endpoints for GET/POST/PUT/PATCH)