Re: RESTful services, services.xml
> keith chapman wrote:
>> Wouldn't it be better to follow the WSDL 2.0 property names so that
>> you have a one to one mapping between property names in the
>> services.xml. WSDL 2.0 property names are whttp:httploaction and
>> whttp:httpmethod where whttp is the namespace of the httpBinding.
>>
>
> But that is less readable IMHO as far as the users are concerned -
> someone looking at service XML would not be able to infer that this is a
> REST property.
+1, and, besides reading from a WSDL and reading from a services.xml would
necessarily be two separate paths and thus, would not matter. Because we
would not in fact search an attribute with whttp:httpLocation, but rather
an attribute with prefix whttp and local-part httpLocation. I hope I'm not
missing anything here.
Regards,
Senaka
>
> Samisa...
>> Thanks,
>> Keith.
>>
>> On Jan 25, 2008 4:21 PM, Dumindu Pallewela <[EMAIL PROTECTED]> wrote:
>>
>>> On Jan 25, 2008 2:26 PM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:
>>>
>>> [snip]
>>>
>
> PUT
> >foo/bar/{x}/{y}
>
>
>
+1. With the change to the param name to reflect tat it is REST, e.g.
REST_HTTPMethod & REST_HTTPLocation
>>> [/snip]
>>>
>>> Won't *RESTMethod* and *RESTLocation* be better, as HTTP is assumed
>>> anyway?
>>>
>>> -Dumindu.
>>>
>>> --
>>> Dumindu Pallewela
>>> http://blog.dumindu.com
>>> GPG ID: 0x9E131672
>>>
>>> WSO2 | "Oxygenating the Web Service Platform" | http://wso2.com
>>>
>>>
>>> -
>>> 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]
Re: RESTful services, services.xml
keith chapman wrote:
Wouldn't it be better to follow the WSDL 2.0 property names so that
you have a one to one mapping between property names in the
services.xml. WSDL 2.0 property names are whttp:httploaction and
whttp:httpmethod where whttp is the namespace of the httpBinding.
But that is less readable IMHO as far as the users are concerned -
someone looking at service XML would not be able to infer that this is a
REST property.
Samisa...
Thanks,
Keith.
On Jan 25, 2008 4:21 PM, Dumindu Pallewela <[EMAIL PROTECTED]> wrote:
On Jan 25, 2008 2:26 PM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:
[snip]
PUT
foo/bar/{x}/{y}
+1. With the change to the param name to reflect tat it is REST, e.g.
REST_HTTPMethod & REST_HTTPLocation
[/snip]
Won't *RESTMethod* and *RESTLocation* be better, as HTTP is assumed anyway?
-Dumindu.
--
Dumindu Pallewela
http://blog.dumindu.com
GPG ID: 0x9E131672
WSO2 | "Oxygenating the Web Service Platform" | http://wso2.com
-
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]
Re: RESTful services, services.xml
Wouldn't it be better to follow the WSDL 2.0 property names so that
you have a one to one mapping between property names in the
services.xml. WSDL 2.0 property names are whttp:httploaction and
whttp:httpmethod where whttp is the namespace of the httpBinding.
Thanks,
Keith.
On Jan 25, 2008 4:21 PM, Dumindu Pallewela <[EMAIL PROTECTED]> wrote:
> On Jan 25, 2008 2:26 PM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:
>
> [snip]
> > >
> > >
> > > PUT
> > > foo/bar/{x}/{y}
> > >
> > >
> >
> > +1. With the change to the param name to reflect tat it is REST, e.g.
> > REST_HTTPMethod & REST_HTTPLocation
> [/snip]
>
> Won't *RESTMethod* and *RESTLocation* be better, as HTTP is assumed anyway?
>
> -Dumindu.
>
> --
> Dumindu Pallewela
> http://blog.dumindu.com
> GPG ID: 0x9E131672
>
> WSO2 | "Oxygenating the Web Service Platform" | http://wso2.com
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Keith Chapman
Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RESTful services, services.xml
> Dumindu Pallewela wrote:
>> On Jan 25, 2008 2:26 PM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:
>>
>> [snip]
>>
PUT
>>> >foo/bar/{x}/{y}
>>> +1. With the change to the param name to reflect tat it is REST, e.g.
>>> REST_HTTPMethod & REST_HTTPLocation
>>>
>> [/snip]
>>
>> Won't *RESTMethod* and *RESTLocation* be better, as HTTP is assumed
>> anyway?
>>
+1
Regards,
Senaka
>
> +1.
>
> Samisa...
>
>
> -
> 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]
Re: RESTful services, services.xml
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.
> >
> >
> > PUT:foo/barp/{x}/{y}
> > GET:foo/barg/{a}/{b}
> >
> >
>
> I had a look into the WSDL 2.0 and I have to agree with you.
> > However the model below looks good,
> >
> >
> > PUT
> > foo/bar/{x}/{y}
> >
> >
>
> +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 > name="HTTPMethodDefault" >PUT 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.
> >
> > true
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 <[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:
> >
> >
> > PUT
> > foo/bar/{x}/{y}
> >
> >
> >
> >
> 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.
>
>
> PUT:foo/barp/{x}/{y}
> GET:foo/barg/{a}/{b}
>
>
> 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 belie
Re: RESTful services, services.xml
Dumindu Pallewela wrote:
On Jan 25, 2008 2:26 PM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:
[snip]
PUT
foo/bar/{x}/{y}
+1. With the change to the param name to reflect tat it is REST, e.g.
REST_HTTPMethod & REST_HTTPLocation
[/snip]
Won't *RESTMethod* and *RESTLocation* be better, as HTTP is assumed anyway?
+1.
Samisa...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RESTful services, services.xml
On Jan 25, 2008 2:26 PM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:
[snip]
> >
> >
> > PUT
> > foo/bar/{x}/{y}
> >
> >
>
> +1. With the change to the param name to reflect tat it is REST, e.g.
> REST_HTTPMethod & REST_HTTPLocation
[/snip]
Won't *RESTMethod* and *RESTLocation* be better, as HTTP is assumed anyway?
-Dumindu.
--
Dumindu Pallewela
http://blog.dumindu.com
GPG ID: 0x9E131672
WSO2 | "Oxygenating the Web Service Platform" | http://wso2.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RESTful services, services.xml
If the HTTPMethod is not specified and if the operation is not safe it
should default to POST.
Thanks,
Keith.
On Jan 25, 2008 2:26 PM, Samisa Abeysinghe <[EMAIL PROTECTED]> 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.
> >
> >
> > PUT:foo/barp/{x}/{y}
> > GET:foo/barg/{a}/{b}
> >
> >
>
> I had a look into the WSDL 2.0 and I have to agree with you.
> > However the model below looks good,
> >
> >
> > PUT
> > foo/bar/{x}/{y}
> >
> >
>
> +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 > name="HTTPMethodDefault" >PUT 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.
> >
> > true
> >
>
> 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:
> >
> >
> > PUT
> > foo/bar/{x}/{y}
> >
> >
> >
> >
> 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.
>
>
> PUT:foo/barp/{x}/{y}
> GET:foo/barg/{a}/{b}
>
>
> 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/#
Re: RESTful services, services.xml
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.
PUT:foo/barp/{x}/{y}
GET:foo/barg/{a}/{b}
I had a look into the WSDL 2.0 and I have to agree with you.
However the model below looks good,
PUT
foo/bar/{x}/{y}
+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 PUT 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.
true
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:
PUT
foo/bar/{x}/{y}
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.
PUT:foo/barp/{x}/{y}
GET:foo/barg/{a}/{b}
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]
Re: RESTful services, services.xml
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.
PUT:foo/barp/{x}/{y}
GET:foo/barg/{a}/{b}
However the model below looks good,
PUT
foo/bar/{x}/{y}
Also it would be good to have a property such as PUT on the service level. This
would mean that if an operation does not specify a HTTPMethod it would
default to the above.
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.
true
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:
> >>>
> >>>
> >>> PUT
> >>> foo/bar/{x}/{y}
> >>>
> >>>
> >>>
> >> 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.
> >>
> >>
> >> PUT:foo/barp/{x}/{y}
> >> GET:foo/barg/{a}/{b}
> >>
> >>
> >> 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]
>
>
--
Keith Chapman
Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RESTful services, services.xml
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:
PUT
foo/bar/{x}/{y}
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.
PUT:foo/barp/{x}/{y}
GET:foo/barg/{a}/{b}
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]
RE: RESTful services, services.xml
Hi Dave,
I guess it is not done that way. Your GET operation would target the GET
call and the PUT operation would target the PUT call. The engine is not
supposed to relay the operation's behavior depending on the HTTP Method.
You can have multiple operations doing multiple tasks of course, as you
are not limited to one operation per service.
Of course you have this option. Your client will see both operations by
the same name, if there would be no ambiguity. As you see, the behavior is
not like SOAP. For instance this is possible.
ex:- GET http://localhost:9090/service/upload/file?blah=blah and PUT
http://localhost:9090/service/upload/file.
After reading below you may notice, that this is not ambiguous. The
mapping would be like this.
GET
This is a sample service.
PUT
upload/{x}
GET
upload/{x}
What I'm trying to tell is that you only need to have this
operation-has-only-one-method limitation on the server side. The consuming
client will not at all notice.
Regards,
Senaka
> I agree that for a given operation, multiple HTTP methods need to be
> supported. For my update item operation, I want to support taking a big
> XML chunk with lots of data to update (PUT), or allow the caller to
> simply specify one or two pieces of data in the query string to update
> (GET). I know GET is not supposed to side effect the data, but I still
> want to support this simplified way of updating (is this okay?).
>
> Alternatively I may want to allow a PUT where all the data is in the URL
> and there is actually no XML data being posted. So we would still need
> to allow the {x}/{y} part of the URL on PUT in order to
> accomplish this.
>
> -Dave.
>
> -Original Message-
> From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 24, 2008 8:38 AM
> To: Apache AXIS C Developers List
> Subject: Re: RESTful services, services.xml
>
> 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:
>>
>>
>> PUT
>> >foo/bar/{x}/{y}
>>
>>
>
> 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.
>
>
> PUT:foo/barp/{x}/{y}
> GET:foo/barg/{a}/{b}
>
>
> Would that be really RESTful?
>
> Also, I was wondering, in case of POST and PUT, do we need {x}/{y} part?
>
> Becuase 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...
>> [2]. Specification of the default HTTPMethod for a service:
>>
>> GET
>>
>> [3]. This is the explanation of HTTPLocation parameter.
>>
>> 1. This is the trailing portion of the URL after the service name.
>> 2. This may or may not start with the operation name.
>> 3. This may include constant portions and variable portions.
>> 4. Variable portions are included inside '{' '}' (curly braces).
>> 5. Curly braces are escaped as {{ or }}.
>> 6. Escaping of curly braces adds another limitation, being we can't
>> specify constant portions inside a variable portion and vice versa.
>> 7. Separation of portions is done by '/'s.
>> 8. HTTPLocation can include query-string portions that need 2 be
> matched.
>> 9. Thus, someone can make the order of the query string parameters
>> significant.
>> 10. Un-specified areas are not captured.
>>
>> This is a sample RESTful services' service.xml:
>>
>>
>> GET
>>
>> This is a sample service.
>>
>>
>> PUT
>> >foo/bar/{x}/{y}
>>
>>
>>
>> [4]. This is a sample request to this service
>> ex:- http://localhost:9090/sample/foo/bar/12/14?query
>>
>> Please add your comments and suggestions.
>>
>> Regards,
>> Senaka
>&
RE: RESTful services, services.xml
I agree that for a given operation, multiple HTTP methods need to be
supported. For my update item operation, I want to support taking a big
XML chunk with lots of data to update (PUT), or allow the caller to
simply specify one or two pieces of data in the query string to update
(GET). I know GET is not supposed to side effect the data, but I still
want to support this simplified way of updating (is this okay?).
Alternatively I may want to allow a PUT where all the data is in the URL
and there is actually no XML data being posted. So we would still need
to allow the {x}/{y} part of the URL on PUT in order to
accomplish this.
-Dave.
-Original Message-
From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 24, 2008 8:38 AM
To: Apache AXIS C Developers List
Subject: Re: RESTful services, services.xml
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:
>
>
> PUT
> foo/bar/{x}/{y}
>
>
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.
PUT:foo/barp/{x}/{y}
GET:foo/barg/{a}/{b}
Would that be really RESTful?
Also, I was wondering, in case of POST and PUT, do we need {x}/{y} part?
Becuase 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...
> [2]. Specification of the default HTTPMethod for a service:
>
> GET
>
> [3]. This is the explanation of HTTPLocation parameter.
>
> 1. This is the trailing portion of the URL after the service name.
> 2. This may or may not start with the operation name.
> 3. This may include constant portions and variable portions.
> 4. Variable portions are included inside '{' '}' (curly braces).
> 5. Curly braces are escaped as {{ or }}.
> 6. Escaping of curly braces adds another limitation, being we can't
> specify constant portions inside a variable portion and vice versa.
> 7. Separation of portions is done by '/'s.
> 8. HTTPLocation can include query-string portions that need 2 be
matched.
> 9. Thus, someone can make the order of the query string parameters
> significant.
> 10. Un-specified areas are not captured.
>
> This is a sample RESTful services' service.xml:
>
>
> GET
>
> This is a sample service.
>
>
> PUT
> foo/bar/{x}/{y}
>
>
>
> [4]. This is a sample request to this service
> ex:- http://localhost:9090/sample/foo/bar/12/14?query
>
> Please add your comments and suggestions.
>
> 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]
**
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. Any
unauthorized review, use, disclosure or distribution is prohibited. If you are
not the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message.
**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RESTful services, services.xml
> 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:
>>
>>
>> PUT
>> foo/bar/{x}/{y}
>>
>>
>
> 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.
>
>
> PUT:foo/barp/{x}/{y}
> GET:foo/barg/{a}/{b}
>
>
> 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.
[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]
Re: RESTful services, services.xml
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:
PUT
foo/bar/{x}/{y}
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.
PUT:foo/barp/{x}/{y}
GET:foo/barg/{a}/{b}
Would that be really RESTful?
Also, I was wondering, in case of POST and PUT, do we need {x}/{y} part?
Becuase 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...
[2]. Specification of the default HTTPMethod for a service:
GET
[3]. This is the explanation of HTTPLocation parameter.
1. This is the trailing portion of the URL after the service name.
2. This may or may not start with the operation name.
3. This may include constant portions and variable portions.
4. Variable portions are included inside '{' '}' (curly braces).
5. Curly braces are escaped as {{ or }}.
6. Escaping of curly braces adds another limitation, being we can't
specify constant portions inside a variable portion and vice versa.
7. Separation of portions is done by '/'s.
8. HTTPLocation can include query-string portions that need 2 be matched.
9. Thus, someone can make the order of the query string parameters
significant.
10. Un-specified areas are not captured.
This is a sample RESTful services' service.xml:
GET
This is a sample service.
PUT
foo/bar/{x}/{y}
[4]. This is a sample request to this service
ex:- http://localhost:9090/sample/foo/bar/12/14?query
Please add your comments and suggestions.
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]
RESTful services, services.xml
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:
PUT
foo/bar/{x}/{y}
[2]. Specification of the default HTTPMethod for a service:
GET
[3]. This is the explanation of HTTPLocation parameter.
1. This is the trailing portion of the URL after the service name.
2. This may or may not start with the operation name.
3. This may include constant portions and variable portions.
4. Variable portions are included inside '{' '}' (curly braces).
5. Curly braces are escaped as {{ or }}.
6. Escaping of curly braces adds another limitation, being we can't
specify constant portions inside a variable portion and vice versa.
7. Separation of portions is done by '/'s.
8. HTTPLocation can include query-string portions that need 2 be matched.
9. Thus, someone can make the order of the query string parameters
significant.
10. Un-specified areas are not captured.
This is a sample RESTful services' service.xml:
GET
This is a sample service.
PUT
foo/bar/{x}/{y}
[4]. This is a sample request to this service
ex:- http://localhost:9090/sample/foo/bar/12/14?query
Please add your comments and suggestions.
Regards,
Senaka
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
