Discussion of GET vs. POST and letting the client decide

[Joe Areeda]

Greetings,

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.

I can think of criteria to decide whether a GET or POST method would be more appropriate, but it would have to happen in Javascript on the client side.

All that verbiage just leads to these fairly simple Javascript questions. I am not a Javascript expert by any means so they are very basic.

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.

Thanks,

Joe

[Ulf Dittmer]

JavaScript can certainly modify the method attribute of an HTML form, just as it can disable or delete form input elements. But basing that on the amount of data is not the right way to go. For starters, GET and POST are not interchangeable; that's something the HTTP specification is very clear about. If you want to make a decision on this, I'm afraid there is no way around reading the HTTP spec (or otherwise learning the depths of HTTP) until you're clear about what idempotent means, and how that affects the choice between GET (which should be idempotent) and POST (which needn't be).

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.

[Joe Areeda]

Thanks Ulf,

I have some reading and experimenting to do.

I'm sur emore questions will come up.

Joe

[Karthik Shiraly]

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.

The benefit of using POST is that it takes care of all future changes to the form - like adding more checkboxes - without having to change and test any kind of form manipulating javascript.

Depending on number of requests, such a database may need periodic cleaning up.

[Jayesh A Lalwani]

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

[Joe Areeda]

Thanks Karthiki and Jayesh!

There are a lot of advantages to that idea.

I've been traveling all day and just arrived for a 2 week visit to one of the observatories. I need to go grocery shopping and make dinner but will discuss this as soon as I get some time.

I think that could work on several levels.

Thanks again,

Joe