Why Distinguish Between GETs and POSTs?

It’s nice that ColdFusion gives you the option of distinguishing between GET and POST requests by putting variables in two different scopes (the “url” and “form” scopes, or structs), but with the framework I’ve put together for ColdFusion applications, I don’t really need to know. In fact, I don’t want my code distinguishing between the two because it makes it less generic (meaning I’m forced to make requests in way or the other). The answer has been to include this little piece of code from my Application.cfc file:

[code]

[/code]

Now I reference everything in the “request” scope or struct, regardless of whether it was submitted through a form or a URL parameter which makes my code more generic and reusable.

14 Responses to Why Distinguish Between GETs and POSTs?

  1. Bill says:

    I think this is a tact a lot of people take with the exception that it might be more common for folks to move things to the attribute scope.I know that is what I do and I believe is what fusebox users do as well.I’m not sure about other frameworks.

  2. Joel Cox says:

    Only caveat is that you are implicity choosing URL to take precedence over FORM in the (admittedly rare) case that a form field and url parameter share the same name.

  3. Devin says:

    why wouldn’t you just not use scopes when referencing them? I realize that you might reference the same var in the wrong scope, but you can usually be aware when this could happen and scope accordingly.this has always seemed to be a feature to me. your application can be very flexible if you don’t use scopes when referencing them… and reference scopes when you want variables from specific scopes only.but so many people run around claiming you should always scope your references to variables no matter what. i think that’s good advice for people who may be less experienced. But that’s taking away a nice feature for those of us who know what we’re doing.

  4. Patrick says:

    To answer the question in the title of the post, you should distinguish between GETs and POSTs because they mean different things. A GET is a request for a copy of a resource, and a POST is a request to take some action based on data supplied by the user.Advocates of REST are finally vindicated by all the crying that REST detractors are doing over the Google Web Accelerator, which is only the latest example of a prefetching proxy server (totally allowed by HTTP) that breaks web applications that forget the difference between GET and POST. You should never set yourself up for a situation where a GET request can be unsafe or non-idempotent.Why distinguish between GETs and POSTs? Ask the developers of Basecamp. They treated GETs like POSTs (allowing them to be non-safe by linking to their delete action with an A tag) and found that the next HTTP user-agent to come along went ahead and clicked on each one of the delete links. Now the application is broken, and they have to put in a hack to block the user-agent that was acting totally in compliance with all the standards.

  5. Christian Cantrell says:

    Devin:Specifying a scope makes your code faster because the value can be located faster rather than ColdFusion having to check all the possible scopes.Patrick:Good point. I would argue that it’s ok not to distinguish in certain circumstances as long as you know what you’re doing, although the Google web accelerator (and prefetching in general) certainly adds an interesting twist.

  6. Patrick says:

    You’re right, the directive to observe the difference between GET and POST rises to the level of SHOULD, and not MUST (to use RFC-speak). If you are fully aware of the consequences, you’re free to hook up your “delete” action to a GET (or, more likely in this case, to do something totally innocuous in the name of efficiency).I would advise developers considering this technique to assume that the page *will* be called in an unanticipated or even malicious manner, and to only proceed if the consequences of such a call are outweighed by the advantages you gain. In the case of a search form, for example, this technique is totally justifiable since the consequences of accidental or malicious calls are slim to none.

  7. Pete Freitag says:

    Christian, Make sure your aware of the potential security risks of doing that. By letting the user choose either form or url, you can do some things like Cross Site Request Forgery

  8. Devin says:

    increase performance by scoping variable references… and then how much performance will be lost by creating brand new (request/attribute) variables?does it really matter anyway? sacrifice flexibility for a couple miliseconds of speed?I like using cf for its rapid development and ease of use. Automatically searching scopes for variables is a nice convienence feature that fits into both those cases. If I were to be anal about miliseconds, CFML wouldn’t be my top choice.

  9. Christian Cantrell says:

    Devin: If it works for you, then do it! I’m the type who likes everything scoped because I like the code to be as explicit as possible, and I like to eek out every last millisecond of performance. But you’re probably right that the difference in performance is imperceptible, so like I said, as long as it works for you, and you’re comfortable doing it that way, go for it.

  10. jim collins says:

    With regards to Devin, this must be one of the last remaining industries that says “if it feels good, do it”. Other disciplines have codes and standards that have to be adhered to. One way we can get more respect for programming in general and CF in particular is by agreeing to certain standards and adhering to them. No one would argue that what Devin is proposing is a best practice, so why encourage it or even say that it’s acceptable?With regards to GET vs POST, I refer to Jon Udell’s column on the topic: http://www.infoworld.com/article/05/04/20/17OPstrategic_1.html

  11. Christian Cantrell says:

    I think there are some really good arguments here, and anyone considering combining GETs and POSTs as I’ve suggested should read all these comments. Thanks for all the feedback. Frankly, I’m wondering if this is such a good idea after all.

  12. Craig says:

    Normally I’d agree with you, but sometimes we work in weird circumstances where data into same variable name from different sources has different priorities.That’s why variable scope matters. To prioritize the sources of data, and to validate it as well.What if you have two different pieces of data, one url and one form. But you need to validate both and then decide which one you want grab the value from?This is the whole point of data typing and data validation. However I can understand your desire to simplify the grabbing of data from whatever reqests scope.Just be careful because this has no problem for 80-90% of the time, but we still get that 10% of odd projects that force us to do non-logical things, so take care.

  13. durairaj says:

    sir,i dont have a clear idea about the difference between the usage of GET and POST request.plz mention some practical usages of using GET and POST request and justify why?

  14. Joseph Flanigan says:

    Actually, CF has 3 request structures, URL, FORM and FLASH. On CFLIB, look at http://www.cflib.org/udf.cfm?ID=976 , RequestINOUT(). The idea is like your approach but with added benefit of choosing order of the structure append. I happen to use Request.IN and Request.OUT because those names made sense to me. Since every HTTP request has some type of response, most of the time, setting up the output at the time of input saves building the output structure eleswhere.