Jan Algermissen wrote: > On Friday, January 19, 2007, at 05:26PM, "Gregg Wonderly" <[EMAIL PROTECTED] > <mailto:gergg%40cox.net>> wrote: > >I'm not sure what your looking for here. HTTP POST and RMI/JERI INVOKE have > the > >exact same capabilities. You can send some content, it is acted on by the > >application on the other end, and you get something back. The semantics on > top > >of either of those operations are defined by the actions of the service > that the > >content is processed by. > > The key question is whether these additional semantics are visible > to/understood by the client. > In the case of REST they are not - the client only knows about the > 'process this' semantics, no more.
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. 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? > 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. 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. The return value is the same as the POST returned content/document. Gregg Wonderly
