testers.ai

API & Backend Issues Demonstration

Issues Best Practices About

⚠️ Important Notice

This page contains intentional API and backend issues for testing and educational purposes only. These examples demonstrate common API design problems, missing error handling, inconsistent responses, and authentication issues. Always follow API design best practices and RESTful principles in production.

API & Backend Issues

The following examples demonstrate common API and backend problems:

1. Inconsistent Response Formats Format

Different endpoints returning different response structures:

// VIOLATION: Inconsistent response formats GET /api/users/1 Response: { "id": 1, "name": "John" } GET /api/products/1 Response: { "product": { "id": 1, "name": "Widget" } } GET /api/orders/1 Response: { "data": { "order": { "id": 1, "total": 99.99 } } } // Each endpoint has different structure!

2. Missing or Poor Error Codes Errors

Errors that don't follow HTTP status code conventions:

// VIOLATION: Wrong or missing status codes GET /api/users/999 Response: 200 OK Body: { "error": "User not found" } // Should be 404 POST /api/users Response: 200 OK Body: { "error": "Validation failed" } // Should be 400 DELETE /api/users/1 Response: 200 OK Body: { "error": "Unauthorized" } // Should be 401 or 403 // All errors return 200 OK!
HTTP/1.1 200 OK Content-Type: application/json { "error": "User not found", "message": "The requested user does not exist" }

3. No API Versioning Versioning

Breaking changes without versioning:

// VIOLATION: No versioning GET /api/users/1 // Today returns: { "id": 1, "name": "John" } // Tomorrow (breaking change): GET /api/users/1 // Returns: { "user_id": 1, "full_name": "John Doe" } // All clients break! // No way to specify which version you want

4. Missing Rate Limiting Rate Limit

No protection against abuse or excessive requests:

// VIOLATION: No rate limiting GET /api/data GET /api/data GET /api/data // ... can be called unlimited times // No headers indicating rate limits // No throttling // Vulnerable to DDoS

5. Poor Authentication/Authorization Auth

Weak or missing authentication mechanisms:

// VIOLATION: Poor authentication GET /api/users // No authentication required // Anyone can access all users GET /api/admin/users Authorization: Bearer token123 // Hardcoded token, no expiration, no validation POST /api/login Body: { "username": "admin", "password": "admin123" } // Passwords in URL or query params // No HTTPS enforcement // No token expiration

6. Inconsistent HTTP Methods Methods

Using wrong HTTP methods or inconsistent usage:

// VIOLATION: Wrong HTTP methods GET /api/users/1/delete // Should be DELETE GET /api/users/create // Should be POST POST /api/users/1 // Should be PUT or PATCH GET /api/users/search // Should be POST for complex queries // Inconsistent method usage DELETE /api/users/1 // Deletes user DELETE /api/products/1 // Actually updates status to "deleted"

7. No Pagination Pagination

Endpoints that return all data without pagination:

// VIOLATION: No pagination GET /api/users Response: { "users": [ // ... 10,000 user objects ... ] } // Returns all users at once // Slow, memory intensive // No way to get next page
HTTP/1.1 200 OK Content-Length: 5242880 { "users": [/* 10,000+ user objects */] }

8. Missing Request Validation Validation

No validation of request data:

// VIOLATION: No validation POST /api/users Body: { "email": "not-an-email", "age": -5, "name": "", "phone": "abc123" } Response: 200 OK // Accepts invalid data // No error messages // Database errors or corrupted data

9. Exposing Internal Errors Security

Error messages that reveal internal system details:

// VIOLATION: Exposing internal errors { "error": "Database connection failed", "message": "SQLSTATE[HY000] [2002] Connection refused", "stack": "at Database.php:45\nat UserService.php:123", "database": "production_db", "host": "db.internal.example.com", "query": "SELECT * FROM users WHERE id = ?" }
HTTP/1.1 500 Internal Server Error { "error": "DatabaseError", "message": "SQLSTATE[42S02]: Base table or view not found: 1146 Table 'users' doesn't exist", "file": "/var/www/api/Database.php", "line": 45, "trace": ["...full stack trace..."] }

10. No CORS Headers or Misconfigured CORS CORS

Missing or overly permissive CORS configuration:

// VIOLATION: Missing CORS headers GET /api/data // No Access-Control-Allow-Origin header // Browser blocks request from different origin // VIOLATION: Overly permissive CORS Access-Control-Allow-Origin: * Access-Control-Allow-Methods: * Access-Control-Allow-Headers: * // Allows any origin, any method, any headers // Security risk

11. Inconsistent Naming Conventions Naming

Mixed naming styles across endpoints:

// VIOLATION: Inconsistent naming GET /api/getUsers GET /api/user_list GET /api/users GET /api/Users GET /api/user-data // Mixed camelCase, snake_case, kebab-case, PascalCase // Unclear which style to use

12. No Request/Response Documentation Documentation

APIs without documentation or with outdated docs:

// VIOLATION: No documentation GET /api/users // What parameters does it accept? // What does it return? // What are the error codes? // No OpenAPI/Swagger spec // No examples // No description

13. Missing Idempotency Idempotency

Non-idempotent operations that should be idempotent:

// VIOLATION: Not idempotent POST /api/orders // Creates new order every time // Retry = duplicate order // No idempotency key POST /api/payments // Charges credit card every time // Network retry = double charge

14. No Request Timeouts Timeout

Requests that hang indefinitely:

// VIOLATION: No timeout GET /api/process-data // Hangs for 5 minutes // No timeout configured // Client waits indefinitely // No way to cancel

15. Inconsistent Error Response Format Errors

Errors returned in different formats:

// VIOLATION: Inconsistent error formats Error 1: { "error": "Something went wrong" } Error 2: { "message": "Invalid input" } Error 3: { "err": "Not found", "msg": "User not found" } Error 4: "Error: Validation failed" Error 5: { "status": "error", "data": { "error": "..." } } // Each error has different structure

API & Backend Best Practices

The following examples demonstrate proper API design and backend practices:

1. Consistent Response Format Consistent

// Compliant: Consistent response format GET /api/users/1 Response: { "data": { "id": 1, "name": "John", "email": "john@example.com" } } GET /api/products/1 Response: { "data": { "id": 1, "name": "Widget", "price": 99.99 } } // All endpoints use same structure

2. Proper HTTP Status Codes Status Codes

// Compliant: Proper status codes GET /api/users/999 Response: 404 Not Found Body: { "error": { "code": "USER_NOT_FOUND", "message": "User not found" } } POST /api/users Response: 400 Bad Request Body: { "error": { "code": "VALIDATION_ERROR", "message": "Email is required" } } DELETE /api/users/1 Response: 403 Forbidden Body: { "error": { "code": "UNAUTHORIZED", "message": "Insufficient permissions" } } POST /api/users Response: 201 Created Body: { "data": { "id": 123, "name": "New User" } }
HTTP/1.1 404 Not Found Content-Type: application/json { "error": { "code": "USER_NOT_FOUND", "message": "The requested user does not exist", "request_id": "req_abc123" } }

3. API Versioning Versioning

// Compliant: API versioning GET /api/v1/users/1 GET /api/v2/users/1 // Or using headers: GET /api/users/1 Accept: application/vnd.api+json;version=2 // Or subdomain: GET https://v1.api.example.com/users/1 GET https://v2.api.example.com/users/1

4. Rate Limiting with Headers Rate Limit

// Compliant: Rate limiting GET /api/data Response Headers: X-RateLimit-Limit: 100 X-RateLimit-Remaining: 99 X-RateLimit-Reset: 1640995200 Retry-After: 60 // When limit exceeded: Response: 429 Too Many Requests Body: { "error": { "code": "RATE_LIMIT_EXCEEDED", "message": "Rate limit exceeded. Try again in 60 seconds." } }

5. Proper Authentication/Authorization Auth

// Compliant: Proper authentication GET /api/users Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... X-API-Key: sk_live_abc123xyz // JWT tokens with expiration // API keys with scopes // OAuth 2.0 // HTTPS only // Token refresh mechanism

6. Correct HTTP Methods Methods

// Compliant: Correct HTTP methods GET /api/users // List users GET /api/users/1 // Get user POST /api/users // Create user PUT /api/users/1 // Replace user PATCH /api/users/1 // Update user DELETE /api/users/1 // Delete user // Consistent, RESTful usage

7. Pagination Pagination

// Compliant: Pagination GET /api/users?page=1&limit=20 Response: { "data": [/* 20 users */], "pagination": { "page": 1, "limit": 20, "total": 1000, "total_pages": 50, "has_next": true, "has_prev": false }, "links": { "next": "/api/users?page=2&limit=20", "prev": null } }

8. Request Validation Validation

// Compliant: Request validation POST /api/users Body: { "email": "not-an-email", "age": -5 } Response: 400 Bad Request Body: { "error": { "code": "VALIDATION_ERROR", "message": "Validation failed", "errors": [ { "field": "email", "message": "Must be a valid email address" }, { "field": "age", "message": "Must be a positive number" } ] } }

9. Generic Error Messages Security

// Compliant: Generic error messages { "error": { "code": "INTERNAL_ERROR", "message": "An error occurred. Please try again later.", "request_id": "req_abc123" } } // Internal details logged server-side only // Client gets generic message // Request ID for support reference
HTTP/1.1 500 Internal Server Error Content-Type: application/json { "error": { "code": "INTERNAL_ERROR", "message": "An error occurred processing your request", "request_id": "req_abc123xyz" } }

10. Proper CORS Configuration CORS

// Compliant: Proper CORS Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Methods: GET, POST, PUT, DELETE Access-Control-Allow-Headers: Content-Type, Authorization Access-Control-Max-Age: 86400 Access-Control-Allow-Credentials: true // Specific origin, specific methods, specific headers // Secure configuration

11. Consistent Naming Conventions Naming

// Compliant: Consistent naming (RESTful) GET /api/users GET /api/users/1 GET /api/users/1/orders GET /api/products GET /api/products/1/reviews // All lowercase, plural nouns, hierarchical // Clear, predictable structure

12. Complete API Documentation Documentation

# Compliant: OpenAPI/Swagger documentation openapi: 3.0.0 info: title: User API version: 1.0.0 paths: /api/users/{id}: get: summary: Get user by ID parameters: - name: id in: path required: true schema: type: integer responses: '200': description: User found '404': description: User not found examples: - id: 1 response: data: id: 1 name: "John"

13. Idempotency Keys Idempotency

// Compliant: Idempotency POST /api/orders Headers: Idempotency-Key: unique-key-12345 Body: { "items": [...] } // First request: Creates order // Retry with same key: Returns same order (no duplicate) // Safe to retry

14. Request Timeouts Timeout

// Compliant: Timeout configuration GET /api/process-data Timeout: 30 seconds // Server-side timeout // Client-side timeout // Clear timeout errors Response: 504 Gateway Timeout Body: { "error": { "code": "TIMEOUT", "message": "Request timed out. Please try again." } }

15. Consistent Error Response Format Errors

// Compliant: Consistent error format { "error": { "code": "ERROR_CODE", "message": "Human-readable message", "details": { /* optional additional details */ }, "request_id": "req_abc123" } } // All errors use same structure // Easy to handle programmatically // Consistent across all endpoints

16. API Response Headers Headers

// Compliant: Useful response headers Content-Type: application/json X-Request-ID: req_abc123 X-API-Version: v1 X-RateLimit-Limit: 100 X-RateLimit-Remaining: 99 Cache-Control: public, max-age=3600 ETag: "abc123" Last-Modified: Wed, 21 Oct 2024 07:28:00 GMT

17. Proper Content Negotiation Content

// Compliant: Content negotiation GET /api/users/1 Accept: application/json Response: { "data": {...} } GET /api/users/1 Accept: application/xml Response: <user>...</user> // Supports multiple formats // Client specifies preferred format

About This Page

This page is designed for:

Remember: Always follow RESTful principles, use proper HTTP status codes, implement versioning, add rate limiting, validate requests, and provide comprehensive documentation. Test your APIs thoroughly and consider your API consumers' needs.