You are viewing a plain text version of this content. The canonical link for it is here.
Posted to zeta-dev@incubator.apache.org by Gaetano Giunta <gi...@gmail.com> on 2011/11/04 11:45:55 UTC

[zeta-dev] proposal: an http (webservice) client component

Iirc there was alreday in the past some such request in the past, but it never came to pass.

In this era of mashups and webservices, having something more advanced than a plain curl handle might be a good thingh.

I am offering the source code of my current library, implemented as part of the ggwebservices extension of ezpublish - you can find it here: 
http://svn.projects.ez.no/ggwebservices/trunk/extension/ggwebservices/

- it does not (yet) follow the zetac coding standards, but it is not too far away from them imho
- it follows the original ezpublish soap api
- it implements both client and server side; client side can be scrapped or rewritten based on zc-mvc
- it supports a wide range of protocols: soap, xmlrpc, jsonrpc, rest
- it supports curl and no-curl installations

Any comments are of course welcome

bye
Gaetano

Re: [zeta-dev] proposal: an http (webservice) client component

Posted by Gaetano Giunta <gi...@gmail.com>.
About integration / extension of the MVCTools:
a couple of questions I have so far about ezcMvcHttpRequestParser

1. why is processBody() called within processStandardHeaders()? It should imho not be there, but directly in createRequest(), as request body is not part of 
request headers

2. why is processBody() only saving the request body in case of PUT? Request bodies are also used with other http verbs, such as POST - for eg. json or xml 
encoded request bodies (soap, xmlrpc) it would make a lot of sense to save http request body in the request object, as otherwise apps have to go fetching it by 
themselves (and $_POST is not useful in that case)

3. on a similar vein, no special provision is made for saving the content-type header in the request, but this is a useful header to decide how to interpret the 
request

4. all http headers received in the request that are considered not important are saved only in the request "raw" member. I'd rather use a call to 
getallheaders() (or parse all $_SERVER['HTTP_xxx'] variables) to get the complete list of headers received and store them in an array

Bye
Gaetano

Maxime Thomas wrote:
> +1 !
>
> 2011/11/4 Gaetano Giunta<gi...@gmail.com>
>
>> Iirc there was alreday in the past some such request in the past, but it
>> never came to pass.
>>
>> In this era of mashups and webservices, having something more advanced
>> than a plain curl handle might be a good thingh.
>>
>> I am offering the source code of my current library, implemented as part
>> of the ggwebservices extension of ezpublish - you can find it here:
>> http://svn.projects.ez.no/**ggwebservices/trunk/extension/**ggwebservices/<http://svn.projects.ez.no/ggwebservices/trunk/extension/ggwebservices/>
>>
>> - it does not (yet) follow the zetac coding standards, but it is not too
>> far away from them imho
>> - it follows the original ezpublish soap api
>> - it implements both client and server side; client side can be scrapped
>> or rewritten based on zc-mvc
>> - it supports a wide range of protocols: soap, xmlrpc, jsonrpc, rest
>> - it supports curl and no-curl installations
>>
>> Any comments are of course welcome
>>
>> bye
>> Gaetano
>>
>
>


Re: [zeta-dev] proposal: an http (webservice) client component

Posted by Maxime Thomas <ma...@gmail.com>.
+1 !

2011/11/4 Gaetano Giunta <gi...@gmail.com>

> Iirc there was alreday in the past some such request in the past, but it
> never came to pass.
>
> In this era of mashups and webservices, having something more advanced
> than a plain curl handle might be a good thingh.
>
> I am offering the source code of my current library, implemented as part
> of the ggwebservices extension of ezpublish - you can find it here:
> http://svn.projects.ez.no/**ggwebservices/trunk/extension/**ggwebservices/<http://svn.projects.ez.no/ggwebservices/trunk/extension/ggwebservices/>
>
> - it does not (yet) follow the zetac coding standards, but it is not too
> far away from them imho
> - it follows the original ezpublish soap api
> - it implements both client and server side; client side can be scrapped
> or rewritten based on zc-mvc
> - it supports a wide range of protocols: soap, xmlrpc, jsonrpc, rest
> - it supports curl and no-curl installations
>
> Any comments are of course welcome
>
> bye
> Gaetano
>



-- 
Maxime
maxime.thomas@wascou.org | www.wascou.org | http://twitter.com/wascou