# HTTP Methods (/academy/http-methods)



**HTTP methods** are the verbs. The path is the noun. Together they are an [endpoint](/academy/endpoint).

* `GET` — show me. Nothing should change.
* `POST` — make one that was not there.
* `PUT` / `PATCH` — change one that was.
* `DELETE` — throw it out.

Devs nickname the set CRUD. You already press these buttons. Refresh a list. Submit a form. Edit a title. Hit trash. The [API](/academy/api) is the same four moves with fancier names.

**The verb that matches the job**

Browsers `GET` when you click a link. Forms `POST`. Everything else is JavaScript being explicit. Using `GET` to delete a user is how you bookmark a disaster. A prefetch, a crawler, a curious judge — anyone who opens the URL does the damage.

`GET` is safe to repeat. Ten reads is ten reads. `POST` is not. A double-click, a flaky retry, a refresh on "payment processing" can create two charges. That is why checkout pages beg you not to reload.

[REST](/academy/rest) puts those verbs on nouns. The [builder](/builder) will generate routes that already do this. If you invent `/api/doThing` as a `GET`, your [agent](/academy/agent) will still call it. The [database](/academy/database) will still notice.

**On stage**

If the list is empty, you have a GET problem. If the row never appears, you have a POST problem. Name the verb before you rewrite the [stack](/academy/stack). A [webhook](/academy/webhook) is almost always a `POST` into a slot you own. Treat it like a create: verify, then write.

**What this unlocks**

Once you hear "it's a POST," you hear "something new is supposed to exist."

Look, add, change, toss. Four verbs. That is the whole conversation at the window.
