5.2 KiB
5.2 KiB
description
| description |
|---|
| Debug API failures using OpenAPI specs and HTTP logs |
Debug API Failures
Systematically debug REST API failures by analyzing OpenAPI specifications and HTTP request/response logs.
Workflow
When the user requests API debugging, follow this comprehensive approach:
Step 1: Load API Documentation
Use load_openapi to parse the OpenAPI spec:
- Accepts JSON or YAML format
- Extracts all endpoints, parameters, and expected responses
- Identifies authentication requirements
- Captures base URLs and server information
Example:
load_openapi({
filePath: "/path/to/openapi.yaml",
name: "my-api"
})
Step 2: Ingest HTTP Logs
Use ingest_logs to import request/response data:
- Supports HAR (HTTP Archive) format from browser DevTools
- Accepts direct log arrays
- Automatically categorizes successful vs failed requests
- Calculates status code and method distributions
Example (HAR file):
ingest_logs({
filePath: "/path/to/requests.har",
format: "har"
})
Example (direct logs):
ingest_logs({
logs: [
{
timestamp: "2025-10-10T12:00:00Z",
method: "POST",
url: "https://api.example.com/users",
statusCode: 400,
requestBody: { "name": "John" },
responseBody: { "error": "Missing required field: email" }
}
]
})
Step 3: Analyze Failures
Use explain_failure to understand why requests failed:
- Identifies root causes based on HTTP status codes
- Compares actual behavior with OpenAPI spec expectations
- Suggests specific fixes
- Assesses severity (critical, high, medium, low)
Example:
explain_failure({
logIndex: 0, // Index from ingest_logs
specName: "my-api" // Compare against loaded spec
})
Step 4: Generate Reproducible Tests
Use make_repro to create cURL commands:
- Generates executable cURL command
- Includes alternative formats (HTTPie, JavaScript fetch)
- Useful for documentation, bug reports, and testing
Example:
make_repro({
logIndex: 0,
includeHeaders: true,
pretty: true // Format for readability
})
Common Debugging Scenarios
Scenario 1: 400 Bad Request
- Load spec to see expected request format
- Ingest logs containing the failure
- Explain failure to identify validation errors
- Make repro to generate test command
- Fix request based on schema requirements
- Test using generated cURL command
Scenario 2: 401 Unauthorized
- Load spec to check authentication requirements
- Explain failure on 401 response
- Verify authentication headers in request
- Check token expiration or permissions
- Make repro with corrected auth headers
Scenario 3: 500 Internal Server Error
- Ingest logs to find pattern of 500 errors
- Explain failure to assess criticality
- Make repro for server team to reproduce
- Check request payload for edge cases
- Monitor server logs (not in scope of this tool)
Scenario 4: Performance Issues
- Ingest logs with duration data
- Analyze distribution of response times
- Identify slow endpoints
- Make repro for performance testing
Analysis Output
The debugging workflow produces:
From explain_failure:
- Severity: critical | high | medium | low
- Possible Causes: List of likely root causes
- Suggested Fixes: Actionable remediation steps
- Matching Endpoint: Comparison with OpenAPI spec
- Details: Request/response bodies for inspection
From make_repro:
- cURL Command: Copy-paste ready command
- HTTPie Alternative: Shorter syntax for quick tests
- JavaScript fetch: For integration into automated tests
- Metadata: Method, URL, headers, body presence
Best Practices
- Always load the OpenAPI spec first - Provides context for failure analysis
- Use HAR files when possible - Most complete log format
- Include request/response bodies - Critical for validation errors
- Compare with spec - Catches mismatches between docs and implementation
- Generate repro commands - Makes bug reports actionable
- Test fixes immediately - Use generated cURL to verify
Tips
- Export HAR from browser DevTools (Network tab → Right-click → Save as HAR)
- Use
pretty: truefor readable cURL commands (good for docs) - Use
pretty: falsefor one-liner cURL (good for scripts) - Check response headers for hints (X-RateLimit-*, Retry-After, etc.)
- Look for patterns in multiple failures (same endpoint, same error)
Example Usage
User: "My API is returning 400 errors, help me debug"
You:
1. First, do you have an OpenAPI spec? If yes, I'll load it.
2. How are you capturing HTTP logs? (HAR file, JSON logs, manual entry?)
3. Let me analyze the failures and suggest fixes.
[After receiving spec and logs]
I've loaded your API spec and found 5 failed requests:
- 3x POST /users → 400 (Missing required field: email)
- 2x GET /users/{id} → 404 (Invalid user ID format)
Let me explain the first failure...
[Uses explain_failure]
Here's a working cURL command to test the fix:
[Uses make_repro]
Notes
- This tool focuses on client-side debugging (requests/responses)
- Server-side logs and profiling are out of scope
- For complex API issues, combine with other debugging tools
- Keep OpenAPI specs up-to-date for accurate analysis