HTTP Methods Every Web Developer Must Know
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
I’ve been programming web for years and I saw a lot of so-called web programmers doing web programming in their own preferred language. Most of them I’ve known were using PHP while a small group of them use Ruby and Python. But the languages doesn’t make any differences when it comes to HTTP Method.
A few weeks ago, I’ve worked with someone who really has expertise in PHP and has doing PHP for 6 years, give or take. I really love working with him as his knowledge about PHP overtakes mine and I do love to learn from him. One thing that I missed about was when he was using the wrong method for particular HTTP requests. He used GET where he should used POST, recklessly using (again!) GET instead of DELETE. But when I asked him about whether he was understand in what he’s doing, he answered, “it works. From the first day I learn PHP, it still works.”
I don’t want to judge him and throw all the mistakes on everything he read but this is dangerous as he will, in the future, be working with a beginner programmer in pair-programming. He could mistakenly put the wrong concepts and mix things up between GET, POST, PUT and DELETE (and another not-so-famous method in HTTP).
Trying so hard to remember all HTTP methods (and all their purposes) is just as hard as writing “Hello World” in Java without using an IDE for beginners. If you’re a web veteran and can spell all HTTP methods without thinking then you should not wasting your time reading this. Go get your things done. To those who are still confused and don’t care before about those methods, go read ahead.
The Four (Plus One) Elements
Two of them are probably the most frequently used by you and two (plus one) of them are rarely use even though most of programmers are aware of their existence.
“I get something!”
“Get the data and back off!”
As you might know, GET should always only getting the data from the specified resources and should not create any action other than retrieval. If you want to save the data to database, modify files, etc., do not use GET. This is important as GET (and HEAD, see below) is considered “safe”.
We can say that this is the light version of GET because HEAD is actually the same as GET but ignoring the response body. When do we use HEAD instead of GET? Testing links, check for modifications, etc., that is for something that you didn’t need to read the response body and just okay with the response header.
If GET retrieved the data then POST is a method to store data, create new resources, etc. POST to GET is like “write” to “read”. Pretty simple. (You might be wondering why I simplify things and not telling the truth about the vary responses, whether it’s 200, 201, or 204. If you’re really curious about those response codes, please refer to RFC2616: HTTP Status Code Definitions. ).
PUT, simply put, is practically the same with POST. The difference between PUT and POST is in its behavior. Read this explanation for a brief and easy-to-understand answer.
As the name suggests, DELETE is the “opposite” of PUT. Again, DELETE to PUT is like “erase” to “write”. No big deal. (I know some people who use POST to delete or destroy the data/resource but that should not happened).
“So if PUT and DELETE are identical with POST, why we would do something using PUT and DELETE instead of POST?“, you asked.
PUT and DELETE is idempotency. I repeat, idempotency. No matter how much you use PUT or DELETE, if you do that more than one within the same resource, it will be counted as one. This rule is not applicable for POST as everytime you do the POST, the (same) data will be stored/created over and over again. Elliotte Rusty Harold explained about this in an interview six years ago.