← All Tools

HTTP Methods Reference

Complete reference for all HTTP request methods. Explore GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT, and TRACE with properties, use cases, and ready-to-use code examples.

Methods Comparison Table

Method Safe Idempotent Request Body Response Body Cacheable Primary Use

REST API Best Practices

Use Nouns for Resources, Not Verbs

The HTTP method already conveys the action. Keep your URL paths as resource nouns.

  • Good: GET /users, POST /orders
  • Avoid: GET /getUsers, POST /createOrder
  • Use plural nouns: /users not /user

Use Correct HTTP Methods

Each method has a specific semantic meaning. Respect that contract.

  • GET for retrieval only -- never modify data
  • POST for creating new resources
  • PUT for full replacement of a resource
  • PATCH for partial updates
  • DELETE for removing resources

Return Appropriate Status Codes

Pair HTTP methods with correct response status codes for clear API contracts.

  • GET returns 200 OK with the resource
  • POST returns 201 Created with Location header
  • PUT/PATCH returns 200 OK or 204 No Content
  • DELETE returns 204 No Content
  • Validation errors return 422 Unprocessable Entity

Idempotency Matters

Design APIs so retrying a request produces the same result. This is critical for reliability.

  • PUT and DELETE are idempotent by design
  • Use idempotency keys for POST (e.g., Idempotency-Key header)
  • Retrying an idempotent request should never create duplicates
  • Clients rely on this for safe retries after network failures

Version Your API

Always version your REST APIs to avoid breaking existing clients when evolving.

  • URL path: /api/v1/users
  • Header: Accept: application/vnd.api.v1+json
  • Query param: /users?version=1 (less common)
  • Never break existing versions -- deprecate gracefully

Handle Errors Consistently

Return structured error responses so clients can handle failures predictably.

  • Use a consistent error response format (JSON)
  • Include: status, error, message, details
  • Distinguish client errors (4xx) from server errors (5xx)
  • Include a correlation/request ID for debugging