Think about filling out a form at a service counter. The counter may be the same, but what you write at the top matters: “Request a copy.” “Create a new account.” “Cancel this record.” The clerk needs the verb before they know what to do with the form. HTTP methods are those verbs for the web.
How it shows up
The common ones are GET, POST, PUT, PATCH, and DELETE. GET usually reads something, POST creates or submits something new, PUT and PATCH update (PATCH usually a smaller update), and DELETE removes. The URL matters, but the method changes the meaning: hitting an endpoint with GET might say “Show me this customer,” while DELETE says “Remove this customer.” Same counter, very different form.
HTTP methods also connect to CORS: a browser may allow one kind of request and block another, checking whether this page is allowed to make that request to that place.
Why you care
This is why API work feels picky. To connect to a REST API, an agent has to know the address, the method, the required fields, and what answer to expect, and a tiny mismatch turns into an error. If it uses POST when it should use PATCH, it may create a duplicate instead of updating the original, and DELETE in the wrong place is a much bigger problem. You don’t need to memorize web standards. The point is that “call the API” is never vague to software. It has to say exactly what it wants, every time.