This is one of those I wonder if it's possible questions and then if so is it worth pursuing?
Deciding whether a form should use the GET or POST method to return its values is sometimes easy and other time a toss up.
One big advantage of GET is our users can past a URI into the trouble report and we can reproduce the exact command they are having trouble with. Another is they can pass it onto another user to reproduce results.
One big disadvantage of GET is that the length of the data returned is limited and that limit varies on, I think, browser and client OS.
I am working on a Java Enterprise app where GET is a nice fit MOST of the time. One of my biggest issues from day 1 is that providing powerful ways to express requests can lead to unreasonable requests (for a browser app, not the user).
I think an example is needed to help this discussion along.
My application is a data visualization tool for a large international scientific collaboration (http://www.ligo.org). The data stores now have about 2PB of data and when the advanced version of the instruments come on line toward the end of 2014, early 2015 we expect to be adding about 10MB/s from 2 observatories or 1PB/year. This data is organized in channels and depending on how you count derivative channels and data stores we have somewhere between 750K and 13M channels. It's common to compare data from different channels or to look at the same channel at different times. So the UI that selects channels and times is fairly general with "select all" and "repeat every" buttons. The problem is if they select too many things they get an error from the Browser because the URI is too long and it is expressed in technobabble or gobledegook, which results in a trouble ticket or email.
Are there any disadvantages to having a form that uses GET sometimes and POST others
When the user hits the submit button, I can count the number of form elements and decide GET or POST, can I modify the method in JS?
The other question is can I remove form elements from the submit process. For example if the check box that says use this plot product is not selected I don't need the many parameter for that product to be sent. In the POST scenario this is not a big deal they don't eat much bandwidth but they do make the URI much longer.
One of the benefits of using the Ranch, is that taking the time to express a problem in a way that others can understand often leads to not only a better understanding of what confuses me but also several ways to research the answer myself.
I'm going to hit the Submit button anyway and would appreciate any comments and advice.
It's not what your program can do, it's what your users do with the program.
There are other pragmatic concerns, like GET requests can be handled differently than POST requests when it comes to caching, and URL parameters as used by GET find their into various places that POST parameters do not - like browser histories and web server access logs; that kind of thing may or may not matter in your situation.
One alternate approach you could think about that is simpler to implement:
Use POST and on the server side, save every request's parameter set - along with a unique ID - in a database.
Then allow users to share or report their criteria by providing them a sharable URL with just this unique ID as a parameter.
Since the parameter set is saved in DB, it can always be recreated for other users or for diagnosis.
Depending on number of requests, such a database may need periodic cleaning up.
I like karthik's answer. Like he says, You could have a link that creates a unique shareable URL. When user clicks on the link, it saves the current post requests in the db, or maybe even takes a snapshots of the results and saves them in the db. When the user visits the shareable URL, you show the results back to him/her.
Or alternatively, you could have every link be shareable. Every request can be a POST, that saves the request in the database. The POST does a client side redirect to the unique shareable URL. When you hit the shareable URL, you process your request and show results to the user. User can bookmark/email/Facebook the URL