programing – SamoSkill

In web development and API design, HTTP request methods often referred to as HTTP verbs define the intended action to be performed on a specific resource identified by a Uniform Resource Identifier (URI). Defined in the Internet Engineering Task Force (IETF) specifications (RFC 7231 and RFC 5789), these standard methods establish a clear contract between clients and servers in web applications and RESTful architectures. Core HTTP Characteristics: Safety and Idempotency Before examining individual methods, two fundamental HTTP properties must be understood: Safe Methods: HTTP methods that do not modify state on the target server. They are strictly read-only operations (e.g., retrieving data). Idempotent Methods: HTTP methods that produce the exact same server-side state whether executed once or repeated multiple consecutive times with identical parameters. 1. The GET Method The GET method requests a representation of the specified resource. It is the primary vehicle for retrieving data across the web. Characteristics & Behavior Primary Purpose: Fetching data (documents, image files, database records). Safe: Yes (read-only; causes no side effects on the server). Idempotent: Yes (making the same GET request 1 time or 100 times yields the same server state). Request Body: Standard HTTP specifications advise against sending a payload body in a GET request; parameters are instead passed as URL query strings (e.g., /api/users?status=active&page=2). Cacheability: Highly cacheable by web browsers, CDNs, and proxy servers. Typical Example HTTP GET /api/v1/products/104 HTTP/1.1 Host: api.example.com Accept: application/json 2. The POST Method The POST method submits an entity to the specified resource, causing a change in state or side effects on the server. It is primarily used to create new entities or trigger processing operations. Characteristics & Behavior Primary Purpose: Resource creation, form processing, or triggering background jobs. Safe: No (creates or mutates data). Idempotent: No (submitting the exact same POST request twice will typically create two duplicate records). Request Body: Contains the payload to be processed, structured in formats like application/json, application/x-www-form-urlencoded, or multipart/form-data. Expected Response: Typically returns HTTP 201 Created along with a Location header pointing to the newly generated resource URL. Typical Example HTTP POST /api/v1/users HTTP/1.1 Host: api.example.com Content-Type: application/json { "name": "Aisha Omar", "email": "aisha@example.com", "role": "Engineer" } 3. The PUT Method The PUT method replaces all current representations of the target resource with the request payload. It represents an "upload" or "full update" operation. Characteristics & Behavior Primary Purpose: Creating or completely replacing a specific resource at a defined URI. Safe: No (modifies server state). Idempotent: Yes (overwriting a record with the exact same full payload multiple times leaves the state unchanged after the first request). PUT vs. POST: While POST creates a resource under a parent URI (server assigns the ID), PUT targets the exact resource URI directly (client specifies or targets the existing ID). Typical Example HTTP PUT /api/v1/users/42 HTTP/1.1 Host: api.example.com Content-Type: application/json { "name": "Aisha Omar", "email": "aisha.updated@example.com", "role": "Lead Engineer" } Note: If any optional field is omitted in a standard PUT payload, the server typically clears or sets that field to null. 4. The PATCH Method Introduced in RFC 5789, the PATCH method applies partial modifications to a resource rather than replacing it entirely. Characteristics & Behavior Primary Purpose: Modifying specific fields of an existing entity without re-sending the entire resource representation. Safe: No. Idempotent: Not inherently required by spec, though often implemented idempotently depending on payload design (e.g., setting status = "active" vs. increment_counter = 1). Bandwidth Efficiency: Saves significant bandwidth when dealing with massive database records or complex entities. Typical Example HTTP PATCH /api/v1/users/42 HTTP/1.1 Host: api.example.com Content-Type: application/json { "email": "aisha.newemail@example.com" } 5. The DELETE Method The DELETE method requests the removal of the specified resource from the server. Characteristics & Behavior Primary Purpose: Deleting records, files, or entities. Safe: No. Idempotent: Yes (calling DELETE /users/42 once removes the resource; calling it a second time results in the resource remaining gone, typically returning 404 Not Found or 204 No Content). Expected Response Statuses: 200 OK (includes a status message payload) 204 No Content (deletion succeeded, no response body returned) 202 Accepted (deletion task queued asynchronously) Typical Example HTTP DELETE /api/v1/users/42 HTTP/1.1 Host: api.example.com Authorization: Bearer 6. The OPTIONS Method The OPTIONS method requests information about the communication options available for the target URI or server capabilities without initiating an actual data operation. Characteristics & Behavior Primary Purpose: Inspecting allowed HTTP verbs and handling Cross-Origin Resource Sharing (CORS) Preflight checks executed automatically by web browsers. Safe: Yes. Idempotent: Yes. Key Header: Server returns an Allow header listing permitted methods (e.g., Allow: GET, POST, OPTIONS). Typical Example (CORS Preflight Request) HTTP OPTIONS /api/v1/users HTTP/1.1 Host: api.example.com Origin: https://dashboard.example.com Access-Control-Request-Method: POST Access-Control-Request-Headers: Content-Type, Authorization Server Response HTTP HTTP/1.1 204 No Content Access-Control-Allow-Origin: https://dashboard.example.com Access-Control-Allow-Methods: GET, POST, OPTIONS Access-Control-Allow-Headers: Content-Type, Authorization Comprehensive HTTP Verbs Comparison Matrix MethodCRUD EquivalentSafe?Idempotent?Allows Request Body?Typical Success Status CodeGETReadYesYesNo / Not Recommended200 OKPOSTCreateNoNoYes201 CreatedPUTUpdate (Replace)NoYesYes200 OK / 204 No ContentPATCHUpdate (Partial)NoNo (Usually Yes)Yes200 OK / 204 No ContentDELETEDeleteNoYesOptional / Rare200 OK / 204 No ContentOPTIONSMeta / InspectYesYesNo200 OK / 204 No Content Best Practices & Common Pitfalls Never use GET for state-changing actions: Triggering deletions or creations via GET /delete-user?id=5 breaks web indexing crawlers (e.g., Googlebot following links and accidentally deleting database rows) and breaches HTTP safety guarantees. Distinguish PUT from PATCH: Use PUT when supplying a complete replacement entity; use PATCH when sending delta changes for targeted field updates. Handle Idempotency in Payment & Order Processing: Because POST is non-idempotent, network retry logic can lead to double billing. API architects address this by embedding an Idempotency-Key header into critical POST headers. Return Appropriate Status Codes: Match methods with semantic status codes (201 for POST creation, 204 for body-less DELETE/PUT, 405 Method Not Allowed when a route rejects a specific verb). https://samoskill.com/http-status-codes-errors-explained-2xx-3xx-4xx-5xx/ https://samoskill.com/understanding-client-server-architecture-and-how-the-internet-works/ https://samoskill.com/understanding-web-architecture-front-end-vs-back-end-development/ https://samoskill.com/how-to-become-a-software-engineer-in-2026-complete-career-guide/ https://samoskill.com/python-vs-javascript-which-programming-language-should-you-learn-first-in-2026/