You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2007/06/01 03:51:03 UTC
Re: More problems with implementing servlet services
Grzegorz Kossakowski wrote:
> Joerg Heinicke pisze:
>> On 19.05.2007 14:28, Grzegorz Kossakowski wrote:
>>
>> One more reason to always put the service URL into the src attribute
>> as you don't need to discuss and differentiate between GET and POST.
+1
> Yes I have to explain meaning of the "postData" parameter and its use.
> Really, POST and GET are conceptually different beasts and I believe we
> should not try to hide this differences anyhow.
I don't buy it. What about PUT? DELETE? TRACE? OPTIONS? HEAD? Is every method
going to get its own syntax and its own generator type? GetGenerator,
PostGenerator, DeleteGenerator? It does not make any sense to me. Request is a
request is a request. Request method is just one single piece of information in
the request and it is not making conceptual difference. Ideally all request
method should be treated equally. In the case of this service generator, it just
means it should take parameter specifying what request method to use... what
headers to set... what data to include in the body (notice how I avoided the
word 'post' here - cause it could be 'put', or any other method)... But the src
attribute of generator is url of the service - everything else is an optional
parameter: request method defaults to GET, request body by default is empty, etc.
Vadim
Re: More problems with implementing servlet services
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Grzegorz Kossakowski wrote:
> Vadim Gritsenko pisze:
>> I don't buy it. What about PUT? DELETE? TRACE? OPTIONS? HEAD? Is every
>> method going to get its own syntax and its own generator type?
>> GetGenerator, PostGenerator, DeleteGenerator? It does not make any
>> sense to me.
>
> Servlet services are tied to POST request and there is no way to call
> the _service_ using DELETE method. How could you interpret such a call?
Easy. Delete service. Takes request parameter as input and goes in and deletes
stuff identified by this parameter.
> Servlet services called during pipeline processing are about
> transforming the XML and usually they are expected to have no side-effects.
>
> To answer you question, there will no syntax for PUT, DELETE, TRACE,
> OPTIONS, HEAD because all of them are not service calls.
>
>> Request is a request is a request. Request method is just one single
>> piece of information in the request and it is not making conceptual
>> difference. Ideally all request method should be treated equally. In
>> the case of this service generator, it just means it should take
>> parameter specifying what request method to use... what headers to
>> set... what data to include in the body (notice how I avoided the word
>> 'post' here - cause it could be 'put', or any other method)... But the
>> src attribute of generator is url of the service - everything else is
>> an optional parameter: request method defaults to GET, request body by
>> default is empty
>
> The request body cannot be empty because the called pipeline has no data
> to start with. Empty data means that it's _not_ the service call.
There are lots of real life web services which do not take (posted) data as an
argument. Plenty of services can work only off parameters. Weather, stocks, etc.
> If you
> just want to perform casual GET you should use servlet: source with
> FileGenerator exactly the same way as for any other GET operation.
How about casual OPTIONS operation? How do I do it with FileGenerator?
Vadim
Re: More problems with implementing servlet services
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Vadim Gritsenko pisze:
> I don't buy it. What about PUT? DELETE? TRACE? OPTIONS? HEAD? Is every
> method going to get its own syntax and its own generator type?
> GetGenerator, PostGenerator, DeleteGenerator? It does not make any sense
> to me.
Servlet services are tied to POST request and there is no way to call the _service_ using DELETE method. How could you interpret such a
call? Servlet services called during pipeline processing are about transforming the XML and usually they are expected to have no side-effects.
To answer you question, there will no syntax for PUT, DELETE, TRACE, OPTIONS, HEAD because all of them are not service calls.
> Request is a request is a request. Request method is just one
> single piece of information in the request and it is not making
> conceptual difference. Ideally all request method should be treated
> equally. In the case of this service generator, it just means it should
> take parameter specifying what request method to use... what headers to
> set... what data to include in the body (notice how I avoided the word
> 'post' here - cause it could be 'put', or any other method)... But the
> src attribute of generator is url of the service - everything else is an
> optional parameter: request method defaults to GET, request body by
> default is empty
The request body cannot be empty because the called pipeline has no data to start with. Empty data means that it's _not_ the service call.
If you just want to perform casual GET you should use servlet: source with FileGenerator exactly the same way as for any other GET operation.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: More problems with implementing servlet services
Posted by Peter Hunsberger <pe...@gmail.com>.
On 5/31/07, Vadim Gritsenko <va...@reverycodes.com> wrote:
> Grzegorz Kossakowski wrote:
> > Joerg Heinicke pisze:
> >> On 19.05.2007 14:28, Grzegorz Kossakowski wrote:
> >>
> >> One more reason to always put the service URL into the src attribute
> >> as you don't need to discuss and differentiate between GET and POST.
>
> +1
>
> > Yes I have to explain meaning of the "postData" parameter and its use.
> > Really, POST and GET are conceptually different beasts and I believe we
> > should not try to hide this differences anyhow.
>
> I don't buy it. What about PUT? DELETE? TRACE? OPTIONS? HEAD? Is every method
> going to get its own syntax and its own generator type? GetGenerator,
> PostGenerator, DeleteGenerator? It does not make any sense to me. Request is a
> request is a request.
+1 (I've already had this discussion with Grzegorz). I agree there
is absolutely no reason to treat POST and GET as "conceptually
different beasts". They are conceptually identical; they differ only
in the implementation details of how they pass data to the server.
> Request method is just one single piece of information in
> the request and it is not making conceptual difference. Ideally all request
> method should be treated equally. In the case of this service generator, it just
> means it should take parameter specifying what request method to use... what
> headers to set... what data to include in the body (notice how I avoided the
> word 'post' here - cause it could be 'put', or any other method)... But the src
> attribute of generator is url of the service - everything else is an optional
> parameter: request method defaults to GET, request body by default is empty, etc.
>
> Vadim
>
--
Peter Hunsberger