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.
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 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
