HTTP defines several methods for interacting with a server. The four most familiar are GET, POST, PUT, and DELETE. A URL identifies a resource on the network, and these HTTP methods can be understood as different ways of operating on that resource: retrieving it, updating it, creating it, or removing it. In that sense, GET is usually associated with fetching or querying data, while POST is commonly used when sending data that may change something on the server.
What the HTTP specification says about GET
According to the HTTP specification, GET is meant for retrieving information. It is expected to be both safe and idempotent.
Safe
Here, safe does not mean secure in the security sense. It means the request is intended to obtain information rather than modify it.
In other words, a GET request should generally not produce side effects. It is like a database query: it reads data, but does not add, delete, or alter it, and should not change the state of the resource.
Idempotent
Idempotent means that making the same request to the same URL multiple times should have the same effect as making it once.
The idea comes from mathematics: if applying an operation repeatedly gives the same result as applying it once, that operation is idempotent. The absolute value function is a common example.
Once that idea is clear, the meaning of GET being idempotent becomes easier to understand.
That said, real-world behavior is not always interpreted in a rigid way. A news homepage is a good example: the front page may show different headlines on two different requests, yet the operation is still considered safe and idempotent because each request is simply returning the current state of that resource. From the user's perspective, following the link is not itself changing the resource.
What POST is for
The HTTP specification treats POST as a method for requests that may modify server-side resources.
Using the same news-site example, if a reader submits a comment on an article, that action should be done with POST, because once the comment is submitted, the resource on the site is no longer the same as before. The server-side state has changed.
Why practice often drifts away from the spec
Although the distinction sounds clear in principle, many real applications have not followed it strictly. There are several common reasons.
1. Convenience
Many developers have used GET even for update operations simply because it is easier. Using POST often means submitting through a FORM, which can feel slightly more cumbersome.
2. GET and POST can both be used to pass data
In practice, create, read, update, and delete operations can all be implemented with only GET and POST, even if that is not the cleanest design. As a result, PUT and DELETE have often been ignored.
3. Traditional MVC frameworks were designed around only GET and POST
Early Web MVC frameworks generally did not treat URLs as abstract representations of resources in a deliberate way. That led to a long-standing pattern where many frameworks supported only GET and POST, while offering little or no support for PUT and DELETE.
A brief note on MVC: it originated in desktop applications. M stands for the data model, V for the user interface, and C for the controller. The purpose of MVC is to separate the implementation of the model from the presentation, so the same application logic can be presented in different ways.
These three points capture an older style of web development that did not strictly follow HTTP semantics. As software architecture evolved, REST (Representational State Transfer) emerged as a style more aligned with the HTTP specification.
The visible differences between GET and POST
Beyond semantics, developers usually notice several practical differences between the two methods.
1. Where the submitted data goes
With GET, request data is appended to the URL. The URL and the transmitted data are separated by ?, and parameters are joined with <, for example:
login.action?name\=hyddd
With POST, the submitted data is placed in the body of the HTTP request.
2. Is GET limited to 1024 bytes while POST is unlimited?
A common claim goes like this: "GET can submit at most 1024 bytes, while POST is theoretically unlimited; in IIS4 the maximum is 80KB, and in IIS5 it is 100KB." That statement is inaccurate.
GET length is not defined by HTTP itself
Because GET sends data through the URL, the amount of data it can carry is directly tied to URL length. But the HTTP specification does not define a hard maximum URL length.
The real limit comes from specific browsers and servers.
For example, Internet Explorer limits the URL length to 2083 bytes (2K+35). Other browsers such as Netscape and Firefox are not defined by the same limit in theory; their practical limits depend on operating system support.
It is also important to note that the restriction applies to the entire URL, not just the parameter value portion.
POST is not inherently size-limited by HTTP either
In theory, POST does not have a fixed size limit in the HTTP specification. So saying that POST data is restricted to 80KB or 100KB is also imprecise.
The actual constraint is usually the server or application environment's ability to process the request.
In ASP, the Request object imposes a 100KB limit when processing each form field. But if Request.BinaryRead is used, that limit does not apply in the same way.
This leads to another important point: with IIS 6.0, Microsoft increased several default limits for security reasons.
Things to keep in mind for IIS 6.0 include:
1). IIS 6.0 defaults to a maximum ASP POST size of 200KB, with each form field limited to 100KB.
2). IIS 6.0 defaults to a maximum uploaded file size of 4MB.
3). IIS 6.0 defaults to a maximum request header size of 16KB.
Versions prior to IIS 6.0 did not have these same defaults.
So the widely cited 80KB and 100KB values are likely just defaults under certain configurations, not universal limits. Different IIS versions use different default settings, and these values can be adjusted through configuration.
3. How server-side code reads them
In ASP, GET parameters are read through Request.QueryString, while POST parameters are read through Request.Form.
In JSP, developers commonly use request.getParameter("XXXX") to retrieve parameters for either method. JSP also provides request.getQueryString(), but it is less convenient to work with directly, for example when handling:
test.jsp?name\=hyddd
4. POST is usually more secure than GET
Again, this is a different meaning of secure from the earlier discussion of GET being safe.
Here, security means actual exposure risk.
Data submitted through GET appears directly in the URL, so usernames and passwords may be exposed in plain text. That creates several problems:
- the login URL may be cached by the browser;
- someone viewing browser history may see the account credentials.
In addition, using GET for operations that should not be link-triggered can increase the risk of Cross-site request forgery attacks.
One last clarification
GET is often described as a way to ask the server for data, and POST as a way to send data to the server. In HTML forms, the default method is GET.
But the deeper point is that GET and POST are not simply "one for receiving and one for sending." Both can transmit data. The real difference is in the request semantics and the mechanism by which the data is carried.