We are doing a RESTful service that is non-public. For a request that is read-only and potentially uses 20+ parameters, we are planning to implement it as a GET request that will pass these parameters in the body.<p>I have seen the well known announcement by Dropbox in 2015: https://blogs.dropbox.com/developers/2015/03/limitations-of-the-get-method-in-http/ and the response in Hacker News: https://news.ycombinator.com/item?id=9133469<p>As I understand it, there are three potential issues with a GET with request body:<p>(1) Not all servers will support this.<p>(2) Not all tools will support this (POSTMAN added support this year: https://github.com/postmanlabs/postman-app-support/issues/131)<p>(3) There is not yet a consensus on GET with request body. (For example, is Dropbox still using a POST)<p>I am not finding too many recent statements about this, I wanted to open up the question here and see what the current opinions are.<p>I heard that ElasticSearch is using GET request parameters in the body. It sounds like there are some who are against this approach:
https://stackoverflow.com/questions/36939748/elasticsearch-get-request-with-request-body<p>(1) Does this make sense for a private server? (The answer here seems to be yes -- unless I am missing something)<p>(2) Does this make sense in general? If the tools needed support it, what is wrong with implementing a RESTful service that requires GET request parameters in the body?
I'd recommend sticking to POST requests with body that fetches the data you need. I know it's semantically odd because the POST request not creating a "resource" on the server. But it's practically very useful as it'll work well with client libraries, load balancers etc.<p>You can get some inspiration from GraphQL for your use case. All GraphQL queries are POST requests with body specifying what data the client needs.
While there's nothing stopping you from doing so I would be wary about it. Even though the service will be internal you might still need to use third-party software/tools in the future that will be incompatible because of this.<p>For example, will you need to use a 3rd party request library? Will you need to set up some sort of proxy (NGINX, HAProxy, etc.)? Will you need to use a cloud load balancer (I'm not sure if they would send a request payload for GET requests)?<p>For open-source solutions you might be able to fork them to add this behavior but why do so to begin with? Is there a specific reason why you don't want to use query parameters?
If you need to have lots of query parameters (I'm assuming that's what you're referring to) then something is wrong in your design. Start by dividing your problem into simpler parts and go from there.<p>A dumb idea would be to encapsulate various options into a single query parameter. Compressing query parameter's names and values and encoding them in base64 (or some other base of your choice) might also help. But all of this will just add tons of needless complexity to it.<p>Do you really <i>NEED</i> 20+ query parameters?<p>I am curious, though. What are you actually trying to achieve here?
I think that only request methods that can use a request body can use a request body. (However, it is only private use, then might not matter.)<p>One alternative way is to use a different protocol rather than HTTP, if that is applicable for your use. Another way is to make up a new LONG_GET method.
Convention should always be adhered to unless you have a really good reason for not doing so. This is especially true for things like REST where convention is the whole point.