axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <sen...@wso2.com>
Subject Re: RESTful services, services.xml
Date Fri, 25 Jan 2008 12:10:14 GMT
On Fri, 2008-01-25 at 14:26 +0530, Samisa Abeysinghe wrote:
keith chapman wrote:
> > Hi all,
> >
> > The scheme proposed below will not work because there is no way that
> > you can bind the same operation to 2 HTTP methods. Also it does not
> > make sense. The logic that happens when foo/barp/{x}/{y} is invoked
> > using a GET is completely different to that should happen when
> > foo/barp/{x}/{y}  is invoked via a PUT. On the other hand WSDL cannot
> > represent the following cause an operation is bound to a single
> > HTTPMethod. Therefore the model below will not work.
> >
> > <operation name="foo">
> >              <parameter name="REST">PUT:foo/barp/{x}/{y}</parameter>
> >              <parameter name="REST">GET:foo/barg/{a}/{b}</parameter>
> >  </operation>
> >
>
> I had a look into the WSDL 2.0 and I have to agree with you.
> > However the model below looks good,
> >
> > <operation name="foo">
> >              <parameter name="HTTPMethod" >PUT</parameter>
> >              <parameter name="HTTPLocation" >foo/bar/{x}/{y}</parameter>
> > </operation>
> >
>
> +1. With the change to the param name to reflect tat it is REST, e.g.
> REST_HTTPMethod & REST_HTTPLocation
> > Also it would be good to have a property such as <parameter
> > name="HTTPMethodDefault" >PUT</parameter> on the service level. This
> > would mean that if an operation does not specify a HTTPMethod it would
> > default to the above.
> >
>
> +1. And again the name should be REST_HTTPMethodDefault. Also, we should
> have a universal default, where even when REST_HTTPMethodDefault is
> missing, the system would assume that it is, say, GET.

+1 for a universal default. I think this should be GET too. Because it is
the most common scenario for RESTful operations.

> > WSDL 2.0 also introduces the concept of safety. and If an operation is
> > marked safe it can be invoked via a GET without any side effects. We
> > have plans to restrict GET access in the java implementation to
> > operations that are marked safe explicitly. And hence if an Operation
> > is not marked as safe it cannot be accessed via a GET. This can be
> > captured by adding a parameter as below.
> >
> > <parameter name="safe" >true</parameter>

I think Keith's point is valid if the universal default is GET. We can
capture this and return a suitable error code in such a scenario. However,
we can leave this out for the moment and implement it on a later date.

I believe we can go ahead with the services.xml format agreed here.

Regards,
Senaka

> >
>
> I think for the C implementation, we can ignore this without much side
> effects for the time being.
>
> Thanks,
> Samisa...
> > Thanks,
> > Keith.
> >
> >
> > On Jan 25, 2008 7:27 AM, Samisa Abeysinghe <samisa@wso2.com> wrote:
> >
> >> Senaka Fernando wrote:
> >>
> >>>> 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].
> >>>
> >>>
> >> Our concept of "operation" is differernt form the REST concept of
> >> "operation" here. Our "operation" maps to a function and RESTful
> >> "operation" maps to a piece of logic in that function.
> >> Anyway I need to have revisit the WSDL 2.0 spec to clear this up. Till
> >> then I still think, conceptually, an operation in our description
> >> hierarchy should be mapped to multiple  HTTP methods.
> >>
> >> Samisa...
> >>
> >>
> >>> 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.
> >>>
> >>> [1] http://www.w3.org/TR/wsdl20-adjuncts/#http-binding-id
> >>> [2] http://www.w3.org/TR/wsdl20-adjuncts/#_http_serialization
> >>> [3] http://www.bloglines.com/blog/sanjiva?id=227
> >>> [4] https://wadl.dev.java.net/
> >>>
> >>> Regards,
> >>> Senaka
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >>
> >>
> >>
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message