This is a personal note that I decided to share. It reflects my understanding of a subject and may contain errors and approximations. Feel free to contribute by contacting me here. Any help will be credited!
At my company, we encountered an issue with a GET endpoint. We reached the max URI length. As we can’t use a request body in a GET, the simplest solution that we found was to use a POST instead.
But I was wondering what the impact would be of using a POST to effectively do a GET. During my research, I learned good things on HTTP and REST, which I’m sharing in this post.
POST for Data Retrieval?
The HTTP GET method has several limitations.
-
URI Length: A GET request returns a representation for a target resource identified by a URI. However, the URI length is limited depending on the “HTTP component.” For example, Internet Explorer’s max URI length is around 2000 characters, and on NGINX, it is 8192 characters by default. So, if the target resource is identified by a large URI, the request may fail.
-
URI Expressiveness: For some complex filter requests, the format of a URI is not sufficiently expressive. URIs, therefore, limit the expressiveness of certain requests.
-
GET Request Content: Theoretically, request content (or body) can be used with all HTTP methods. However, GET request content has no semantics and does not alter the meaning of the request (according to RFC-9110). Many servers and proxies ignore or reject the request content on the GET method.
If we look at all the limitations above, we can see the potential limits of GET methods. When we reach those limits, we may think of using a POST method instead. Thus, we can use the request body and build complex requests.
But we may also think of the impact of this choice on HTTP and REST principles.
HTTP and REST
To understand the impact and scope of choosing to use a POST instead of a GET, we need to look at the impacts at HTTP and REST levels (which are not really linked, as we shall see).
HTTP Semantics
HTTP is a communication protocol built in 1990 for the World Wide Web. HTTP is standardized and specified in documents called RFC written by the IETF (Internet Engineering Task Force).
The RFC-9110 describes HTTP Semantics, we can read the following information.
GET Method
GET request returns a representation for a target resource identified by a URI. According to the doc, GET method is safe and idempotent.
Safe means that the method has a read-only semantic. From a client perspective, the use of GET does not impact the server state (HEAD, OPTIONS, and TRACE are also safe).
Idempotent means that from a client perspective, multiple identical requests have the same effect on the server as a single request. All safe methods are idempotent, plus PUT and DELETE.
Safe and idempotent properties allow the implementation of mechanisms such as: crawlers, cache performance optimization (pre-fetching), and retry support. All are widely used by search engines, browsers, and HTTP clients.
GET vs POST
POST requests tell the server to process the data enclosed in the request content. A client should expect a change in a server state after a POST request, so it is not safe. Moreover, POST requests are not necessarily idempotent. Multiple identical requests do not have the same effect on the server as a single request. Caching semantics is defined for POST, but most cache implementations do not support it.
From a technical point of view, it is possible to use a POST request instead of GET to bypass GET limitations. However, from a client perspective, it changes the request semantics and may prevent him from some optimizations, such as cache and retry. So, according to the HTTP standard, using POST to GET resources is not compliant.
REST (Representational State Transfer)
REST (Representational State Transfer) is an architectural style designed by Roy Fielding (an IETF member) in a these published in 2000. As an architectural style, there are no “REST standards”. REST is a set of general principles to build scalable, extensible, uniform, and performant applications on the web.
REST is not necessarily linked to HTTP. The thesis does not mention HTTP methods usage (GET, POST, PUT, DELETE) nor CRUD.
Search my dissertation, and you won’t find any mention of CRUD or POST. […] The main reason for my lack of specificity is because the methods defined by HTTP are part of the Web’s architecture definition, not the REST architectural style. […] The only thing REST requires of methods is that they be uniformly defined for all resources (i.e., so that intermediaries don’t have to know the resource type to understand the meaning of the request). As long as the method is being used according to its definition, REST doesn’t have much to say about it.
Roy T. Fielding - It is okay to use POST
REST Principles/Constraints
REST principles (or constraints) are detailed in Chapter 5 of his thesis : Architectural Styles and the Design of Network-based Software Architectures.
- Client/Server : Client and server responsibilities are separated. Components can evolve separately.
| Benefits | Trade-offs |
|---|---|
| Portability | |
| Scalability | |
| Extensibility |
- Stateless: Each request contains all the session state information needed to be processed by the server. There is no server-side context or session storage. The client is responsible for maintaining session state.
| Benefits | Trade-offs |
|---|---|
| Reliability | Information duplication between requests |
| Scalability | Network performance (mitigated in 2025) |
| Less server control |
- Cache: Request responses specify if they are cacheable.
| Benefits | Trade-offs |
|---|---|
| Reduce interactions with the server | Stale data can impact reliability |
| Better performances |
- Layered: Clients only see the next component with which they interact. So clients don’t know if they are connected to the final server. Components such as proxies or load balancers can be placed in the system, with no impact on the clients.
| Benefits | Trade-offs |
|---|---|
| Decoupled | Network latency |
| Improve reliability with load balancers | Complexity |
| Improve security with firewall |
- Code on demand: Server can modify the clients by sending remote executable code. This constraint is qualified as optional.
| Benefits | Trade-offs |
|---|---|
| Simplify client implementation | Visibility |
| Portability |
- Uniform Interface: Provide a general and uniform interface between components, decoupled from service implementation.
- Identification of resources: Resources are identified using unique identifiers.
- Manipulation of resources through representations: Clients manipulate representations of resources sent by the server. The server does not share internal resource representations. Clients holding a resource with its metadata have enough information to modify or delete it.
- Self-descriptive: The server returns the resources with metadata such as media types, enabling the client to process them.
- Hypermedia as the engine of application state (HATEOAS): The Server should provide links to guide the client through the application.
| Benefits | Trade-offs |
|---|---|
| Simplify integration | Less efficient for specific interactions |
| Improve visibility | |
| Decoupled |
REST and POST for Data Retrieval
Regarding the REST principles, using a POST to retrieve a resource breaks the uniform interface principle. It may also affect the caching principle, as HTTP clients handle caching differently for GET and POST requests.
Roy T. Fielding, in a 2009 blog post, confirms it.
For example, it isn’t RESTful to use GET to perform unsafe operations because that would violate the definition of the GET method in HTTP, which would in turn mislead intermediaries and spiders. It isn’t RESTful to use POST for information retrieval when that information corresponds to a potential resource, because that usage prevents safe reusability and the network effect of having a URI.
Roy T. Fielding - It is okay to use POST
Conclusion
Although it’s technically possible to use a POST to overcome the limitations of a GET, this poses a problem regarding the HTTP standard and REST architecture.
This should prompt us to reassess our endpoints and consider several key questions. Is it normal to have a very long URI? Is it possible to implement more restrictive filters to reduce the number of query parameters?
Finally, we may not really have a choice.
It’s important to evaluate our decision within the specific context in which it is being considered. Who is the API intended for? What are its uses? Obviously, there are different constraints between a public API used by web applications and a private API called by a piece of Python code four times a day.
Perhaps this subject will soon be a thing of the past. Indeed, the IETF working group is currently discussing a new HTTP method, QUERY: a safe, idempotent request that contains content. The specification is currently in draft : The HTTP QUERY Method -Draft.