DELETE
/dɪ-ˈliːt/
n. “Gone. No take-backs.”
DELETE is an HTTP request method used to remove a resource from a server. When a client issues a DELETE request to a specific URI, the server is instructed to permanently remove that resource, or at least mark it as deleted depending on implementation. Unlike PATCH or PUT, which modify resources, DELETE is purely destructive — its purpose is removal.
For example, sending a DELETE request to /users/123 would instruct the server to remove the user with ID 123 from its database. The operation should be idempotent: sending the same DELETE request multiple times should have the same effect as sending it once, meaning that after the first deletion, subsequent requests typically result in a 404 Not Found or equivalent response.
In RESTful APIs, DELETE is used alongside GET, POST, PUT, and PATCH to provide full CRUD (Create, Read, Update, Delete) capabilities. Its idempotency is a key design principle: clients can retry DELETE safely without risking duplicate deletions.
Security considerations are critical when implementing DELETE. Servers must ensure that the client is authenticated and authorized to delete the resource. Logging deletions, requiring confirmation, or using soft deletes (marking a resource as inactive rather than removing it entirely) are common strategies to prevent accidental data loss.
In practical use, DELETE enables administrators to manage resources, clean up outdated data, or remove sensitive information. For instance, a SaaS platform may allow users to delete their accounts, or an application may remove obsolete entries from a database. When combined with TLS encryption, DELETE requests can be securely transmitted over the network.
Overall, DELETE is a fundamental web method for removal operations. While simple in concept, proper implementation ensures consistency, prevents unintended data loss, and maintains the integrity of modern APIs and web applications.
PATCH
/pætʃ/
n. “Fix it, tweak it, change just what’s needed.”
PATCH is an HTTP request method used to apply partial modifications to a resource on a server. Unlike PUT, which replaces the entire resource, PATCH allows clients to send only the fields or sections that need updating. This makes PATCH ideal for efficient updates where only a small portion of a resource has changed.
For example, if a user profile exists at /users/123 and only the email address needs to be updated, a PATCH request can include just the new email field rather than sending the entire profile data. This reduces bandwidth usage and lowers the risk of accidentally overwriting unrelated fields.
In RESTful APIs, PATCH is used alongside PUT, POST, GET, and DELETE to provide a complete CRUD toolkit. While PUT is idempotent (repeating the request results in the same state), PATCH can be non-idempotent depending on how the server applies the changes, so developers should implement it carefully.
Common uses of PATCH include updating user preferences, adjusting configurations, or modifying specific fields in a document without touching the rest. API designers often combine PATCH with JSON or XML payloads specifying the exact keys or paths to modify.
Security considerations include authenticating the client, validating input data, and ensuring authorization for partial updates. Encryption via TLS is recommended to protect sensitive data in transit. Proper implementation prevents unintended changes or corruption of the resource.
In essence, PATCH gives developers surgical precision for resource updates. It is a flexible tool that complements PUT and POST, allowing modern web applications, SaaS platforms, and APIs to operate efficiently, minimize errors, and maintain data integrity while handling incremental changes.
PUT
/pʊt/
n. “Replace it, overwrite it, make it exactly this.”
PUT is an HTTP request method used to update or replace a resource on a server with the data provided in the request body. Unlike POST, which typically creates a new resource or triggers an action, PUT is idempotent — sending the same request multiple times results in the same state on the server without creating duplicates.
For example, if a web application manages user profiles at /users/123, sending a PUT request with updated data such as name, email, or preferences will replace the existing profile with the new content. Repeating this request does not duplicate the profile — it simply enforces the specified state.
In RESTful APIs, PUT is often paired with resource URLs to indicate exactly which entity should be replaced. If the resource does not exist, some implementations may create it (sometimes referred to as “upsert”), though this behavior depends on the API specification.
PUT requests require the client to send the complete representation of the resource. Partial updates are usually handled by PATCH, which modifies only specified fields. This distinction ensures that PUT operations are predictable and consistent.
Security considerations include validating and sanitizing all incoming data, ensuring that only authorized users can modify the resource, and encrypting requests with TLS to protect data in transit. In modern web development, PUT is frequently used for updating user data, configurations, or documents via APIs in SaaS or cloud platforms like IaaS and PaaS.
In short, PUT enforces a precise server-side state, allowing developers to overwrite resources safely, predictably, and repeatedly without unintended duplication. It complements POST, GET, and DELETE to provide the essential toolkit of CRUD operations that power RESTful web services.
POST
/poʊst/
n. “Send it, trust it, let it change the world.”
POST is an HTTP request method used to submit data to a server, typically causing a change in server state or triggering an action. Unlike GET, which only retrieves information, POST is intended for creating or updating resources. The client packages data in the request body, which the server interprets according to the endpoint’s rules.
For example, when submitting a form on https://catenco.de/contact, your browser sends a POST request containing fields like name, email, and message. The server then processes this data, perhaps storing it in a database, sending an email, or triggering another workflow.
POST requests are not idempotent, meaning repeating the same request can result in multiple side effects — like creating duplicate entries or sending multiple emails. This is why it is commonly paired with confirmation mechanisms, such as redirect-after-submit patterns, to prevent accidental repetition.
In web development, POST is central to RESTful APIs, form submissions, and any action where client input modifies server state. Tools like fetch in JavaScript, curl in the terminal, or libraries like Axios simplify creating POST requests with structured payloads such as JSON or URL-encoded forms.
Security considerations are critical when using POST. Since the data resides in the request body, it is not visible in URLs, unlike GET query strings. However, POST data still travels over the network and should always be encrypted using TLS to prevent interception. Input validation and server-side sanitization are necessary to avoid injection attacks or unintended consequences.
POST requests also support sending files, multipart form data, and complex objects, making them versatile for modern web applications. APIs often define POST endpoints for creating new resources, processing transactions, or interacting with services like SaaS platforms.
In summary, POST is the workhorse method for sending data, triggering actions, and enabling interactivity on the web. It complements GET and other HTTP methods, forming the foundation of request-response architecture that powers websites, apps, and APIs today.
GET
/ɡɛt/
n. “Ask nicely, get the goods.”
GET is one of the core HTTP request methods used in the web ecosystem, primarily designed to retrieve data from a server. When a browser or client sends a GET request, it is asking the server to return a representation of a specific resource identified by a URL. Unlike other request methods, GET is considered safe and idempotent: it should not change the state of the server, and repeating the request yields the same result.
For example, when you visit https://catenco.de/whatis/MD5 in your browser, your client sends a GET request for that resource. The server responds with the page content, which your browser then renders. This simple exchange underpins almost every web interaction, from loading images and scripts to fetching JSON for dynamic applications.
GET requests can include query parameters, appended to the URL after a question mark. These parameters refine the request or provide additional context. For instance: https://catenco.de/search?q=SHA256 sends a GET request with the search term SHA256, allowing the server to return relevant results. Importantly, because GET URLs are visible in the browser and can be cached or bookmarked, sensitive information should never be sent this way.
In contrast to POST, which submits data that may modify server state, GET is for retrieval only. Its predictable, read-only nature makes it ideal for linking between pages, caching responses, and exposing public APIs. Many modern REST APIs rely heavily on GET for fetching resources, while other methods handle creation, updating, or deletion.
Developers must be mindful of URL length limits and encoding when using GET. Query strings must be properly encoded to ensure special characters, spaces, or symbols do not break the request. Tools like fetch in JavaScript or curl in the terminal allow easy testing and automation of GET requests for debugging, scraping, or API interaction.
In essence, GET is the polite web method: it asks the server for information, expects no side effects, and forms the backbone of internet browsing and API communication. Understanding GET, alongside its companions like POST, PUT, and DELETE, is fundamental for web developers, sysadmins, and anyone interacting with the web’s request-response model.