Please note the question has changed/been clarified since this answer was first written. A further response to the latest iteration of the question is after the second horizontal rule
What is the need of methods like GET and POST in the HTTP protocol?
They, along with a few other things like header formats, rules for how headers and bodies are separated, form the basis of the HTTP protocol
Can we not implement the HTTP protocol using just a request body and a response body?
No, because then whatever you created wouldn't be the HTTP protocol
Congratulations, you just invented a new protocol! Now, if you want to set up a standards body to drive and maintain it, develop it etc, it could overtake HTTP one day
I appreciate this is a bit tongue in cheek, but there's nothing magical about the internet, TCP/IP or the communication that goes on between servers and clients. You open a connection and send some words down the wire, forming a conversation. The conversation really needs to adhere to some ratified spec at both ends if the requests are to be understood and sensible responses delivered. This is no different to any dialog in the world. You speak English, your neighbor speaks Chinese. Hopefully your hand waving, pointing and fist shaking will be sufficient to convey your message that you don't want him parking his car in front of your house.
Back on the internet, if you open a socket to a web server that is HTTP compliant and send the following:
(The start of an SMTP email transmission) then you wont get a sensible answer. You could craft the most perfect SMTP compliant client, but your webserver won't talk to it because this conversation is all about the shared protocol - no shared protocol, no joy.
This is why you can't implement the HTTP protocol without implementing the HTTP protocol; if what you write does not conform to protocol, then it simply isn't the protocol - it's something else, and it won't work as specified in the protocol
If we run with your example for a moment; where the client connects and just states something that looks like a URL.. And the server understands it and just sends something that looks like HTML/JS (a webpage) then sure, it could work. What did you save though? Couple of bytes on not saying GET? Few more on ditching those pesky headers.. The server saved some too - but what if you can't work out what it sent you? What if you asked for a URL that ended in JPEG, and it sent you some bytes that make a picture, but it's in PNG? An incomplete PNG at that. If only we had a header that said how many bytes it was going to send, then we'd know if the number of bytes we received was actually the whole file or not. What if the server gzipped the response to save some bandwidth but didn't tell you? You're going to spend some considerable computing power trying to work out what it sent.
At the end of the day, we need metainformation - information about information; we need headers; we need files to have names, extensions, created dates. We need people to have birthdays, to say please and thankyou etc - the world is full of protocol and bits of info about the context so we don't have to sit down and work everything out from scratch all the time. It costs a bit of storage space, but it's easily worth it
Is implementing various HTTP methods really needed?
Arguably, one doesn't have to implement the entire specified protocol, and this is usually true for anything. I don't know every word in the English language; my Chinese neighbor is also a software developer but in a different industry and he doesn't know even the Chinese for some of the terms used in my industry let alone the English. The good thing is though, we can both pick up a document on the implementation of HTTP, he can write the server and I can write the client, in different programming languages on different architectures, and they still work because they adhere to protocol
It may well be the case that none of your users will ever issue anything other than a GET request, won't use persistent connections, send anything other than JSON as the body, or need to accept anything other than text/plain so you could write a really pared down web server that only meets the very limited demands of the client browser. But you couldn't just arbitrarily to decide to do away with the basic rules that make "some text passing down a socket" what HTTP is; you can't ditch the basic notion that the request will be a string like:
VERB URL VERSION
And the response will have a version, and status code and maybe headers. If you change any of that - it's not HTTP any more - it's something else, and will only work with something that's designed to understand it. HTTP is what it is by these definitions, so if you want to implement it, you have to follow the definitions
Your question has evolved a bit, here's some response to what you ask:
Why does HTTP protocol have notion of methods?
Historically you need to appreciate that things were a lot more inflexible in their design and implementation, even to the extent that scripting didn't exist and even the notion that pages could be dynamic, generated on the fly in memory and pushed down the socket instead of being a static file on disk that was requested by the client and read and pushed down the socket, didn't exist. As such the very early web centred around the notion of static pages that contained links to other pages, all the pages existed on disk and navigation would have been by the terminal mostly making GET requests for pages at URLs, the server would be able to map the url to a file on disk and send it. There was also this notion that the web of documents that linked to each other and off to elsewhere should be an evolving, evolvable thing so it made sense for a suite of methods to exist, to allow suitably qualified permitted users to update the web without necessarily having access to the server file system- cue the use case for the likes of PUT and DELETE, and other methods like HEAD returned just meta information about a document so the client could decide whether to GET it again (remember that we are talking about the days of dialup modems, really primitive slow tech. It could be a great saving to get the meta of a half megabyte file and see it hadn't changed and server up the local copy from cache rather than download again
That gives some historical context for the methods- once upon a time the URL was the inflexible bit, and simplistically referred to pages on disk so the method was useful because it allowed the client to describe what intention it had for the file and the server would process the method in some varying way. There wasn't really a notion of urls being virtual or used for switching or mapping in the original vision of a hypertext (and it really was Text only) web
I'm not intending for this answer to be a documentation of the historical record with dates and cited references of exactly when things started to change - for that you can probably read Wikipedia - but it's sufficient to say that over the time the desire for the web to be more gathered momentum and at each end of the server-client connection the opportunities for creating a rich multimedia experience we're expanding. Browsers supported a huge proliferation of tags for formatting content, each one racing to implement must-have media richness features and new ways of making things look snazzy.
In making modern multi megabyte pages probably only a fraction of it is now fixed content on a disk; database data is formatted and shaped into html that the browser will consume and it's done by the server in response to multiple different programming routines being referenced in some way by the url
I mentioned in the comments to the question that it's a bit like full circle. Back when computers cost hundreds of thousands and filled rooms it was common to allow multiple users to use the one super powerful central mainframe by way of hundreds of dumb terminals - a key board and mouse, a green screen, send some text in, get some text out. Over the time as computing power increased and prices came down, people started ending up with desk computers more powerful than early mainframes and the ability to run powerful apps locally so the mainframe model became outdated. It never went away though, because things just evolved to shift the other way and somewhat revert to a central server providing most of the useful app functionality and a hundred client computers that do very little except draw on the screen, and submit and receive data to/from the server. That interim period where your computer was smart enough to run its own copy of word and outlook at the same time has again given way to office online, where your browser is a device for drawing pictures on the screen and editing the document/email you're writing as a thing that lives on the server, is saved there, sent and shared with other users all as the notion that the browser is just a shell that provides a partial view at any one time of this thing that lives elsewhere
From the answers, I get some sense of why concept of methods is there..This leads to another related question:
For example in gmail compose link, the PUT/POST request and data will be sent. How does the browser come to know which method to use?
It uses GET by default, by convention/spec as that's what is decreed shall happen when you type a url and press return
Does the gmail page sent by server include the method name to use when calling gmail compose request?
This is one of the key things I allude to in the comments above. In the modern web it's not even about pages any more. Once pages were files on disk, that the browser would GET. Then they became pages that were predominantly generated dynamically by slotting data into a template. But it still involved a "request a new page from the server, get a page, show page" process. The page swapping got really slick; you didn't see them load and resize and jerk their layout around so it loooed smoother but it was still the browser replacing one entire page or part of a page with another
The modern way of doing things is with a single page application; the browser has a document in memory that is displays in a certain way, scripting calls to the server and gets some nugget of info back, and manipulates the document so that part of the page changes visually to show the new info- the whole things runs without the browser ever loading another new page; it's just become a UI where parts of it update just like a typical client app like word or outlook. New elements appear on top of other elements and can be dragged around simulating dialog windows etc. All this Is the browser scripting engine sending requests using whatever http method the developer wants, getting data back and poking at the document that the browser is drawing. You can conceive that the modern browser is a brilliant device that is something like an entire operating system or virtual computer; a programmable device that has a fairly standardized way of drawing things on screen, playing sound, capturing user input and sending it for processing. All you have to do to make it draw your UI is provide it with some html/css that makes a UI then tweak the html constantly to make the browser change what it is drawing. Heck, people are so used to seeing the address bar change/using it as a direction of intent that a single page app will change the url programmatically even though no navigation (requesting whole new pages) is being done
when we call www.gmail.com , it must be using GET method, how does the browser know that this method to use?
It is indeed a GET. Because it is specified. The first request is as it historically always has been- GET some initial html to draw a UI, then either poke and manipulate it forever, or get another page with other script that pokes and manipulates and makes a responsive reactive UI
As some answers tell, we can create new users on DELETE method, then this raises question the intention behind notion of methods in http protocol, because at the end of the day, it totally depends on servers what function they want to map an URL to. Why should client tell servers what methods to use for an URL.
History. Legacy. We could theoretically toss all the http methods out tomorrow- we're at a programming sophistication level where methods are obsolete because URLs are processable to the extent that they can be the switching mechanism that indicates to the server that you want to save the data in the body as a draft email, or delete a draft - there isn't a /emails/draft/save/1234 file on the server - the server is programmed to pick that url apart and know what to do with the body data- save it as a draft email under id 1234
So it is certainly possible to do away with methods, except for the huge weight of legacy compatibility that grew up around them. It's better to just use them for what you need to but largely ignore them and instead use whatever you need to get your thing working. We still need methods as specified because you have to remember that they mean something to the browser and the server on top of which we have created our apps. The client side script wants to use the underlying browser to send data, it needs to use a method that will make the browser do as it asks- probably a POST because GET packs all its variable info into the url and that has a limit on length in a lot of servers. The client wants a long response from the server - don't use a HEAD because they aren't supposed to have response bodies at all. Maybe your chosen browser and server don't have any restrictions, but maybe one day they will each encounter a different implementation at the other end that does - and in the spirit of interoperation, sticking to a spec makes it work better