Jan Algermissen wrote: > On 20.01.2007, at 01:24, Gregg Wonderly wrote: > > The additional semantics must be known by the client in order for > > the developer > > of that client to make the right choice of which operation to use, > > how to wrap > > the data and parameters that the resource understands etc. > > No, that is apparently your misunderstanding. The method is POST > (process this) and the client does not know about any other > semantics. Clients do have to choose the right resource to POST to > (e.g. a shoe order processor) to get the desired result, but the > operation is just POST.
Jan, this only works for HTML based data. If I am using a web server, and have nothing up front, but it accepts images and stores them for me, I have to know that resource, and I have to know that I pass an image as opposed to a URL to the image data or something else. I understand that you'd like to assert that there is always some content or knowledge that the client already has. Over and over again, I've had to type URLs into by browser, at least once. There is always some knowledge that a user has to have up front to guide the browser to get started. Not every user of HTTP uses it with a session. I have a Java based applet that talks to a web server. It never, downloads HTML and never gets anything from the server except data that it uses to populate GUI components (not HTML renderings). I had to code into it what data to send, and how to interpret the various document types that come back. Web browser developers have to do the same thing. > The server tells the client at runtime what media type to send (this > is the purpose of forms) and the client just sends that - there are > no parameters and no operations beyond that. That's a interesting statement. The fact is that forms constructed by the developer of the application inform the client what type of fields and values are acceptable, and then the client software, seeing that the form is either GET or POST, packages the request into an appropriate operation on the server. When there is no HTML in hand, and no other programatic information, the client has to known what to do. Web browsers assume that any URL that I type into the address bar, and choose to open, should be accessed with GET. The server doesn't "tell" the client to do that, it makes that choice itself. A subsequent HTTP redirect might change what the client sees, but initially the client does not have that knowledge. > > For example POSTed data might go to a java servlet which performs a > > specific > > operation with the associated content. Sending the appropriate > > content is a > > paramount decision. Without the correct data, the invocation of > > POST is not > > purposeful is it? > > The invocation of POST always means the same and it can be purposeful > without any consideration for the data in the case of processors that > just take the data and append it to a list of stuff they keep (for > example Atom servers). But there are lots of other cases where the data is not just "appended", and the content must be meaningful to the consumer. POST is just transporting the content. That content can indicate additional processing such as a SOAP invocation. > >> Are you saying that a client that calls INVOKE does not need to know > >> anything beyond INVOKE? It need not specify the operation to invoke?? > > > > The layer of software that is using INVOKE is not anymore aware of > > the semantics > > associated with the data than a layer of software that would know > > how to use > > HTTP POST correctly. > > Every HTTP client allways knows how to use POST correctly, because > the meaning of POST is defined up front, by the HTTP specs. Every HTTP client which has an HTML form or other content that a server sent it, has such knowledge. Without that form or other knowledge, the client is incapable to know what content should be POSTed. > > The RMI/JERI INVOKE operation, uses the fully qualified method as the > resource. > > The parameters to the method call, if any, are a parallel concept to the > HTTP > > POST content. > > No, they are not. Please describe to me how RMI/JERI invoke can not do the same thing as HTTP POST from a technical and logical perspective because I'm not seeing it. Gregg Wonderly
