HTTP Request Builder

GET: Retrieve data without side effects. Idempotent (multiple identical requests have same effect as single request). URL parameters only, no request body. Example: GET /api/users/123 fetches user 123. Cacheable by browsers/CDNs. Use for: fetching resources, search queries, pagination. POST: Create new resources or submit data that causes server-side changes. Not idempotent (each request creates new resource). Supports request body. Example: POST /api/users with JSON body creates new user. Use for: creating resources, form submissions, uploading files, non-idempotent operations. PUT: Replace entire resource or create if doesn't exist. Idempotent (sending same PUT request multiple times results in same state). Example: PUT /api/users/123 with full user object replaces user 123. Use for: full updates, resource replacement. PATCH: Partial update of resource. May or may not be idempotent depending on implementation. Example: PATCH /api/users/123 with {"email": "new@example.com"} updates only email. Use for: partial updates, field-level modifications. DELETE: Remove resource. Idempotent (deleting same resource multiple times has same result). Example: DELETE /api/users/123 removes user 123. Best practices: Never use GET for state-changing operations. Use POST for actions that don't fit other methods. Use PUT for full replacements, PATCH for partial updates. Always return appropriate status codes: 200 (OK), 201 (Created), 204 (No Content), 404 (Not Found).

Content-Type header: Tells server the format of request body. Common values: application/json for JSON data ({"key": "value"}), application/x-www-form-urlencoded for form data (key1=value1&key2=value2), multipart/form-data for file uploads with form fields, text/plain for plain text, application/xml for XML. Setting Content-Type: For JSON: {'Content-Type': 'application/json'} and body as JSON.stringify(data). For forms: browser sets automatically with FormData, or manually set for URL-encoded. Accept header: Tells server what response formats you accept. Example: {'Accept': 'application/json'} requests JSON response. Multiple values: {'Accept': 'application/json, text/plain'}. Authorization header: For authentication. Bearer token: {'Authorization': 'Bearer eyJhbGc...'}. Basic auth: {'Authorization': 'Basic ' + btoa('username:password')}. API key: {'Authorization': 'ApiKey your-key'} or custom header {'X-API-Key': 'your-key'}. Other important headers: User-Agent: identifies client application. Referer: source page URL (auto-set by browsers). Cache-Control: caching directives (no-cache, max-age=3600). Accept-Encoding: compression support (gzip, deflate, br). Custom headers: Prefix with X- by convention (though deprecated in RFC 6648): X-Request-ID, X-Correlation-ID. CORS headers: Server responds with Access-Control-Allow-Origin, client doesn't set these. Common mistakes: Forgetting Content-Type for POST/PUT (server may not parse body correctly). Sending JSON as string instead of JSON.stringify(). Including Authorization header in CORS preflight (use credentials properly).

1. JSON (application/json): Most common for APIs. Structure: {"name": "John", "age": 30, "tags": ["developer", "writer"]}. Usage: fetch('/api/users', {method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({name: 'John'})}). Advantages: Readable, supports nested objects/arrays, standardized. 2. URL-encoded (application/x-www-form-urlencoded): Form submission format. Structure: name=John&age=30&tags=developer&tags=writer. Encoding: spaces become + or %20, special characters encoded. Usage: const params = new URLSearchParams({name: 'John', age: 30}); fetch('/api/form', {method: 'POST', headers: {'Content-Type': 'application/x-www-form-urlencoded'}, body: params}). Limitations: No nested objects, arrays repeated as key=val1&key=val2. 3. Multipart form-data: For file uploads with optional text fields. Structure: Multiple parts separated by boundary. Usage: const formData = new FormData(); formData.append('file', fileInput.files[0]); formData.append('description', 'Profile pic'); fetch('/api/upload', {method: 'POST', body: formData}). Important: Don't manually set Content-Type; browser adds boundary automatically. 4. Plain text (text/plain): Raw text data. No structure. Example: CSV, logs, plain strings. 5. Binary data: Use Blob or ArrayBuffer for binary files. Example: body: new Blob([imageData], {type: 'image/png'}). Choosing format: Use JSON for structured data and modern APIs. Use URL-encoded for simple forms without files (backward compatible). Use multipart for file uploads or mixed text/binary data. Use plain text for unstructured data. Testing tip: This tool lets you preview how each format structures your data before sending, helping you choose the right format and debug encoding issues.

Basic Authentication: Simplest method. Encode username:password in Base64. Header: Authorization: Basic base64(username:password). Implementation: const credentials = btoa('user:pass'); headers['Authorization'] = 'Basic ' + credentials;. Security note: Credentials sent with every request. Use HTTPS only (insecure over HTTP). Bearer Token: Token-based auth (JWT common). Header: Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.... Implementation: headers['Authorization'] = 'Bearer ' + token;. Workflow: Login with credentials → receive token → include token in subsequent requests. Token usually expires (check expiry in JWT payload). Refresh tokens: When access token expires, use refresh token to get new access token without re-login. API Key: Simple key for identification. Methods: 1. Query parameter: /api/data?api_key=your-key (not recommended, appears in logs). 2. Custom header: X-API-Key: your-key (common, cleaner than query param). 3. Authorization header: Authorization: ApiKey your-key. OAuth 2.0: Industry standard for delegated access. Flow: 1. Redirect user to OAuth provider (Google, GitHub). 2. User authorizes app. 3. Provider redirects back with authorization code. 4. Exchange code for access token via POST to token endpoint. 5. Use access token in Authorization header: Bearer access_token. Scopes: Request specific permissions (read:user, write:repo). Implementation tip: Libraries like oauth2-client handle OAuth flow complexity. Best practices: Store tokens securely (httpOnly cookies or secure storage, never localStorage for sensitive apps). Implement token refresh logic before expiry. Use short-lived access tokens (15 min) with long-lived refresh tokens (30 days). Include CSRF protection for cookie-based auth. This tool helps you test each auth method by constructing proper headers before implementing in your application.

Preflight requests: Browser sends automatic OPTIONS request before actual request when: 1. Using methods other than GET, POST, HEAD. 2. Setting custom headers beyond simple headers (Accept, Accept-Language, Content-Language, Content-Type). 3. Content-Type is not application/x-www-form-urlencoded, multipart/form-data, or text/plain. Example: PUT /api/users/123 with Content-Type: application/json triggers preflight. Browser sends: OPTIONS /api/users/123 with headers Access-Control-Request-Method: PUT and Access-Control-Request-Headers: content-type. Server response required: Access-Control-Allow-Origin: https://yoursite.com (or * for public APIs, but can't use * with credentials). Access-Control-Allow-Methods: GET, POST, PUT, DELETE. Access-Control-Allow-Headers: Content-Type, Authorization. Access-Control-Max-Age: 86400 (cache preflight for 24 hours). Credentials handling: For cookies/auth: Client sets credentials: 'include' in fetch. Server responds with Access-Control-Allow-Credentials: true and specific origin (not *). Common CORS errors: 1. Missing CORS headers: Server doesn't respond to OPTIONS or doesn't include Allow-Origin header. 2. Wildcard with credentials: Can't use Access-Control-Allow-Origin: * with credentials. 3. Wrong origin: Server returns different origin than request origin. 4. Missing Allow-Headers: Custom header sent but not listed in Allow-Headers. Development workarounds: CORS proxy: Route requests through https://cors-anywhere.herokuapp.com/ (not for production). Browser extension: Disable CORS checks (dev only). Production solutions: Configure server properly (Express: cors middleware, Nginx: add headers). Use same-origin requests (API on same domain). Implement server-side proxy to bypass CORS. Testing: This tool shows you exactly what preflight requests look like, helping you configure server CORS policies correctly before deploying.

Status code categories: 2xx Success: 200 OK (request succeeded), 201 Created (resource created), 204 No Content (success but no response body, common for DELETE), 206 Partial Content (range request). 3xx Redirection: 301 Moved Permanently (update bookmark), 302 Found (temporary redirect), 304 Not Modified (cached version still valid), 307 Temporary Redirect (preserve method). 4xx Client Errors: 400 Bad Request (invalid syntax/validation failed), 401 Unauthorized (missing/invalid authentication), 403 Forbidden (authenticated but not authorized), 404 Not Found (resource doesn't exist), 405 Method Not Allowed (wrong HTTP method), 409 Conflict (state conflict, e.g., duplicate resource), 422 Unprocessable Entity (validation error), 429 Too Many Requests (rate limited). 5xx Server Errors: 500 Internal Server Error (generic server failure), 502 Bad Gateway (upstream server error), 503 Service Unavailable (server overloaded/maintenance), 504 Gateway Timeout (upstream timeout). Debugging steps: 1. Check network tab: Open browser DevTools → Network → inspect request/response headers, body, timing. 2. Verify request structure: Correct URL (no typos), proper method, required headers present, body format matches Content-Type. 3. Check CORS errors: Preflight failures show in console. Verify server CORS configuration. 4. Authentication issues: 401: Check if token is included and valid. 403: Check if user has permission (different from 401). Token expiry: Implement refresh logic. 5. Validation errors: 400/422: Check response body for error details. Common causes: missing required fields, wrong data types, invalid formats. 6. Rate limiting: 429: Respect Retry-After header, implement exponential backoff. 7. Server errors: 500: Contact API provider, check API status page. 502/504: Temporary infrastructure issues, retry with backoff. Tools: Use browser DevTools Network tab for requests from browser. Use this HTTP Request Builder to test API endpoints in isolation, examining exact request/response. Use curl -v for command-line debugging with verbose output. Use Wireshark for deep packet inspection. Logging: Log failed requests with full context (URL, headers, body, timestamp). Implement error tracking (Sentry, Rollbar) to catch production issues. Best practice: Always check response status before parsing body. Implement proper error handling for each status code category. Provide meaningful error messages to users based on status codes.