REST API fundamentals review in Postman - Deep Dive

Overview - REST API fundamentals review

What is it?

REST API fundamentals cover how web services communicate using standard web protocols. REST stands for Representational State Transfer, a style that uses simple HTTP methods like GET, POST, PUT, and DELETE to perform actions on resources. These resources are identified by URLs, and data is often exchanged in formats like JSON or XML. Understanding REST APIs helps you test and interact with web services effectively.

Why it matters

Without REST APIs, different software systems would struggle to talk to each other easily over the internet. REST APIs provide a simple, standardized way to access and manipulate data remotely. This makes building, testing, and maintaining software faster and more reliable. If REST APIs didn’t exist, developers would spend much more time creating custom communication methods, leading to more bugs and slower progress.

Where it fits

Before learning REST API fundamentals, you should understand basic web concepts like HTTP and URLs. After mastering REST APIs, you can explore advanced API testing techniques, automation with tools like Postman, and concepts like authentication, versioning, and API design.

Mental Model

Core Idea

REST APIs let clients and servers exchange data by using simple, standard HTTP methods to act on resources identified by URLs.

Think of it like...

Using a REST API is like ordering food at a restaurant: you tell the waiter (server) what you want (resource) and how you want it (HTTP method), then the waiter brings your order (response).

┌───────────────┐       HTTP Request       ┌───────────────┐
│    Client     │ ───────────────────────▶ │    Server     │
└───────────────┘                         └───────────────┘
       ▲                                         │
       │                                         │
       │           HTTP Response                  │
       └─────────────────────────────────────────┘

Resources identified by URLs:
GET /users/123  → Get user 123
POST /users     → Create new user
PUT /users/123  → Update user 123
DELETE /users/123 → Delete user 123

Build-Up - 7 Steps

1

Foundation

Understanding HTTP Methods Basics

Concept: Learn the main HTTP methods used in REST APIs and what they do.

There are four main HTTP methods in REST: - GET: Retrieve data from the server. - POST: Send new data to the server. - PUT: Update existing data on the server. - DELETE: Remove data from the server. Each method tells the server what action to perform on a resource.

Result

You can identify what action a REST API call will perform just by looking at its HTTP method.

Knowing HTTP methods is essential because they define the basic actions you can perform on resources in REST APIs.

2

Foundation

Resources and URLs in REST

Concept: Resources are the key objects REST APIs work with, and each has a unique URL.

In REST, everything is a resource like users, products, or orders. Each resource has a URL (Uniform Resource Locator) that acts like its address. For example, /users/123 points to user number 123. You use HTTP methods on these URLs to perform actions.

Result

You understand how REST APIs organize data and how to locate specific items using URLs.

Recognizing resources and their URLs helps you know what data you are working with and how to access it.

3

Intermediate

Request and Response Structure

🤔Before reading on: Do you think REST API requests always include a body? Commit to your answer.

Concept: Learn what parts make up a REST API request and response, including headers, body, and status codes.

A REST API request usually has: - URL: The resource address. - Method: The HTTP action. - Headers: Extra info like content type. - Body: Data sent to the server (optional, mostly for POST/PUT). The response includes: - Status code: Shows success or error (e.g., 200 OK, 404 Not Found). - Headers: Info about the response. - Body: The data returned, often JSON.

Result

You can read and build REST API requests and understand what the server replies mean.

Understanding request and response parts lets you debug and test APIs effectively by checking what you send and receive.

4

Intermediate

Using Postman for API Testing

🤔Before reading on: Do you think Postman can automate API tests or only send manual requests? Commit to your answer.

Concept: Postman is a tool that helps you send REST API requests and check responses easily, with features for automation and scripting.

Postman lets you: - Create and send HTTP requests with chosen methods and URLs. - Add headers and body data. - View responses with status codes and data. - Write tests using JavaScript to check if responses are correct. - Automate sequences of requests for complex testing.

Result

You can use Postman to test APIs manually and automate tests to save time and catch bugs.

Knowing how to use Postman bridges theory and practice, making API testing accessible and efficient.

5

Advanced

Handling Status Codes and Errors

🤔Before reading on: Do you think a 200 status code always means the API worked perfectly? Commit to your answer.

Concept: Status codes tell you if a request succeeded or failed, and how to handle errors properly in tests.

Common status codes: - 200 OK: Success. - 201 Created: Resource created. - 400 Bad Request: Client sent wrong data. - 401 Unauthorized: Missing or bad authentication. - 404 Not Found: Resource doesn’t exist. - 500 Internal Server Error: Server problem. In testing, you check these codes to confirm the API behaves as expected and handle errors gracefully.

Result

You can write tests that verify correct status codes and detect when something goes wrong.

Understanding status codes prevents false positives in tests and helps diagnose issues quickly.

6

Advanced

REST API Idempotency and Safety

🤔Before reading on: Do you think all HTTP methods can be safely repeated without side effects? Commit to your answer.

Concept: Idempotency means repeating a request has the same effect as doing it once; safety means no data changes happen.

GET is safe and idempotent: you can call it many times without changing data. PUT and DELETE are idempotent but not safe: repeating them doesn’t change the result beyond the first call. POST is neither safe nor idempotent: repeating it can create multiple resources. Knowing this helps design tests that avoid unintended side effects.

Result

You can predict how repeated API calls affect data and write safer tests.

Recognizing idempotency and safety helps prevent bugs caused by repeated requests during testing or retries.

7

Expert

REST API Versioning and Evolution

🤔Before reading on: Do you think changing an API always breaks existing clients? Commit to your answer.

Concept: APIs evolve over time; versioning strategies help maintain compatibility while adding features or fixing bugs.

Common versioning methods: - URL versioning: /v1/users - Header versioning: custom headers specify version - Query parameters: ?version=1 Good versioning lets clients choose which API version to use, avoiding sudden breaks. Testing must cover multiple versions and deprecated features.

Result

You understand how to manage API changes and test different versions effectively.

Knowing versioning strategies is key to maintaining stable APIs and reliable tests in real-world projects.

Under the Hood

REST APIs work over HTTP, where clients send requests to servers using URLs and methods. The server processes the request, accesses or modifies resources, and sends back a response with status codes and data. Internally, servers map URLs to functions or database queries. HTTP headers carry metadata like content type and authentication tokens. The stateless nature means each request is independent, so servers don’t keep client state between calls.

Why designed this way?

REST was designed to use existing web standards simply and flexibly. By using HTTP methods and URLs, it avoids inventing new protocols. Statelessness improves scalability and reliability because servers don’t need to remember clients. This design fits the web’s distributed nature and allows many clients and servers to interact easily.

┌───────────────┐       HTTP Request       ┌───────────────┐
│    Client     │ ───────────────────────▶ │    Server     │
│ (Postman)     │                         │ (API Logic)   │
└───────────────┘                         └───────────────┘
       ▲                                         │
       │                                         │
       │           HTTP Response                  │
       └─────────────────────────────────────────┘

Server internals:
┌───────────────┐
│ URL Routing   │
├───────────────┤
│ Controller    │
├───────────────┤
│ Business Logic│
├───────────────┤
│ Database      │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does a 200 OK status code always mean the API request succeeded perfectly? Commit to yes or no.

Common Belief: A 200 OK status code means the API request was successful and the data is correct.

Reality: A 200 status means the server processed the request without error, but the response data might still indicate a problem or be empty.

Why it matters: Assuming 200 always means success can cause tests to miss logical errors or empty responses, leading to false confidence.

Quick: Can POST requests be safely repeated without causing duplicate data? Commit to yes or no.

Common Belief: POST requests are safe to repeat because they just send data to the server.

Reality: POST is not idempotent; repeating it can create multiple resources or side effects.

Why it matters: Retrying POST requests without care can cause duplicate entries or unexpected behavior in production.

Quick: Is REST API communication always stateful, remembering previous requests? Commit to yes or no.

Common Belief: REST APIs keep track of client state between requests to manage sessions.

Reality: REST APIs are stateless; each request is independent and contains all needed info.

Why it matters: Expecting stateful behavior can lead to design and testing errors, such as relying on previous calls to set context.

Quick: Does changing an API always require clients to update immediately? Commit to yes or no.

Common Belief: Any API change breaks existing clients and forces immediate updates.

Reality: With proper versioning, APIs can evolve without breaking existing clients.

Why it matters: Misunderstanding this can cause unnecessary panic and poor API design that harms user experience.

Expert Zone

1

Understanding that REST’s statelessness improves scalability but requires clients to handle state, which affects test design.

2

Knowing that HTTP caching headers can affect API responses and tests, sometimes causing stale data if not handled properly.

3

Recognizing that some APIs mix REST principles with RPC or GraphQL styles, requiring flexible testing approaches.

When NOT to use

REST APIs are not ideal when you need real-time communication or complex queries; alternatives like WebSockets or GraphQL may be better. Also, for very simple internal services, lightweight protocols like gRPC might be preferred.

Production Patterns

In real-world projects, REST APIs are tested using automated Postman collections integrated into CI/CD pipelines. Versioning is carefully managed to avoid breaking clients. Tests include checking authentication, rate limiting, and error handling to ensure robustness.

Connections

HTTP Protocol

REST APIs build directly on HTTP methods and status codes.

Understanding HTTP deeply helps you grasp why REST APIs behave as they do and how to troubleshoot issues.

Software Design Patterns

REST follows architectural principles like statelessness and resource-based design.

Knowing design patterns clarifies why REST APIs are structured for scalability and simplicity.

Supply Chain Management

Both REST APIs and supply chains manage resources and state transitions systematically.

Seeing REST as managing resource states like supply chains manage goods helps understand the importance of clear state and action definitions.

Common Pitfalls

#1 Ignoring HTTP status codes and only checking response data.

Wrong approach:

if (response.body) { console.log('Success'); }

Correct approach:

if (response.status === 200) { console.log('Success'); }

Root cause:

Misunderstanding that status codes communicate success or failure separately from response content.

#2 Sending POST requests repeatedly without checking for duplicates.

Wrong approach:

post('/users', newUserData); post('/users', newUserData);

Correct approach:

Check if user exists before POST or use idempotent methods like PUT for updates.

Root cause:

Not knowing POST is not idempotent and can create multiple resources.

#3 Assuming REST APIs maintain session state automatically.

Wrong approach:

Send request 1 without auth, then request 2 expecting server remembers user.

Correct approach:

Include authentication info in every request, e.g., tokens in headers.

Root cause:

Confusing REST statelessness with stateful web sessions.

Key Takeaways

REST APIs use standard HTTP methods and URLs to perform actions on resources, making communication simple and consistent.

Understanding HTTP methods, status codes, and request/response structure is essential for effective API testing.

Tools like Postman make it easy to send requests, inspect responses, and automate tests for REST APIs.

REST APIs are stateless, so each request must contain all necessary information, which affects how tests are designed.

Proper API versioning and error handling ensure APIs evolve without breaking clients and help maintain reliable software.

Practice

1. Which HTTP method is typically used to retrieve data from a REST API without changing it?

easy

A. POST

B. GET

C. PUT

D. DELETE

Solution

1. Step 1: Understand HTTP methods

   GET is used to request data without modifying it, while POST, PUT, DELETE change data.

2. Step 2: Identify method for data retrieval

   Since we want to retrieve data without changes, GET is the correct method.

3. Final Answer:

   GET -> Option B

4. Quick Check:

   Retrieve data = GET [OK]

Hint: GET is for reading data, others modify it [OK]

Common Mistakes:

• Confusing POST with GET for data retrieval
• Using DELETE to get data
• Thinking PUT retrieves data

2. Which of the following is the correct way to set the HTTP method to POST in Postman?

easy

A. Add 'method: POST' in the Headers tab

B. Type 'POST' in the URL field

C. Select POST from the dropdown next to the URL input

D. Use the Body tab to set method to POST

Solution

1. Step 1: Locate HTTP method selector in Postman

   Postman has a dropdown menu next to the URL field to choose HTTP methods.

2. Step 2: Confirm correct method selection

   Selecting POST from this dropdown sets the request method properly.

3. Final Answer:

   Select POST from the dropdown next to the URL input -> Option C

4. Quick Check:

   Method dropdown sets HTTP method [OK]

Hint: Use dropdown near URL to pick method [OK]

Common Mistakes:

• Typing method name in URL field
• Trying to set method in Headers
• Confusing Body tab with method setting

3. What will be the status code returned by a successful DELETE request in a REST API?

medium

A. 404 Not Found

B. 201 Created

C. 200 OK

D. 204 No Content

Solution

1. Step 1: Understand DELETE success responses

   A successful DELETE often returns 204 No Content, meaning the resource was deleted and no content is returned.

2. Step 2: Compare other status codes

   200 OK means success with content, 201 Created is for new resource creation, 404 Not Found means resource missing.

3. Final Answer:

   204 No Content -> Option D

4. Quick Check:

   DELETE success = 204 No Content [OK]

Hint: DELETE success usually returns 204 No Content [OK]

Common Mistakes:

• Choosing 201 Created for DELETE
• Assuming 200 OK always returns content
• Confusing 404 with success

4. You send a POST request in Postman but get a 405 Method Not Allowed error. What is the most likely cause?

medium

A. The API endpoint does not support POST method

B. The URL is incorrect

C. The request body is empty

D. The server is down

Solution

1. Step 1: Understand 405 error meaning

   405 Method Not Allowed means the server recognizes the URL but the HTTP method used is not supported on that endpoint.

2. Step 2: Eliminate other options

   Incorrect URL usually gives 404, empty body usually does not cause 405, server down causes no response or 5xx errors.

3. Final Answer:

   The API endpoint does not support POST method -> Option A

4. Quick Check:

   405 = Method not allowed on endpoint [OK]

Hint: 405 means method not allowed on URL [OK]

Common Mistakes:

• Confusing 405 with 404 Not Found
• Assuming empty body causes 405
• Thinking server down causes 405

5. You want to test a REST API endpoint that updates user data. Which combination of HTTP method and Postman feature is best to use?

hard

A. PUT method with Body tab to send JSON data

B. GET method with Params tab to send JSON data

C. DELETE method with Headers tab to send JSON data

D. POST method with URL query parameters

Solution

1. Step 1: Identify method for updating data

   PUT is the standard HTTP method to update existing data in REST APIs.

2. Step 2: Choose Postman feature to send data

   The Body tab allows sending JSON data payload, which is needed to update user data.

3. Step 3: Evaluate other options

   GET does not update data, DELETE removes data, and URL query parameters are not suitable for sending JSON update data.

4. Final Answer:

   PUT method with Body tab to send JSON data -> Option A

5. Quick Check:

   Update data = PUT + Body JSON [OK]

Hint: Use PUT with Body for updates in Postman [OK]

Common Mistakes:

• Using GET to update data
• Sending JSON in URL parameters
• Confusing DELETE with update