What is the need of methods like GET and POST in the HTTP protocol?

Question

Can we not implement the HTTP protocol using just a request body and a response body?

For example, the URL will contain request, which will be mapped to a function depending on programming language on server side say a Servlet and in response HTML and JavaScript response will be sent across.

Why does HTTP protocol have notion of methods?

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? Does the gmail page sent by server include the method name to use when calling gmail compose request? when we call www.gmail.com , it must be using GET method, how does the browser know that this method to use?

PS : I don't have enough credits to comment on answers, so I am not able to comment on many questions raised by people related to intention behind this question.

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.

Answer 1

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

For example, the URL will contain request, which will be mapped to a function depending on programming language on server side say a Servlet and in response HTML and JavaScript response will be sent across.

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:

EHLO
AUTH LOGIN

(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
header: value

maybe_body

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

---

Update

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.

Scripting arrived on the client end and plugins and browser extensions, all aimed at making the browser into a vastly capable powerhouse of everything. At the server end active generation of content based on algorithms or database data was the big push and it continues to develop to the extent that there are probably few files on disk any more - sure, we keep a picture or script file as a file on the web server and have the browser GET it, but increasingly the pictures the browser shows and the scripts it runs aren't files you can open in your file explorer, they're generated content that is the output of some compilation process done on demand, SVG that describes how to draw pixels rather than a bitmap array of pixels, or JavaScript that was emitted from a higher level form of script like TypeScript

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

Answer 2

HTTP can be thought of as one specific case of generic principles of Remote Procedure Call: you tell the server what you want with some variable field in the request, the server responds accordingly. By now, due to the complex interactivity of ‘Web 2.0,’ these same features are shoved in every field on the request: the URL, headers, the body—and each appserver and app understands them in their own way. However, originally the web was simpler, used static pages, and it was thought that the HTTP methods provided for the level of interactivity that would suffice. Notably, HTTP has plenty of methods that are used rarely, if ever, with some of them only seeing the light thanks to REST. E.g. PUT and DELETE were moribund before REST, and TRACE and PATCH are afaik still unseen. The takeaway is that HTTP's model of RPC didn't quite match the apps that followed, and apps implemented their own model with just GET and POST—but HTTP couldn't be thrown away by then.

REST did the exact opposite of what you're proposing, by noting that the HTTP methods serve the typical CRUD use-cases of most apps if PUT and DELETE are brought back.

Note also that HTTP methods have semantics assigned to them, that are honored by browsers and middleware like proxy servers: POST, PUT, DELETE and PATCH requests may have side effects and likely to not be idempotent, so client-side apps and middleware take caution to not fire these requests without express action from the user. In practice, poorly-designed web apps did use GET for non-safe actions, and e.g. the Google Web Accelerator prefetcher caused trouble by deleting bunch of data on such sites, so its beta was suspended soon after launch.

So, to answer the ‘can we’ question: sure, you just need to agree on a protocol that will tell the server app what action you want to perform, and then you put the arguments somewhere in the URL/body—such as the target item for the action. The set of actions is bounded only by specific apps, so you need an extensible protocol. But you'll need to let the client apps know which requests are safe, and probably to take other nuances into account, such as cache-control.

Answer 3

From my personal point-of-view as a developer, it can make creating API endpoints much easier. For instance if I write a controller that manages products on a website I can use the same URL to do multiple different operations.

Examples:

GET https://example.com/api/products/1234

This will fetch the details of product 1234.

---

POST https://example.com/api/products/1234

This will create a product with ID 1234 using data in the request body.

---

PUT https://example.com/api/products/1234

This will update product 1234 with data in the request body.

---

DELETE https://example.com/api/products/1234

This will delete a product with ID 1234.

---

I could make different endpoints for each operation but that would complicate the process and make it less understandable for other developers.

Answer 4

What is the need of methods like GET and POST in the HTTP protocol?

It seems that you forgot the old days when HTTP servers were there just to serve files; not running script, CGI, or making dynamic content of that sort.

The request methods are basic standardized set of verbs on what to do with those files...

• GET means download
• HEAD means get information of
• PUT means upload
• DELETE means remove
• POST means send data into
• OPTIONS means tell me what I could do

In the day of HTTP/0.9, request line is the only thing in the request leg of the protocol; no request headers, no response headers. You just type in GET /somefile, press Enter, the server will return the response body (i.e. HTML content), and okay thanks bye (i.e. close the connection).

If you meant just to ask why it was designed this way? My answer is because it was originally written to handle the kind of content exchange existed back then, i.e. the serving static HTML files at users' request.

However, if you meant to ask about how to treat these semantics in modern application server...

Can we not implement the HTTP protocol using just a request body and a response body?

Is implementing various HTTP methods really needed?

My answer is: do whatever you would like to do, but keep in mind that you should not implement application logic in a way that defies expectations of the protocol: expectations like GET should not change data (or very loosely, have at least idempotent result), HEAD should have the same result as GET but without response body, PUT should make the content of the target URI available (if succeeded).

If you go against expectations without carefully considering its implications, various unpleasant things would happen, like...

• When you shoehorn GET method into data submission use, the server might spit 414 "URI Too Long" error in your face.
• When you shoehorn GET method into data modification use, you would find that modification sometimes doesn't get through when user is behind a caching proxy, or unexpected modifications would take place when user recalled the URL from bookmark (or when web crawlers reach it).
• When you respond to HEAD method improperly, you would find that your automatic site check tools (e.g. wget --spider) bail on your site.
• When you shoehorn POST method into content download, you would find that bookmarking or even entering the URL into the browser won't work.
• And many more...

---

"Beginner knows rules, but veterans know exceptions."

Anyway, you might end up finding some valid excuses to go against some of the rules for some narrow use cases; but make sure to do your research and consider all possibilities. Otherwise, you are going end up axing interoperability, and ruining "user experiences".

There's no guarantee that users always use latest shiny rollout of mainstream name-brand clients/user-agents that you tested. They may use a local brand that is tailored to their needs (me included), a custom one they ordered from specialty shop next door, or a vintage one they dug out of a storeroom. Even with all these, your sites are still expected to give a reasonable service. That's a reason why we have standards.

Carelessly breaking the standard also means you are applying discrimination on your users.

Answer 5

It is true in theory we could use get all over the place and it would sort of work. Some software even use GET with request body(I'm looking at you elasticsearch/kibana). This of course is a horrible thing to to.

The most important reason is because the different methods has different semantics. Some are safe, some are idempotent. Some are both. See which are which

This is important e.g. when interacting with other applications. GET endpoints are not supposed to have side effects. This is important when google is crawling your side. PUT is supposed to be idempotent which means the client is free to try again in case of a failure. This is not the case for POST which why browsers have to have an ugly confirm box if you press f5 on a post request.

See what can happen if you use GET where you should have used POST

Answer 6

You can also think of GET, POST, etc as overloads of the same function, or even as getters and setters.

GET_MyVar() won't take an input param (aka the Request Body), but returns something.

POST_MyVar(string blah) does something with the input (again, the request body) and may return something. (It also needs to at least return a response code, so that we know the function ran!!)

DELETE_MyVar() Also probably doesn't take anything and is expected delete something.

Yes, we could implement it all with:
MyVar(string Action, string? blah)

This way we could accept just one call and then choose what to do based on some other parameter.

But one of the conveniences of this approach is that it allows browsers and servers to optimize the way these things work. For example, maybe the server would want to block all requests where Action==DELETE. Maybe browsers want to cache things where Action==GET. If not, in every function we would have to write if (Action==Delete) {return AngryFace}

There is no requirement to implement everything exactly according to protocol, but protocol is basically a set of rules that we all decided to follow. That way, I can guess easily what your site will do, even if I haven't seen the server!

Answer 7

HTTP methods serve different purposes. In general, GET is for downloads and POST is for uploads.

The only way implement part of the HTTP protocol using just a request body and a response body would be to implement POST. GET does not have a request body. It only has the request itself with headers, but no body. It is just a request for a document to download. POST has both the request body (the file upload) and a response body (the document showing the result).

So could you just implement POST and be done? Not if you want your site to be usable in standard browsers. The default request type that browsers send is GET. POST requests are usually only sent when forms in web pages are submitted or for AJAX calls. Only if this particular server were only being used for AJAX calls, and not for pages visible to users, might you be able to get away with POST only.

Browsers also sometimes send HEAD requests to check if a document has changed since last time they downloaded it, so it would be advisable to at least implement that as well.

In any case, there isn't a good reason to implement a web server for your site from scratch. The HTTP protocol is complicated. In addition to the various methods you would also have to implement pipelining and chunked requests. It is far easier to build your web application on top of a web server like Apache, Nginx, or IIS that handles the HTTP protocol for you. You mention Servlets, so maybe you should use Tomcat or JBoss web servers which run Servlets.

Answer 8

You are correct, we could do just that, GET, POST, PUT etc are just historical conventions if I had my way HTTP would be superseded with just POST method and nothing else, although I have to concede eliminating GET would be a huge undertaking, that couldn't be done, the horse has already bolted on that one

Answer 9

Your proposed protocol would be significantly less secure against hackers.

There is a reason why websites have moved away from storing information about variables and such in the URL, and that reason is simple: it gives attackers a very simply way to attack your system. By observing the plaintext URL information, they can determine the fashion that the data sent to your web server is constructed; they can then use this information to execute an attack on your server by using a specially-constructed URL that allows them to inject malicious code or data onto your server.