API Testing Fundamentals

📌 Definition:

Testing APIs (Application Programming Interfaces) to verify they work correctly, reliably, securely, and perform well.

📖 Detailed Explanation:

APIs are the backbone of modern applications. Mobile apps use APIs to get data from backend servers. Frontend communicates with backend via APIs. Microservices communicate via APIs. Testing APIs is critical but often overlooked. API bugs are invisible to users (no UI), but they break functionality completely.

📎 Api Basics Detailed:

Http Methods:

Method	Purpose	Example	Should Return
GET	Retrieve data (read-only, safe, idempotent)	GET /api/users/123 retrieves user with ID 123	200 OK with user data in response body
POST	Create new data (creates resource)	POST /api/users with body {name: 'John'} creates new user	201 Created with new user data
PUT	Update entire resource (replace)	PUT /api/users/123 with body {name: 'Jane'} replaces user data	200 OK with updated data
PATCH	Partially update resource (modify specific fields)	PATCH /api/users/123 with body {email: 'john@new.com'} updates only email	200 OK with updated data
DELETE	Delete resource	DELETE /api/users/123 deletes user with ID 123	204 No Content or 200 OK

Http Status Codes:

Code	Meaning	Example
200 OK	Request successful	GET /api/users returns 200 with user list
201 Created	Resource created successfully	POST /api/users returns 201 with new user
204 No Content	Success but no data to return	DELETE /api/users/123 returns 204
400 Bad Request	Invalid request (client error)	POST /api/users without required name field
401 Unauthorized	Authentication required	API request without login token
403 Forbidden	Authenticated but not authorized	User tries to access admin endpoint
404 Not Found	Resource doesn't exist	GET /api/users/999 when user doesn't exist
500 Server Error	Internal server error	Unexpected backend crash
503 Unavailable	Service temporarily down	Server under maintenance

Request Components:

Component	Description	Example
URL/Endpoint	/api/users or /api/users/123	Points to the resource being accessed
HTTP Method	GET, POST, PUT, DELETE	Specifies the action
Headers	Content-Type, Authorization, etc.	Content-Type: application/json tells server data is JSON
Body/Payload	Data being sent (for POST, PUT, PATCH)	{name: 'John', email: 'john@example.com'}
Query Parameters	?page=1&limit=10	Filters or pagination parameters

📎 What To Test Detailed:

Test Category:

Functionality Testing

Tests:

Correct response for valid requests - Does GET return expected data?
Error handling for invalid requests - Does POST with missing fields return 400?
Correct status codes - Does creation return 201, not 200?
Response data format - Is data in correct JSON structure?
Data validation - Does API reject invalid email format?

Test Category:

Boundary/Edge Case Testing

Tests:

Minimum/maximum values - What happens with 0 items or 1000000 items?
Empty fields - Does API handle null values correctly?
Special characters - Can API handle Unicode, emojis, SQL injection attempts?
Duplicate requests - What happens when same request sent twice?
Timeout testing - What if request takes >30 seconds?

Test Category:

Security Testing

Tests:

Authentication - Are API tokens required? Do expired tokens get rejected?
Authorization - Can User A access User B's data? Should return 403.
SQL Injection - Can attacker use malicious SQL in parameters?
Sensitive data exposure - Are passwords returned in response? They shouldn't be.
Rate limiting - Can attacker make 10000 requests/second or is it throttled?

Test Category:

Performance Testing

Tests:

Response time - Does API respond in <200ms? <1000ms?
Throughput - Can API handle 1000 requests per second?
Scalability - Does response time increase when database grows?
Resource usage - Does API consume excessive memory/CPU?

Test Category:

Data Integrity Testing

Tests:

Consistency - If API is called twice with same data, is result identical?
Atomicity - If CREATE fails midway, is data partially saved? (Should be all-or-nothing)
Referential integrity - Can you delete a user if they have orders? (Database constraints)

📎 Real World Scenario:

Api Endpoint:

POST /api/orders/checkout

Test Case 1:

Name:

Valid Checkout

Request:

POST /api/orders/checkout {userId: 123, items: [{productId: 1, qty: 2}], paymentMethod: 'card'}

Expected Response:

201 Created {orderId: 999, totalAmount: 100, status: 'confirmed'}

What To Verify:

Order created, correct total calculated, status is confirmed

Test Case 2:

Name:

Invalid User

Request:

POST /api/orders/checkout {userId: 99999, items: [...]}

Expected Response:

400 Bad Request {error: 'User not found'}

What To Verify:

Returns 400, not 500. Error message is clear.

Test Case 3:

Name:

Insufficient Stock

Request:

POST /api/orders/checkout {userId: 123, items: [{productId: 1, qty: 1000}]}

Expected Response:

409 Conflict {error: 'Only 50 items in stock'}

What To Verify:

Returns 409, not silent failure. User knows why order failed.

📎 Common Api Testing Tools:

Tool	Use	Features
Postman	Manual and automated API testing, collection sharing	Easy UI, good for beginners
Rest Assured	Java-based API testing in CI/CD pipelines	Java syntax, integrates with TestNG
SoapUI	SOAP and REST API testing	Load testing, security scanning
Insomnia	API testing with good UX	Team collaboration, environment management
JMeter	Performance/load testing for APIs	Simulate thousands of concurrent users
Swagger/OpenAPI	API documentation and auto-generated tests	Contract-driven testing

🎯 Scenario-Based Interview Question:

Your user API has GET /api/users/123. Without authentication, this returns all user data including passwords. What would you do?

💡 Quick Tip:

🔗 API testing = Testing data flow without UI. Master this to advance your QA career. Postman is your best friend.

💡 Interview Focus:

API testing is modern, essential skill. Interviewers value candidates who understand APIs deeply.

‹ Previous

Test Environment & Requirements

Next ›

Cross-Browser Testing