APIs often support different methods (HTTP verbs) that communicate to the client/server what kind of action is taken at that endpoint. The two most common methods are GET and POST. There are several others (PUT, DELETE, HEAD, OPTIONS, TRACE, CONNECT), but we’re going to focus on GET and POST today.
Endpoints that employ GET do exactly that–they get information from the server and return the results to the requester. Endpoints that use POST usually make changes to the backend in some way–inserting, updating, or deleting something in the database for example. GET is called an idempotent method because its effect on the backend is the same whether the endpoint is hit once or multiple times. This can be true for POST requests too (e.g. /logout where username=”broberts” can be called one time or 100 times, and broberts–and only broberts–will be logged out), but in general, POST is not an idempotent method. RESTful APIs are stateless, so if you use GET at one endpoint, you should get the same response if you hit that endpoint again with the same parameters.
It’s important to note that HTTP methods don’t have special properties–from a functionality standpoint, anything you can do with GET you can do with POST (and vice versa). But that doesn’t mean that you should. One of the reasons it’s good not to make all your endpoints use GET is link prefetching. Browsers might prefetch pages (any GET request) that it thinks a user will visit soon. If your logout endpoint is prefetched, then users’ browsers might be logging them out via link prefetching as soon as they log in!
For more information, W3Schools has some great documentation that provides a closer look at the differences between GET and POST.
Ryan from The Bunch