axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <>
Subject Re: RESTful services, services.xml
Date Thu, 24 Jan 2008 17:59:14 GMT
> Senaka Fernando wrote:
>> Hi all,
>> After discussing with Axis2/Java folk, I believe that we should improve
>> the services.xml to support RESTful Services as we don't have a WSDL2.0
>> mode. This is the proposed scheme.
>> [1]. Adding a local http_location mapping for each operation:
>>     <operation name="foo">
>>             <parameter name="HTTPMethod" >PUT</parameter>
>>             <parameter name="HTTPLocation" >foo/bar/{x}/{y}</parameter>
>>     </operation>
> These are REST specific parameters. With or without those in place, SOAP
> should also work, as it used to be. I do think the parameter names
> should reflect that they are REST specific. Otherwise the user will
> confuse them with SOAP cases as well.
> So why not prefix them with REST.
> Also, should we not be able to expose the same service operation, e,g,
> foo, with multiple HTTP methods? How are we supposed to handle that with
> this syntax? If we combine HTTP method with location, I think we can
> handle that case
> e.g.
>     <operation name="foo">
>             <parameter name="REST">PUT:foo/barp/{x}/{y}</parameter>
>             <parameter name="REST">GET:foo/barg/{a}/{b}</parameter>
>     </operation>
> Would that be really RESTful?

Well, in fact WSDL 2.0 includes extensions supporting RESTful services,
and the attempt here, was to mimic the WSDL2.0 spec. Also, each operation
wouldn't have more than one method against it. Thus, I believe it is not
possible to combine the method and the location. This is explained in [1].
However, in order to avoid confusion, I'm +1 for adding the REST prefix,
making it,

1. REST_HTTPMethod
2. REST_HTTPLocation

Any thoughts?

> Also, I was wondering, in case of POST and PUT, do we need {x}/{y} part?
> Because the payload comes in the request body. I think it is only GET
> and DELETE need those {} parts. Am I missing something here?
> Thanks,
> Samisa...

Yes, I believe that the Service Author is not restricted not to add such
parts in the RESTful scenario. So even in PUT and DELETE he may do so, as
in [2].

I believe that the following resources, [3], and [4], would also be useful.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message