--- title: "HTTP Methods: GET, POST, PUT, PATCH, DELETE & More - API7.ai" description: "Learn the nine core HTTP methods and when to use GET vs POST, POST vs PUT, PUT vs PATCH, DELETE, HEAD, OPTIONS, TRACE, and CONNECT in APIs." url: "https://api7.ai/learning-center/api-101/http-methods-in-apis" --- [Skip to article](#column-content) Column contentsAPI 101 [API 101](https://api7.ai/learning-center/api-101) Search this column 01 API Fundamentals [View this topic · 10](https://api7.ai/learning-center/api-101?topic=fundamentals)[1. Introduction to APIs: Definition and Importance](https://api7.ai/learning-center/api-101/what-is-api)[2. RESTful API Best Practices: Architecture, Methods, and Examples](https://api7.ai/learning-center/api-101/restful-api-best-practices)[3. SOAP vs REST: Differences, Examples, and When to Use Each](https://api7.ai/learning-center/api-101/soap-vs-rest-differences)[4. GraphQL: A New Approach to APIs](https://api7.ai/learning-center/api-101/what-is-graphql)[5. gRPC: High-Performance RPC Framework](https://api7.ai/learning-center/api-101/what-is-grpc)[6. Webhooks: Real-Time Communication Between Applications](https://api7.ai/learning-center/api-101/what-is-webhooks)[7. API Endpoints: Designing and Managing for Scalability and Security](https://api7.ai/learning-center/api-101/what-are-api-endpoints)[8. HTTP Methods: GET, POST, PUT, PATCH, DELETE & More](https://api7.ai/learning-center/api-101/http-methods-in-apis)[9. API Rate Limiting Best Practices and Algorithms](https://api7.ai/learning-center/api-101/api-rate-limiting)[10. API Versioning Strategies and Best Practices](https://api7.ai/learning-center/api-101/api-versioning) 02 API Development and Design [View this topic · 10](https://api7.ai/learning-center/api-101?topic=design)[11. How to Build an API: From Design to Deployment](https://api7.ai/learning-center/api-101/build-your-first-api)[12. API Documentation: Tools and Techniques](https://api7.ai/learning-center/api-101/api-documentation-tools-and-techniques)[13. OpenAPI Specification Guide: OAS, Examples, and Best Practices](https://api7.ai/learning-center/api-101/openapi-specification)[14. API Mocking: Testing Without a Backend](https://api7.ai/learning-center/api-101/api-mocking)[15. API Error Handling: Status Codes, Error Responses, and Best Practices](https://api7.ai/learning-center/api-101/error-handling-apis)[16. Authentication and Authorization in APIs](https://api7.ai/learning-center/api-101/authentication-authorization-apis)[17. OAuth 2.0: Secure API Access](https://api7.ai/learning-center/api-101/oauth-2.0-secure-api-access)[18. API Gateways: Managing and Securing Traffic](https://api7.ai/learning-center/api-101/api-gateways-managing-securing-traffic)[19. Microservices and APIs: Designing Modular Applications](https://api7.ai/learning-center/api-101/microservices-apis-modular-application-design)[20. API Orchestration: Combining Multiple Services](https://api7.ai/learning-center/api-101/api-orchestration-combining-services) 03 API Security [View this topic · 10](https://api7.ai/learning-center/api-101?topic=security)[21. How to Avoid Common Vulnerabilities](https://api7.ai/learning-center/api-101/how-to-avoid-common-api-vulnerabilities)[22. Implementing JWT for API Security](https://api7.ai/learning-center/api-101/implementing-jwt-for-api-security)[23. Rate Limiting and Throttling: Protecting Your API](https://api7.ai/learning-center/api-101/rate-limiting-and-throttling)[24. API Security Testing Tools and Techniques for Modern APIs](https://api7.ai/learning-center/api-101/api-security-testing-tools-and-techiniques)[25. CORS in APIs: Handling Cross-Origin Requests](https://api7.ai/learning-center/api-101/understanding-cors-in-apis)[26. Data Encryption in API Communication](https://api7.ai/learning-center/api-101/data-encryption-in-api-communication)[27. API Security Best Practices: Protecting Your Digital Front Door](https://api7.ai/learning-center/api-101/api-security-best-practices)[28. API Tokens Explained: Usage, Security, and Best Practices](https://api7.ai/learning-center/api-101/api-tokens-and-their-usage)[29. Securing APIs in Serverless Architectures](https://api7.ai/learning-center/api-101/secure-apis-in-serverless-architectures)[30. API Security in the Age of IoT](https://api7.ai/learning-center/api-101/api-security-in-the-age-of-iot) 04 API Integration [View this topic · 10](https://api7.ai/learning-center/api-101?topic=integration)[31. Integrating Third-Party APIs into Your Application](https://api7.ai/learning-center/api-101/integrate-third-party-apis)[32. API Aggregation: Combining Multiple APIs](https://api7.ai/learning-center/api-101/api-aggregation-combining-multiple-apis)[33. Real-Time Data with Streaming API](https://api7.ai/learning-center/api-101/real-time-data-with-streaming-apis)[34. Handling API Pagination: Fetching Large Data Sets](https://api7.ai/learning-center/api-101/handling-api-pagination)[35. Error Handling When Consuming APIs](https://api7.ai/learning-center/api-101/error-handling-when-consuming-apis)[36. API Integration Testing: Ensuring Reliability](https://api7.ai/learning-center/api-101/api-integration-testing-ensuring-reliability)[37. Working with Rate Limits in Third-Party APIs](https://api7.ai/learning-center/api-101/working-with-rate-limits-in-third-party-apis)[38. Automating Workflows with APIs](https://api7.ai/learning-center/api-101/automating-workflows-with-apis)[39. API Integration in Mobile Applications](https://api7.ai/learning-center/api-101/api-integration-in-mobile-applications)[40. How to Overcome API Integration Challenges](https://api7.ai/learning-center/api-101/how-to-overcome-api-integration-challenges) 05 API Management [View this topic · 10](https://api7.ai/learning-center/api-101?topic=management)[41. API Lifecycle Management: From Development to Retirement](https://api7.ai/learning-center/api-101/api-lifecycle-management)[42. Monitoring API Performance: Tools and Metrics](https://api7.ai/learning-center/api-101/api-performance-monitoring)[43. API Analytics: Understanding Usage Patterns](https://api7.ai/learning-center/api-101/api-analytics-guide)[44. Monetizing Your API: Strategies and Models](https://api7.ai/learning-center/api-101/api-monetization-strategies-models)[45. Scaling APIs: Best Practices for High Traffic](https://api7.ai/learning-center/api-101/scaling-api-high-traffic-best-practices)[46. API Governance Policies and Standards Guide](https://api7.ai/learning-center/api-101/api-governance-policies-standards-guide)[47. API Developer Portal Guide: Features, Onboarding, and Engagement](https://api7.ai/learning-center/api-101/developer-portal-guide-engaging-api-users)[48. Rate Limiting Strategies for API Management](https://api7.ai/learning-center/api-101/rate-limiting-strategies-for-api-management)[49. API Breaking Changes: Deprecation and Migration Guide](https://api7.ai/learning-center/api-101/api-versioning-managing-changes-over-time)[50. Choosing the Right API Management Platform](https://api7.ai/learning-center/api-101/choosing-the-right-api-management-platform) 06 Emerging API Practices [View this topic · 10](https://api7.ai/learning-center/api-101?topic=trends)[51. Serverless APIs: Building Scalable Applications](https://api7.ai/learning-center/api-101/serverless-apis)[52. API-First Development: From Contract to Production](https://api7.ai/learning-center/api-101/api-first-development)[53. Hypermedia APIs: HATEOAS and Its Applications](https://api7.ai/learning-center/api-101/hypermedia-apis)[54. The Role of AI in API Development](https://api7.ai/learning-center/api-101/ai-in-api-development)[55. APIs in IoT: Connecting Devices](https://api7.ai/learning-center/api-101/apis-in-iot)[56. REST and GraphQL APIs: Architecture, Caching, and Gateways](https://api7.ai/learning-center/api-101/graphql-vs-rest)[57. The Rise of API Marketplaces](https://api7.ai/learning-center/api-101/rise-of-api-marketplaces)[58. Event-Driven APIs: Designing for Real-Time](https://api7.ai/learning-center/api-101/event-driven-api-design-real-time)[59. Low-Code/No-Code API Development](https://api7.ai/learning-center/api-101/low-code-no-code-api-development-guide)[60. API Development Trends: The Future of APIs for Modern Teams](https://api7.ai/learning-center/api-101/future-and-trends-of-apis) 07 Industry API Applications [View this topic · 10](https://api7.ai/learning-center/api-101?topic=industries)[61. Payment Gateway APIs: Integrating Stripe and PayPal](https://api7.ai/learning-center/api-101/stripe-vs-paypal-api-integration-guide)[62. Social Media APIs: Facebook, Twitter, and Instagram](https://api7.ai/learning-center/api-101/social-media-apis)[63. Maps & Geolocation APIs: Google Maps, Mapbox, and OSM](https://api7.ai/learning-center/api-101/mapping-and-geolocation-apis)[64. E-commerce APIs: Building Modern Online Stores](https://api7.ai/learning-center/api-101/e-commerce-apis)[65. Healthcare APIs: Connecting Medical Data](https://api7.ai/learning-center/api-101/healthcare-apis)[66. Financial APIs: Accessing Banking Services](https://api7.ai/learning-center/api-101/financial-apis)[67. Travel and Booking APIs: Integrating Flight and Hotel Data](https://api7.ai/learning-center/api-101/travel-and-booking-apis)[68. Music and Video Streaming APIs: Spotify and YouTube](https://api7.ai/learning-center/api-101/music-and-video-streaming-apis)[69. Weather APIs: Accessing Meteorological Data](https://api7.ai/learning-center/api-101/weather-apis)[70. Sports Data APIs: Features, Use Cases, and Integration Tips](https://api7.ai/learning-center/api-101/sports-data-apis) 08 Tools and Platforms [View this topic · 10](https://api7.ai/learning-center/api-101?topic=tools)[71. What Is Postman? API Development Platform Guide](https://api7.ai/learning-center/api-101/postman-api-development-environment)[72. Swagger: Designing and Documenting APIs](https://api7.ai/learning-center/api-101/swagger-designing-and-documenting-apis)[73. Insomnia API Client: Debug, Test, and Design APIs](https://api7.ai/learning-center/api-101/insomnia-rest-client-for-debugging)[74. What Is Apigee? API Management Features and Architecture](https://api7.ai/learning-center/api-101/apigee-api-management-platform)[75. Building Serverless APIs with AWS API Gateway](https://api7.ai/learning-center/api-101/aws-api-gateway-building-serverless-apis)[76. Apache APISIX: Open-Source API Gateway and Enterprise Support](https://api7.ai/learning-center/api-101/apache-apisix-open-source-api-gateway)[77. MuleSoft: Connecting Applications and Data](https://api7.ai/learning-center/api-101/mulesoft-connecting-applications-and-data)[78. RapidAPI Guide: Discovering, Testing, and Connecting to APIs](https://api7.ai/learning-center/api-101/rapidapi-discovering-and-connecting-to-apis)[79. Firebase: Backend as a Service](https://api7.ai/learning-center/api-101/firebase-backend-as-a-service)[80. Auth0: Complete Authentication and Authorization Platform](https://api7.ai/learning-center/api-101/auth0-authentication-authorization-platform) 09 API Testing [View this topic · 10](https://api7.ai/learning-center/api-101?topic=testing)[81. Automated API Testing: Tools and Techniques](https://api7.ai/learning-center/api-101/automated-api-testing-tools-and-techniques)[82. Load Testing Your API: Ensuring Performance at Scale](https://api7.ai/learning-center/api-101/load-testing-your-api-ensuring-performance)[83. Mocking APIs for Testing: Accelerating Development and Improving Quality](https://api7.ai/learning-center/api-101/mocking-apis-for-testing-purposes)[84. Contract Testing in API Development: Ensuring Reliable Integration](https://api7.ai/learning-center/api-101/contract-testing-in-api-development)[85. Postman API Testing Automation: Newman, CLI, and CI/CD](https://api7.ai/learning-center/api-101/using-postman-for-api-testing)[86. Continuous Integration and API Testing](https://api7.ai/learning-center/api-101/continuous-integration-and-api-testing)[87. Security Testing for APIs: Protecting Your API from Vulnerabilities](https://api7.ai/learning-center/api-101/security-testing-for-apis)[88. Handling API Deprecations in Testing: Strategies for Smooth Transitions](https://api7.ai/learning-center/api-101/handling-api-deprecations-in-testing)[89. Testing GraphQL APIs: Challenges and Solutions](https://api7.ai/learning-center/api-101/testing-graphql-apis-challenges-and-solutions)[90. API Test Automation Frameworks: A Comparative Study](https://api7.ai/learning-center/api-101/api-test-automation-frameworks-comparative-study) 10 Documentation and Developer Experience [View this topic · 10](https://api7.ai/learning-center/api-101?topic=documentation)[91. Writing Clear and Concise API Documentation](https://api7.ai/learning-center/api-101/writing-clear-and-concise-api-documentation)[92. Tools for Generating API Documentation](https://api7.ai/learning-center/api-101/tools-for-generating-api-documentation)[93. Interactive API Documentation for Developer Experience](https://api7.ai/learning-center/api-101/interactive-api-documentation)[94. Maintaining Documentation for Multiple API Versions](https://api7.ai/learning-center/api-101/maintaining-documentation-for-multiple-api-versions)[95. Using OpenAPI for API Documentation](https://api7.ai/learning-center/api-101/using-openapi-for-api-documentation)[96. Best Practices for Documenting API Error Responses](https://api7.ai/learning-center/api-101/best-practices-for-documenting-api-error-responses)[97. Incorporating Code Samples in API Documentation](https://api7.ai/learning-center/api-101/incorporating-code-samples-in-api-documentation)[98. API Documentation for Non-Developers](https://api7.ai/learning-center/api-101/api-documentation-for-non-developers)[99. Translating API Documentation for Global Audiences](https://api7.ai/learning-center/api-101/translating-api-documentation-for-global-audiences)[100. How to Measure API Documentation Effectiveness](https://api7.ai/learning-center/api-101/measuring-api-documentation-effectiveness) [API 101](https://api7.ai/learning-center/api-101)[API Fundamentals](https://api7.ai/learning-center/api-101?topic=fundamentals) On this page On this page - [HTTP Methods at a Glance](#http-methods-at-a-glance) - [GET vs POST vs PUT vs PATCH vs DELETE: Quick Decision Table](#get-vs-post-vs-put-vs-patch-vs-delete-quick-decision-table) - [Quick Summary List](#quick-summary-list) - [What Are HTTP Methods in APIs?](#what-are-http-methods-in-apis) - [Why Are HTTP Methods Important in API Design?](#why-are-http-methods-important-in-api-design) - [1. Standardization and Clarity](#1-standardization-and-clarity) - [2. Resource Management](#2-resource-management) - [3. Scalability and Maintainability](#3-scalability-and-maintainability) - [All 9 Core HTTP Methods Explained](#all-9-core-http-methods-explained) - [GET: Retrieve Data](#get-retrieve-data) - [POST Request Method: Create or Submit Data](#post-request-method-create-or-submit-data) - [PUT: Replace a Resource Entirely](#put-replace-a-resource-entirely) - [PATCH: Partially Update a Resource](#patch-partially-update-a-resource) - [What Is the Difference Between PUT and PATCH?](#what-is-the-difference-between-put-and-patch) - [DELETE: Remove a Resource](#delete-remove-a-resource) - [HEAD: Retrieve Headers Only](#head-retrieve-headers-only) - [OPTIONS: Discover Supported Methods](#options-discover-supported-methods) - [TRACE: Diagnostic Loop-Back Test](#trace-diagnostic-loop-back-test) - [CONNECT: Establish a Tunnel](#connect-establish-a-tunnel) - [Common Mistakes and How to Avoid Them](#common-mistakes-and-how-to-avoid-them) - [1. Misusing HTTP Methods](#1-misusing-http-methods) - [2. Ignoring Idempotency](#2-ignoring-idempotency) - [3. Returning Incorrect Status Codes](#3-returning-incorrect-status-codes) - [4. Overloading POST for Everything](#4-overloading-post-for-everything) - [5. Confusing PUT and PATCH](#5-confusing-put-and-patch) - [HTTP Methods and API Gateways](#http-methods-and-api-gateways) - [Frequently Asked Questions](#frequently-asked-questions) - [How many HTTP methods are there?](#how-many-http-methods-are-there) - [What is the difference between GET and POST?](#what-is-the-difference-between-get-and-post) - [What is the difference between POST and PUT?](#what-is-the-difference-between-post-and-put) - [What is the difference between PUT and PATCH?](#what-is-the-difference-between-put-and-patch-1) - [What are safe and idempotent HTTP methods?](#what-are-safe-and-idempotent-http-methods) - [Can GET requests have a request body?](#can-get-requests-have-a-request-body) - [What HTTP method should I use to update a resource?](#what-http-method-should-i-use-to-update-a-resource) - [Conclusion](#conclusion) - [Next Steps](#next-steps) Article 8 # HTTP Methods: GET, POST, PUT, PATCH, DELETE & More API7.ai Published: March 19, 2025 Updated: September 10, 2026 **HTTP methods** (also called HTTP request methods or HTTP verbs) are standardized actions that indicate the desired operation to perform on a given resource. If you are designing or consuming [RESTful APIs](https://api7.ai/learning-center/api-101/restful-api-best-practices), the most common questions are practical ones: when should you use GET vs POST, when is POST vs PUT the right comparison, and how do PUT, PATCH, and DELETE behave when a request is retried? This guide explains the eight methods defined by [HTTP Semantics (RFC 9110)](https://www.rfc-editor.org/rfc/rfc9110.html), plus PATCH as defined by [RFC 5789](https://www.rfc-editor.org/rfc/rfc5789.html): GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, and PATCH. You will learn how the methods map to common API operations, which are safe or idempotent, what status codes to return, and how an [API gateway](https://api7.ai/learning-center/api-gateway-guide/what-is-an-api-gateway) can enforce method-based routing and policies. ## HTTP Methods at a Glance | Method | Primary purpose | Safe | Idempotent | Default cache behavior | | ----------- | --------------------------------------- | ---- | ------------------------------ | ---------------------------------------------------------- | | **GET** | Retrieve a representation | Yes | Yes | Cacheable unless response controls prohibit it | | **HEAD** | Retrieve the headers a GET would return | Yes | Yes | Cacheable; can update stored GET metadata | | **POST** | Process submitted data for a resource | No | No | Not by default; explicit freshness information is required | | **PUT** | Create or replace state at a known URI | No | Yes | Not cacheable | | **DELETE** | Remove the association with a resource | No | Yes | Not cacheable | | **CONNECT** | Establish a tunnel | No | No | Not cacheable | | **OPTIONS** | Describe communication options | Yes | Yes | Not cacheable | | **TRACE** | Perform a message loop-back test | Yes | Yes | Not cacheable | | **PATCH** | Apply partial modifications | No | Depends on the patch operation | Not cacheable by default | > **Safe** means the client is not requesting a state change. **Idempotent** means multiple identical requests have the same intended effect as one request; the response status and body can still differ. These properties describe method semantics, not a guarantee that every server implementation is correct. ## GET vs POST vs PUT vs PATCH vs DELETE: Quick Decision Table | Question | Use This Method | Why | | ---------------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------ | | Do you only need to retrieve data? | `GET` | It is safe, cacheable, and should not change server state. | | Do you need to create a new resource or trigger an action? | `POST` | It is designed for non-idempotent operations and request bodies. | | Do you need to create or replace state at a known URI? | `PUT` | Its replacement semantics are idempotent when the same representation is sent again. | | Do you need to update only a few fields? | `PATCH` | It avoids sending the full resource representation. | | Do you need to remove a resource? | `DELETE` | It expresses deletion and is expected to be idempotent. | In short: use **GET vs POST** to decide between reading and creating/submitting, and use **POST vs PUT** to decide between creating an unknown/new resource and replacing a known resource at a stable URL. ### Quick Summary List 1. **GET** — Retrieves data without requesting a state change 2. **POST** — Submits data to create a new resource 3. **PUT** — Creates or replaces state at a known URI 4. **PATCH** — Applies partial modifications to a resource 5. **DELETE** — Removes the specified resource 6. **HEAD** — Uses GET semantics but returns no response content 7. **OPTIONS** — Returns the HTTP methods supported by a URL 8. **TRACE** — Performs a diagnostic message loop-back 9. **CONNECT** — Establishes a tunnel through a proxy ## What Are HTTP Methods in APIs? HTTP (Hypertext Transfer Protocol) methods are standardized actions that clients (such as browsers, mobile apps, or CLI tools) use to interact with resources on a server. In RESTful APIs, these methods map to CRUD operations, making them essential for managing data: - **Create** → POST - **Read** → GET - **Update** → PUT or PATCH - **Delete** → DELETE When you browse a website, your browser sends a GET request to retrieve the page content. When you submit a form, a POST request sends the data to the server. When you change your profile settings, a PUT or PATCH request updates your information. This predictable mapping is what makes REST APIs intuitive and easy to work with. ## Why Are HTTP Methods Important in API Design? ### 1. Standardization and Clarity HTTP methods provide a consistent framework for defining actions. GET retrieves data; POST is commonly used to create resources. This standardization makes APIs intuitive — any developer can understand an endpoint's purpose by looking at the HTTP method alone. ### 2. Resource Management Each HTTP method corresponds to a specific action on a resource: - **GET /users/123** → Retrieve user 123 - **POST /users** → Create a new user - **PUT /users/123** → Replace user 123 with the supplied representation - **PATCH /users/123** → Update specific fields of user 123 - **DELETE /users/123** → Remove user 123 This clear mapping reduces ambiguity and ensures efficient resource management. ### 3. Scalability and Maintainability Proper method semantics make APIs easier for clients, caches, gateways, and retry logic to handle correctly. GET responses are cacheable by definition, although cache directives and authorization rules still determine whether a particular response can be reused. PUT and DELETE are idempotent, but clients should still consider timeouts, preconditions, and application-specific side effects before automatically retrying them. ## All 9 Core HTTP Methods Explained ### GET: Retrieve Data **Purpose**: Retrieve data without asking the server to modify the target resource. **Best Practices**: - Use query parameters for filtering, sorting, and pagination (e.g., `?page=2&limit=10`). - Never include sensitive data in URLs (e.g., passwords or [API keys](https://api7.ai/blog/what-is-api-key-why-need-them-complete-guide)). - GET requests must be idempotent — repeating the same request should not cause additional state changes, even if the response may differ over time. - Return `200 OK` with the resource in the response body. **Example**: ``` GET /users/123 HTTP/1.1 Host: api.example.com Accept: application/json ``` **Response**: ``` HTTP/1.1 200 OK Content-Type: application/json { "id": 123, "name": "John Doe", "email": "john@example.com" } ``` ### POST Request Method: Create or Submit Data **Purpose**: Create a new resource or submit data to the server. A client sends a POST request with request data in the message body, commonly as JSON or form data. Unlike a GET URL, that body is not normally stored in browser history, although applications must still protect sensitive values in logs and developer tools. **Best Practices**: - Use POST when the target resource should process the submitted representation, such as creating a subordinate resource or triggering an action. - Include proper error handling (e.g., return `400 Bad Request` for invalid input). - When POST creates a resource, return `201 Created` and include a `Location` header when the new resource has an identifier. Other processing outcomes may use `200 OK`, `202 Accepted`, or `204 No Content`. **Example**: ``` POST /users HTTP/1.1 Host: api.example.com Content-Type: application/json { "name": "John Doe", "email": "john@example.com" } ``` **Response**: ``` HTTP/1.1 201 Created Location: /users/124 Content-Type: application/json { "id": 124, "name": "John Doe", "email": "john@example.com" } ``` ### PUT: Replace a Resource Entirely **Purpose**: Create or replace the state of a resource at a known URI with the supplied representation. **Best Practices**: - PUT requests must be idempotent — repeating the same request has the same effect. - Treat the request body as the replacement representation defined by the API contract. Whether omitted fields are rejected, defaulted, or removed is application-specific. - Return `200 OK` for successful updates or `204 No Content` if no response body is needed. - If the resource does not exist, PUT may create it (return `201 Created`). **Example**: ``` PUT /users/123 HTTP/1.1 Host: api.example.com Content-Type: application/json { "name": "Jane Doe", "email": "jane@example.com", "role": "admin" } ``` This request asks the server to replace the state represented by `/users/123` with the supplied representation. The API contract must define how validation and omitted fields are handled. ### PATCH: Partially Update a Resource **Purpose**: Apply partial modifications to an existing resource. **Best Practices**: - Use PATCH when you only need to update specific fields (e.g., changing a user's email without resending their entire profile). - PATCH is not guaranteed to be idempotent (though it can be designed to be). - Return `200 OK` when the response includes the updated representation, or `204 No Content` when the update succeeds without a response body. - Use JSON Merge Patch (`application/merge-patch+json`) or JSON Patch (`application/json-patch+json`) for structured updates. **Example** (JSON Merge Patch): ``` PATCH /users/123 HTTP/1.1 Host: api.example.com Content-Type: application/merge-patch+json { "email": "jane.new@example.com" } ``` This request updates **only the email** of user 123 — all other fields remain unchanged. ### What Is the Difference Between PUT and PATCH? This is one of the most common questions in API design: | Aspect | PUT | PATCH | | -------------- | ------------------------------------------------------ | -------------------------------------------- | | Update scope | Replacement of resource state | Partial modification (specific fields) | | Request body | Replacement representation defined by the API contract | Patch document describing changes | | Idempotent | Always | Not guaranteed | | Missing fields | Behavior must be defined by the API contract | Determined by the patch format and operation | | Use case | Replacing user profile entirely | Changing just the email address | **Rule of thumb**: Use PUT when the client has the complete updated resource. Use PATCH when the client only knows what changed. ### DELETE: Remove a Resource **Purpose**: Remove a resource from the server. **Best Practices**: - DELETE is idempotent in its intended effect. A retry may return a different status, such as `404 Not Found`, after the association has already been removed. - Return `200 OK` when the response includes a status or representation, `202 Accepted` when deletion is asynchronous, or `204 No Content` when deletion completes without a response body. - A later retry may return `404 Not Found` if the resource no longer exists and the API exposes that distinction. - Consider soft deletes (marking as deleted rather than removing) for data that may need recovery. **Example**: ``` DELETE /users/123 HTTP/1.1 Host: api.example.com ``` **Response**: ``` HTTP/1.1 204 No Content ``` ### HEAD: Retrieve Headers Only **Purpose**: Uses the same request semantics as GET but returns no response content. A server may omit headers whose values are determined only while generating GET content. **Best Practices**: - Use HEAD to check if a resource exists without downloading its content. - Use HEAD to inspect `Content-Length`, `Last-Modified`, or `ETag` headers before making a full GET request. - HEAD requests must be safe and idempotent. **Example**: ``` HEAD /users/123 HTTP/1.1 Host: api.example.com ``` **Response**: ``` HTTP/1.1 200 OK Content-Type: application/json Content-Length: 85 Last-Modified: Mon, 17 Mar 2025 10:00:00 GMT ``` **Common use cases**: Checking if a large file exists before downloading, validating cache freshness, monitoring API endpoint availability. ### OPTIONS: Discover Supported Methods **Purpose**: Returns the HTTP methods and communication options supported by a given URL. **Best Practices**: - OPTIONS is used heavily in CORS (Cross-Origin Resource Sharing) preflight requests. - Include an `Allow` header when the response is intended to enumerate supported methods. An `Allow` header is required for a `405 Method Not Allowed` response, but not for every possible OPTIONS response. - Use OPTIONS to build self-documenting APIs. **Example**: ``` OPTIONS /users HTTP/1.1 Host: api.example.com ``` **Response**: ``` HTTP/1.1 200 OK Allow: GET, POST, OPTIONS Access-Control-Allow-Origin: https://app.example.com Access-Control-Allow-Methods: GET, POST, OPTIONS Access-Control-Allow-Headers: Content-Type, Authorization Access-Control-Max-Age: 86400 ``` ### TRACE: Diagnostic Loop-Back Test **Purpose**: Echoes the received request back to the client, allowing you to see what intermediate proxies or gateways may have modified. **Best Practices**: - TRACE is primarily a debugging tool — it is rarely used in production APIs. - **Disable TRACE in production** to prevent cross-site tracing (XST) attacks. - Verify the behavior of each server and gateway in the request path instead of assuming TRACE is disabled by default. **Example**: ``` TRACE /users HTTP/1.1 Host: api.example.com ``` > **Security warning**: TRACE reflects request data and can expose sensitive fields when a server or intermediary handles it incorrectly. Disable or tightly restrict it unless you have a controlled diagnostic requirement. ### CONNECT: Establish a Tunnel **Purpose**: Ask a proxy to establish a tunnel to the host and port identified by the request target. CONNECT is most commonly associated with creating a TCP tunnel for HTTPS traffic through an HTTP proxy. **Best Practices**: - Allow CONNECT only to approved destinations and ports. - Authenticate and log tunnel requests at the proxy boundary. - Do not expose an unrestricted CONNECT proxy to untrusted clients. **Example**: ``` CONNECT api.example.com:443 HTTP/1.1 Host: api.example.com:443 ``` If the proxy permits the tunnel, it returns a successful 2xx response and then forwards bytes in both directions. CONNECT is not a CRUD method and is uncommon in ordinary REST API resource design. ## Common Mistakes and How to Avoid Them ### 1. Misusing HTTP Methods **Mistake**: Using GET for operations that modify data (e.g., `GET /users/123/delete`). **Solution**: Use the method whose requested semantics match the operation — DELETE for deletions, POST for creation or processing, and PUT/PATCH for updates. A GET endpoint must not ask the server to change resource state; incidental effects such as logging or metrics collection do not change that safety classification. ### 2. Ignoring Idempotency **Mistake**: Designing non-idempotent PUT or DELETE endpoints (e.g., a DELETE that decrements a counter). **Solution**: Ensure that repeating the same PUT or DELETE request has the same effect. This makes your API resilient to network retries. ### 3. Returning Incorrect Status Codes **Mistake**: Returning `200 OK` for every response, including errors. **Solution**: Choose status codes based on the outcome. Examples include `201 Created` when POST creates a resource, `202 Accepted` for asynchronous processing, `204 No Content` for a successful response without a body, `400 Bad Request` for invalid input, and `404 Not Found` for a missing resource. ### 4. Overloading POST for Everything **Mistake**: Using POST for all operations, including reads, updates, and deletes. **Solution**: Use the method whose semantics match the operation. POST is appropriate for resource-specific processing, including creation and actions that do not map cleanly to PUT, PATCH, or DELETE. ### 5. Confusing PUT and PATCH **Mistake**: Using PUT to update a single field, sending an incomplete resource representation. **Solution**: Use PATCH for partial updates. Use PUT only when you have the complete replacement resource. ## HTTP Methods and API Gateways An [API gateway](https://api7.ai/learning-center/api-gateway-guide/what-is-an-api-gateway) can enforce correct HTTP method usage across all your APIs: - **Route by method**: Direct GET requests to read replicas and POST/PUT/PATCH to write endpoints. - **Method restrictions**: Block unsafe methods (PUT, DELETE) on public endpoints that should be read-only. - **CORS handling**: Automatically respond to OPTIONS preflight requests without hitting your backend. - **Rate limiting by method**: Apply stricter [rate limits](https://api7.ai/blog/token-bucket-vs-leaky-best-rate-limiting-algorithm) to write operations (POST, PUT, DELETE) than reads (GET). API gateways like [Apache APISIX](https://api7.ai/apisix) and [API7 Enterprise](https://api7.ai/enterprise) provide built-in support for method-based routing, rate limiting, and security policies. ## Frequently Asked Questions ### How many HTTP methods are there? RFC 9110 defines eight HTTP methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, and TRACE. RFC 5789 defines PATCH, bringing the core set commonly discussed for APIs to nine. The IANA HTTP Method Registry also includes standardized extension methods such as WebDAV's PROPFIND, COPY, MOVE, and LOCK. ### What is the difference between GET and POST? GET retrieves data and should not change server-side state. POST submits data to create a resource or trigger a server-side action, so it usually has a request body and is not idempotent. ### What is the difference between POST and PUT? POST is commonly used when the server decides the new resource URL, such as `POST /users`. PUT is used when the client updates or replaces a known resource URL, such as `PUT /users/123`, and the same request can be retried safely. ### What is the difference between PUT and PATCH? PUT creates or replaces the state of a resource at a known URI using a representation defined by the API contract. PATCH applies a set of partial modifications using a patch document. Use PUT when replacement semantics match your contract; use PATCH when the client needs to describe only the changes. ### What are safe and idempotent HTTP methods? Safe methods (GET, HEAD, OPTIONS, TRACE) do not ask the server to change state. Idempotent methods (GET, HEAD, PUT, DELETE, OPTIONS, TRACE) have the same intended effect whether an identical request is made once or multiple times. POST is not idempotent by definition; PATCH can be designed to be idempotent but is not guaranteed to be. ### Can GET requests have a request body? RFC 9110 assigns no generally defined semantics to content in a GET request and warns that some implementations may reject it because of request-smuggling risks. Avoid GET content unless the origin server explicitly supports it and every intermediary in the request path is known to handle it safely. Otherwise, use query parameters or a method whose content semantics match the operation. ### What HTTP method should I use to update a resource? Use **PUT** when the client is supplying the replacement representation for a known URI. Use **PATCH** when the client is supplying a patch document that describes partial changes. In both cases, document validation, concurrency controls, and omitted-field behavior in the API contract. ## Conclusion HTTP methods are the cornerstone of RESTful API design. The nine standard HTTP methods — GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE, and CONNECT — provide a predictable, standardized vocabulary for client-server communication. By using the correct method for each operation, following idempotency rules, and returning appropriate status codes, you build APIs that are intuitive, scalable, and maintainable. ## Next Steps Deepen your API development knowledge with these related guides: - **[RESTful API Best Practices](https://api7.ai/learning-center/api-101/restful-api-best-practices)** — Learn how to design REST APIs that correctly leverage HTTP methods for clean, intuitive endpoints. - **[OpenAPI Specification](https://api7.ai/learning-center/api-101/openapi-specification)** — Document your HTTP methods, parameters, and responses in the industry-standard OpenAPI format. - **[What Is an API Key?](https://api7.ai/blog/what-is-api-key-why-need-them-complete-guide)** — Secure your API endpoints with key-based authentication, commonly applied per HTTP method. - **[What Is an API Gateway?](https://api7.ai/learning-center/api-gateway-guide/what-is-an-api-gateway)** — See how API gateways enforce method-based routing, rate limiting, and security at scale. - **[Token Bucket vs Leaky Bucket Rate Limiting](https://api7.ai/blog/token-bucket-vs-leaky-best-rate-limiting-algorithm)** — Understand the algorithms behind method-aware rate limiting in production APIs. - **[Postman API Development Environment](https://api7.ai/learning-center/api-101/postman-api-development-environment)** — Test all HTTP methods interactively with the most popular API development tool. - **[API7 Enterprise](https://api7.ai/enterprise)** — Enforce method-based routing, rate limiting, and authentication across every API from a single gateway platform. Eager to deepen your knowledge about API gateways? Follow [our LinkedIn](https://sg.linkedin.com/company/api7-ai) for valuable insights delivered straight to your inbox! If you have any questions or need further assistance, feel free to contact [API7 Experts](https://api7.ai/contact). [Previous article**API Endpoints: Designing and Managing for Scalability and Security**](https://api7.ai/learning-center/api-101/what-are-api-endpoints)[Next article**API Rate Limiting Best Practices and Algorithms**](https://api7.ai/learning-center/api-101/api-rate-limiting) On this page - [HTTP Methods at a Glance](#http-methods-at-a-glance) - [GET vs POST vs PUT vs PATCH vs DELETE: Quick Decision Table](#get-vs-post-vs-put-vs-patch-vs-delete-quick-decision-table) - [Quick Summary List](#quick-summary-list) - [What Are HTTP Methods in APIs?](#what-are-http-methods-in-apis) - [Why Are HTTP Methods Important in API Design?](#why-are-http-methods-important-in-api-design) - [1. Standardization and Clarity](#1-standardization-and-clarity) - [2. Resource Management](#2-resource-management) - [3. Scalability and Maintainability](#3-scalability-and-maintainability) - [All 9 Core HTTP Methods Explained](#all-9-core-http-methods-explained) - [GET: Retrieve Data](#get-retrieve-data) - [POST Request Method: Create or Submit Data](#post-request-method-create-or-submit-data) - [PUT: Replace a Resource Entirely](#put-replace-a-resource-entirely) - [PATCH: Partially Update a Resource](#patch-partially-update-a-resource) - [What Is the Difference Between PUT and PATCH?](#what-is-the-difference-between-put-and-patch) - [DELETE: Remove a Resource](#delete-remove-a-resource) - [HEAD: Retrieve Headers Only](#head-retrieve-headers-only) - [OPTIONS: Discover Supported Methods](#options-discover-supported-methods) - [TRACE: Diagnostic Loop-Back Test](#trace-diagnostic-loop-back-test) - [CONNECT: Establish a Tunnel](#connect-establish-a-tunnel) - [Common Mistakes and How to Avoid Them](#common-mistakes-and-how-to-avoid-them) - [1. Misusing HTTP Methods](#1-misusing-http-methods) - [2. Ignoring Idempotency](#2-ignoring-idempotency) - [3. Returning Incorrect Status Codes](#3-returning-incorrect-status-codes) - [4. Overloading POST for Everything](#4-overloading-post-for-everything) - [5. Confusing PUT and PATCH](#5-confusing-put-and-patch) - [HTTP Methods and API Gateways](#http-methods-and-api-gateways) - [Frequently Asked Questions](#frequently-asked-questions) - [How many HTTP methods are there?](#how-many-http-methods-are-there) - [What is the difference between GET and POST?](#what-is-the-difference-between-get-and-post) - [What is the difference between POST and PUT?](#what-is-the-difference-between-post-and-put) - [What is the difference between PUT and PATCH?](#what-is-the-difference-between-put-and-patch-1) - [What are safe and idempotent HTTP methods?](#what-are-safe-and-idempotent-http-methods) - [Can GET requests have a request body?](#can-get-requests-have-a-request-body) - [What HTTP method should I use to update a resource?](#what-http-method-should-i-use-to-update-a-resource) - [Conclusion](#conclusion) - [Next Steps](#next-steps)