Question
How do the HTTP methods POST, PUT, GET and DELETE map to operations on data?
Answer
They map to create, update, read and delete (CRUD), the same four operations as SQL's INSERT, UPDATE, SELECT and DELETE.
| HTTP method | Database analogue | What it does to the resource |
|---|---|---|
| POST | INSERT | Creates a new resource (the server picks its URL), or more generally hands data to the server to process |
| PUT | UPDATE | Replaces the resource at the given URL with the request body, creating it if it does not exist |
| GET | SELECT | Reads the resource. It never changes it |
| DELETE | DELETE | Removes the resource |
The mapping matters for IoT because constrained protocols kept it. CoAP, the lightweight web protocol for small devices, uses the same GET, POST, PUT and DELETE over UDP, so a sensor reading is a GET and a configuration change is a PUT. A device that understands these four methods can be designed like a tiny web server: every reading, setting and actuator is a resource with a URL.
Go deeper:
MDN — HTTP request methods — every method with its exact semantics.- Wikipedia — Create, read, update and delete — the CRUD mapping across SQL, HTTP and other interfaces.
Note saved — thanks!
Question
GET must never change a resource. Why does that rule matter, and what goes wrong if an IoT server opens a door on a GET request?
Answer
GET is defined as safe: clients, browsers, proxies and crawlers may send it at any time, repeat it, prefetch it or cache it, assuming nothing happens. A door that opens on GET can be opened by a link preview, a prefetch or a retry, and the command is trivial to trigger and repeat.
HTTP gives methods two properties that the rest of the web relies on:
- Safe (GET, HEAD): the request only reads. Software may send it without asking the user.
- Idempotent (GET, PUT, DELETE): sending it twice has the same effect as sending it once, so a client may retry after a timeout. POST is neither safe nor idempotent, which is why browsers warn before resending a form.
A state-changing GET breaks those assumptions. A chat app generating a link preview fetches the URL and opens the door. A browser prefetching links does the same. A proxy may answer from its cache, so a later "open" never reaches the device. The URL ends up in browser history and server logs, and anyone who sees it can reuse it.
So actions go in POST (or PUT for "set the state to X"). This does not make the action secure: a POST can be sniffed and replayed just as well. It only keeps ordinary web infrastructure from triggering it by accident. Security needs authentication and freshness on top.
Go deeper:
- RFC 9110 — Safe methods — the normative definition, including why crawlers may follow GET links.
- MDN — Idempotent — which methods are idempotent and why retries depend on it.
Note saved — thanks!