RE: [Zope] Zope Requests - POST vs. GET
[Tino Wildenhain ]
IMHO, the two should not be mixed because they have different semantics. A POST is intended for sending information to the server to apply to the resource designated by the current uri, a GET is for requesting a new page designated by the uri. I think it is wise to keep them separated.
I dont think so. Its just a hindering decision to implement it this way. Better approach would have been to implement a GET and a POST namespace in REQUEST as well as mirroring the variables into Form as they are now.
After all, a QUERY string in a Post URL is just valid information. I really cant see why Zope does not let us access it. And I'm very into standards.
But they are not quite on the same footing so far as information goes - there is supposed to be a semantic difference. A GET is supposed to be idempotent, a POST need not be. For example, if you GET an airline schedule twice in a row, it should not have changed because of the effect of any data you sent with the GET. If you transfer money from one bank account to another using a POST, you expect to see a change in the state of the resource (your bank account's representation). True, a POST does not _have_ to make such a change. But a GET is NEVER supposed to. When you mix up form variables between a POSTed form and query string parameters,the procedssor ought to assume that all the parameters might have come with the POST. So in effect the semantics of the GET have been changed. That is what I am against - even if it is convenient once in a while. Cheers, Tom P
Hi Tom, Passin, Tom schrieb:
[Tino Wildenhain ]
IMHO, the two should not be mixed because they have different semantics. A POST is intended for sending information to
the server
to apply to the resource designated by the current uri, a GET is for requesting a new page designated by the uri. I think it is wise to keep them separated.
I dont think so. Its just a hindering decision to implement it this way. Better approach would have been to implement a GET and a POST namespace in REQUEST as well as mirroring the variables into Form as they are now.
After all, a QUERY string in a Post URL is just valid information. I really cant see why Zope does not let us access it. And I'm very into standards.
But they are not quite on the same footing so far as information goes - there is supposed to be a semantic difference. A GET is supposed to be idempotent, a POST need not be. For example, if you GET an airline schedule twice in a row, it should not have changed because of the effect of any data you sent with the GET. If you transfer money from one bank account to another using a POST, you expect to see a change in the state of the resource (your bank account's representation).
True, a POST does not _have_ to make such a change. But a GET is NEVER supposed to. When you mix up form variables between a POSTed form and query string parameters,the procedssor ought to assume that all the parameters might have come with the POST. So in effect the semantics of the GET have been changed. That is what I am against - even if it is convenient once in a while.
This semantic you are referring to is effectively non existent. Sorry. If you see real world examples there are a lot of cases where the information indeed changes between GET requests. Even a GET request without QUERY-string is a GET request after all. See for example the shop, where you put items in a backet. On each page there is the number of items currently in the basket displayed. So no matter if you put it in via GET or POST at least another GET will give you different result. Its just not feaseable to do it any other way (e.g. only use POST for modifying data) Regards Tino
On Tuesday 16 December 2003 06:35, Tino Wildenhain wrote:
Passin, Tom schrieb:
A GET is supposed to be idempotent, a POST need not be. For example, if you GET an airline schedule twice in a row, it should not have changed because of the effect of any data you sent with the GET. If you transfer money from one bank account to another using a POST, you expect to see a change in the state of the resource (your bank account's representation).
This semantic you are referring to is effectively non existent. Sorry. If you see real world examples there are a lot of cases where the information indeed changes between GET requests. Even a GET request without QUERY-string is a GET request after all.
That is not the distinction that Tom was referring to. Of course that data can change *between* GET requests, but it should not change *because* of the GET.
See for example the shop, where you put items in a backet. On each page there is the number of items currently in the basket displayed. So no matter if you put it in via GET or POST at least another GET will give you different result. Its just not feaseable to do it any other way (e.g. only use POST for modifying data)
A shop that uses GET for the 'add to basket' operation will suffer from problems where it sees more that one such request, when the user thought he issued only a single request. This is allowed. Real world http proxies do do this automatically. -- Toby Dickenson
participants (3)
-
Passin, Tom -
Tino Wildenhain -
Toby Dickenson