|
|
Posted by Joel Shepherd on 06/18/05 21:03
In article <op.sskd3ipqdob4us@ibis>, Mitja <nun@example.com> wrote:
> the only thing at which POST is better is sending large chunks of data
No. POST and GET have entirely different semantics, beyond how the query
data is sent to the server.
http://www.cs.tut.fi/~jkorpela/forms/methods.html
If submitting the form is expected to result in some important change of
state on the server side (e.g., an order being placed, form data being
saved in a database, someone's pager going off), then POST should be
used.
In addition, responses to "GET" requests can be cached (by the browser,
by a proxy, etc.), while "POST" responses generally are not.
This is probably relevant to the OP, since it sounds like 'Cranio' is
expecting users to click on the link to refresh their view of table
data. If that's the case, then "GET" is not appropriate, as the browser
may simply display the results of an earlier GET, and not fetch the
current row data from the database.
I don't know if it's still the case, but at one time this was actually a
defect on the Amazon site: you could add an item to your cart, hit a
"View Cart" link (a GET), see the item there, add another item to your
cart, hit "View Cart" again, and still see only the first item added to
the cart. The first "View Cart" response had been cached and redisplayed
the second time around, even though the state on the server had changed
since. Oops.
--
Joel.
Navigation:
[Reply to this message]
|