You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Senaka Fernando <se...@wso2.com> on 2008/01/23 05:23:23 UTC
Improving REST Support
Hi all,
I'm interested in improving the REST support on Axis2/C. As a step towards
improving the REST support, what I can do is relay to the service that a
particular type of request was made through the message context and
retrieve the appropriate response from the message context and reply to
the sender. This wont be that much of a trouble in doing. The point is
since we are talking about services, the service will decide what it would
do with the request, not the server. If not, when considering PUT, DELETE,
etc. how am I to implement them?
I read through the references below, plus some others which were not that
very helpful. Hope that they may be of some help.
Thanks,
Senaka
References:
[1] http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1)
[2] http://java.sun.com/developer/technicalArticles/WebServices/restful/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Improving REST Support
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Dave Meier wrote:
> Yes, I had forgotten to put the operation name into the URL. So the
> server should figure out the operation from the "service/operation"
> portion instead of requiring the operation name in an XML payload.
>
> Is this something that is happening in the near term (these changes)? I
> have until late February/early March to complete my work including REST
> calls.
>
First, I think we should do it now rather than be late on it. Also,
looking at the amount of stuff we do, we should be able to have the
initial stuff working by early next month. Anyway, when we start on the
real implementtion, we would know for sure how long that would take.
Thanks,
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
RE: Improving REST Support
Posted by Dave Meier <DM...@SERENA.com>.
Yes, I had forgotten to put the operation name into the URL. So the
server should figure out the operation from the "service/operation"
portion instead of requiring the operation name in an XML payload.
Is this something that is happening in the near term (these changes)? I
have until late February/early March to complete my work including REST
calls.
Thanks!
-Dave.
-----Original Message-----
From: Senaka Fernando [mailto:senaka@wso2.com]
Sent: Wednesday, January 23, 2008 11:36 AM
To: Apache AXIS C Developers List
Subject: RE: Improving REST Support
Hi Dave, and others,
Thanks for the input. I will consider what you've mentioned here. I also
would like to draw your attention to AmazonS3, which Sam Ruby & Leonard
Richardson describe as a RESTful Web Service. The REST API doc can be
found at [1].
According to what is mentioned in the post by Dave as well as in the
book by Sam Ruby & Leonard Richardson, I believe that Axis2/C lacks the
ability of adding the resource name after the name of the operation.
And, most importantly we are not reconizing this as a resource.
Therefore, these are the proposals for the logic.
1. In the services.xml, the Service Author must be able to specify the
format of the resource(s) he expects with slashes.
ex:- http://www.sample.com/service/operation/resource =>
http://www.sample.com/service/operation/first/second
resource => {name}/{subname}
2. We need to read this from the services.xml and store it on the
message context.
2. In the uri based dispatcher, we need to read the message context,
find the resource id format and recognize the resource, then we must add
the resource data into the message context.
3. The http_method will also be added onto the message context.
4. Do the processing according to current implementation, and make use
of http_method as well as resource details.
5. The service writes the state of the operation back onto the message
context.
6. We read the state on the message context and respond with appropriate
http_status_code and payload.
Any comments are most warmly welcome. We also need to add PUT and DELETE
support, which will be relatively easy as it is the services'
responsibility to handle these.
[1] http://docs.amazonwebservices.com/AmazonS3/2006-03-01/RESTAPI.html
Thanks,
Senaka.
> Hi,
>
> I agree that it would be nice to have flexibility with REST as far as
> the I/O to the service. Right now, I am using WSDL2C to generate code
> for my project and the way the code is generated, it requires that the
> high level request and response is always there. If the code
> generation was also updated to be more flexible in handling REST style
> requests, that would really help.
>
> As an example with GET, I have a method that returns all the data
> associated with an item id. The SOAP request requires a structure
> that contains the item id along with userid and password for
authentication.
> Using REST, I would put the item id in the URL, then probably put the
> userid and encoded password into the query string of the URL. If
> there are easy ways to retrieve both pieces of information from inside
> my service that would be great. In the generated code I would like
> the call to go through to my service even if there is no XML payload.
> Then for the response I want to send XML describing the item without
> the SOAP envelope.
>
> If I was using REST to update an item in my service, I would require
> that the XML representation of the item is provided in a PUT. For
> this case it would be the same as the SOAP case except for the lack of
> a SOAP envelope. The only difference might be that I could have the
> item id in the URL and possibly the authentication info as in the GET
> case. Also, all of my data elements in the item are optional, so if
> only one part of the item needs to be updated, only that XML element
would be necessary.
> I suppose for these simple update cases, I could allow the update to
> occur as a GET, with the fields being updated by putting field name
> and value in the query string (e.g.
> http://host:9090/axis2/services/myservice/item543?userid=dave&password
> =A FDGA3435FD&title="my%20new%20title"). For the response I could
> either send an HTTP code or the updated item in XML.
>
> -Dave.
>
> -----Original Message-----
> From: Senaka Fernando [mailto:senaka@wso2.com]
> Sent: Tuesday, January 22, 2008 8:23 PM
> To: axis-c-dev@ws.apache.org
> Subject: Improving REST Support
>
> Hi all,
>
> I'm interested in improving the REST support on Axis2/C. As a step
> towards improving the REST support, what I can do is relay to the
> service that a particular type of request was made through the message
> context and retrieve the appropriate response from the message context
> and reply to the sender. This wont be that much of a trouble in doing.
> The point is since we are talking about services, the service will
> decide what it would do with the request, not the server. If not, when
> considering PUT, DELETE, etc. how am I to implement them?
>
> I read through the references below, plus some others which were not
> that very helpful. Hope that they may be of some help.
>
> Thanks,
> Senaka
>
> References:
> [1] http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1)
> [2]
> http://java.sun.com/developer/technicalArticles/WebServices/restful/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
> **********************************************************************
> 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: 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
Re: Improving REST Support
Posted by Samisa Abeysinghe <sa...@wso2.com>.
I had a chat with Keith, who did the REST stuff in Axis2/Java.
They have implemented this with WSDL 2.0, which we do not have.
So, we have to go with the service.xml model. Apparently, Axis2/Java too
seem to have plans to do that model as well.
We can use annotations to map to the HTTP method/operation/parameters in
the service.xml file.
e.g.
GET:add/{a}/{b}
PUT:setQuote/{name}/{price}
In terms of dispatching, the payload could be built only when we look at
and understand the request URI. Hence, we have to implement a "REST
Dispatcher". This would be similar to the URI based dispatcher. However,
would not be on the same path as the SOAP processing path. Once the
request comes, we can get to know it if is SOAP or REST by looking at
the content type, and if it is SOAP we invoke the regular dispatchers
and if now, invoke the REST dispatcher. After dispatching, the remainder
of the invocation would be the same for both REST and SOAP.
Thanks,
Samisa...
Samisa Abeysinghe wrote:
> Senaka Fernando wrote:
>> Hi Dave, and others,
>>
>> Thanks for the input. I will consider what you've mentioned here. I also
>> would like to draw your attention to AmazonS3, which Sam Ruby & Leonard
>> Richardson describe as a RESTful Web Service. The REST API doc can be
>> found at [1].
>>
>> According to what is mentioned in the post by Dave as well as in the
>> book by
>> Sam Ruby & Leonard Richardson, I believe that Axis2/C lacks the
>> ability of
>> adding the resource name after the name of the operation. And, most
>> importantly we are not reconizing this as a resource. Therefore,
>> these are
>> the proposals for the logic.
>>
>> 1. In the services.xml, the Service Author must be able to specify the
>> format of the resource(s) he expects with slashes.
>> ex:- http://www.sample.com/service/operation/resource =>
>> http://www.sample.com/service/operation/first/second
>> resource => {name}/{subname}
>>
>
> Is this the way Axis2/Java folks has done it. We do not need to
> re-invent the wheel here. Can have a peek into how Java folks have
> done it, because it is the same architecture.
>> 2. We need to read this from the services.xml and store it on the
>> message
>> context.
>>
>> 2. In the uri based dispatcher, we need to read the message context,
>> find
>> the resource id format and recognize the resource, then we must add the
>> resource data into the message context.
>>
> Rather than adding resource data, we can build the request payload as
> an AXIOM model. This way we can keep the SOAP and REST models the same
> - useful when exposing the services in both ways.
>
> Also, when this is implemented, the model that we already have should
> be kept in place - that is the current implementation with the request
> parameters. Since that works, it is worth keeping that too.
>> 3. The http_method will also be added onto the message context.
>>
>
> This is a transport level detail. So it should be handled at transport
> level. I am not sure if we have this detail in message context right
> now. Anyway, when adding PUT and DELETE, you can use the same
> techniques we are already using for GET and POST. Put is analogous to
> POST and DELETE to GET. Since our GET and PORT already work well, we
> better use the same techniques.
>> 4. Do the processing according to current implementation, and make
>> use of
>> http_method as well as resource details.
>> 5. The service writes the state of the operation back onto the message
>> context.
>>
>> 6. We read the state on the message context and respond with appropriate
>> http_status_code and payload.
>>
>
> 5 and 6 are already in place for GET & POST. You just need to add PUT
> and DELETE.
>
> An interesting question would be to see how to map the semantics of
> PUT and DELETE to operation invocations. As an example, DELETE is
> supposed to remove a resource - does this mean that we are removing an
> operation? Does PUT mean we are adding a new operation? I am still not
> clear on how to map that. Again Axis2/Java could come to rescue.
>
> Thanks,
> Samisa...
>
> ---------------------------------------------------------------------
> 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
Re: Improving REST Support
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Senaka Fernando wrote:
> Hi Dave, and others,
>
> Thanks for the input. I will consider what you've mentioned here. I also
> would like to draw your attention to AmazonS3, which Sam Ruby & Leonard
> Richardson describe as a RESTful Web Service. The REST API doc can be
> found at [1].
>
> According to what is mentioned in the post by Dave as well as in the book by
> Sam Ruby & Leonard Richardson, I believe that Axis2/C lacks the ability of
> adding the resource name after the name of the operation. And, most
> importantly we are not reconizing this as a resource. Therefore, these are
> the proposals for the logic.
>
> 1. In the services.xml, the Service Author must be able to specify the
> format of the resource(s) he expects with slashes.
> ex:- http://www.sample.com/service/operation/resource =>
> http://www.sample.com/service/operation/first/second
> resource => {name}/{subname}
>
Is this the way Axis2/Java folks has done it. We do not need to
re-invent the wheel here. Can have a peek into how Java folks have done
it, because it is the same architecture.
> 2. We need to read this from the services.xml and store it on the message
> context.
>
> 2. In the uri based dispatcher, we need to read the message context, find
> the resource id format and recognize the resource, then we must add the
> resource data into the message context.
>
Rather than adding resource data, we can build the request payload as an
AXIOM model. This way we can keep the SOAP and REST models the same -
useful when exposing the services in both ways.
Also, when this is implemented, the model that we already have should be
kept in place - that is the current implementation with the request
parameters. Since that works, it is worth keeping that too.
> 3. The http_method will also be added onto the message context.
>
This is a transport level detail. So it should be handled at transport
level. I am not sure if we have this detail in message context right
now. Anyway, when adding PUT and DELETE, you can use the same techniques
we are already using for GET and POST. Put is analogous to POST and
DELETE to GET. Since our GET and PORT already work well, we better use
the same techniques.
> 4. Do the processing according to current implementation, and make use of
> http_method as well as resource details.
>
> 5. The service writes the state of the operation back onto the message
> context.
>
> 6. We read the state on the message context and respond with appropriate
> http_status_code and payload.
>
5 and 6 are already in place for GET & POST. You just need to add PUT
and DELETE.
An interesting question would be to see how to map the semantics of PUT
and DELETE to operation invocations. As an example, DELETE is supposed
to remove a resource - does this mean that we are removing an operation?
Does PUT mean we are adding a new operation? I am still not clear on how
to map that. Again Axis2/Java could come to rescue.
Thanks,
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
RE: Improving REST Support
Posted by Senaka Fernando <se...@wso2.com>.
Hi Dave, and others,
Thanks for the input. I will consider what you've mentioned here. I also
would like to draw your attention to AmazonS3, which Sam Ruby & Leonard
Richardson describe as a RESTful Web Service. The REST API doc can be
found at [1].
According to what is mentioned in the post by Dave as well as in the book by
Sam Ruby & Leonard Richardson, I believe that Axis2/C lacks the ability of
adding the resource name after the name of the operation. And, most
importantly we are not reconizing this as a resource. Therefore, these are
the proposals for the logic.
1. In the services.xml, the Service Author must be able to specify the
format of the resource(s) he expects with slashes.
ex:- http://www.sample.com/service/operation/resource =>
http://www.sample.com/service/operation/first/second
resource => {name}/{subname}
2. We need to read this from the services.xml and store it on the message
context.
2. In the uri based dispatcher, we need to read the message context, find
the resource id format and recognize the resource, then we must add the
resource data into the message context.
3. The http_method will also be added onto the message context.
4. Do the processing according to current implementation, and make use of
http_method as well as resource details.
5. The service writes the state of the operation back onto the message
context.
6. We read the state on the message context and respond with appropriate
http_status_code and payload.
Any comments are most warmly welcome. We also need to add PUT and DELETE
support, which will be relatively easy as it is the services'
responsibility to handle these.
[1] http://docs.amazonwebservices.com/AmazonS3/2006-03-01/RESTAPI.html
Thanks,
Senaka.
> Hi,
>
> I agree that it would be nice to have flexibility with REST as far as
> the I/O to the service. Right now, I am using WSDL2C to generate code
> for my project and the way the code is generated, it requires that the
> high level request and response is always there. If the code generation
> was also updated to be more flexible in handling REST style requests,
> that would really help.
>
> As an example with GET, I have a method that returns all the data
> associated with an item id. The SOAP request requires a structure that
> contains the item id along with userid and password for authentication.
> Using REST, I would put the item id in the URL, then probably put the
> userid and encoded password into the query string of the URL. If there
> are easy ways to retrieve both pieces of information from inside my
> service that would be great. In the generated code I would like the
> call to go through to my service even if there is no XML payload. Then
> for the response I want to send XML describing the item without the SOAP
> envelope.
>
> If I was using REST to update an item in my service, I would require
> that the XML representation of the item is provided in a PUT. For this
> case it would be the same as the SOAP case except for the lack of a SOAP
> envelope. The only difference might be that I could have the item id in
> the URL and possibly the authentication info as in the GET case. Also,
> all of my data elements in the item are optional, so if only one part of
> the item needs to be updated, only that XML element would be necessary.
> I suppose for these simple update cases, I could allow the update to
> occur as a GET, with the fields being updated by putting field name and
> value in the query string (e.g.
> http://host:9090/axis2/services/myservice/item543?userid=dave&password=A
> FDGA3435FD&title="my%20new%20title"). For the response I could either
> send an HTTP code or the updated item in XML.
>
> -Dave.
>
> -----Original Message-----
> From: Senaka Fernando [mailto:senaka@wso2.com]
> Sent: Tuesday, January 22, 2008 8:23 PM
> To: axis-c-dev@ws.apache.org
> Subject: Improving REST Support
>
> Hi all,
>
> I'm interested in improving the REST support on Axis2/C. As a step
> towards improving the REST support, what I can do is relay to the
> service that a particular type of request was made through the message
> context and retrieve the appropriate response from the message context
> and reply to the sender. This wont be that much of a trouble in doing.
> The point is since we are talking about services, the service will
> decide what it would do with the request, not the server. If not, when
> considering PUT, DELETE, etc. how am I to implement them?
>
> I read through the references below, plus some others which were not
> that very helpful. Hope that they may be of some help.
>
> Thanks,
> Senaka
>
> References:
> [1] http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1)
> [2] http://java.sun.com/developer/technicalArticles/WebServices/restful/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
> **********************************************************************
> 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: 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
RE: Improving REST Support
Posted by Dave Meier <DM...@SERENA.com>.
Hi,
I agree that it would be nice to have flexibility with REST as far as
the I/O to the service. Right now, I am using WSDL2C to generate code
for my project and the way the code is generated, it requires that the
high level request and response is always there. If the code generation
was also updated to be more flexible in handling REST style requests,
that would really help.
As an example with GET, I have a method that returns all the data
associated with an item id. The SOAP request requires a structure that
contains the item id along with userid and password for authentication.
Using REST, I would put the item id in the URL, then probably put the
userid and encoded password into the query string of the URL. If there
are easy ways to retrieve both pieces of information from inside my
service that would be great. In the generated code I would like the
call to go through to my service even if there is no XML payload. Then
for the response I want to send XML describing the item without the SOAP
envelope.
If I was using REST to update an item in my service, I would require
that the XML representation of the item is provided in a PUT. For this
case it would be the same as the SOAP case except for the lack of a SOAP
envelope. The only difference might be that I could have the item id in
the URL and possibly the authentication info as in the GET case. Also,
all of my data elements in the item are optional, so if only one part of
the item needs to be updated, only that XML element would be necessary.
I suppose for these simple update cases, I could allow the update to
occur as a GET, with the fields being updated by putting field name and
value in the query string (e.g.
http://host:9090/axis2/services/myservice/item543?userid=dave&password=A
FDGA3435FD&title="my%20new%20title"). For the response I could either
send an HTTP code or the updated item in XML.
-Dave.
-----Original Message-----
From: Senaka Fernando [mailto:senaka@wso2.com]
Sent: Tuesday, January 22, 2008 8:23 PM
To: axis-c-dev@ws.apache.org
Subject: Improving REST Support
Hi all,
I'm interested in improving the REST support on Axis2/C. As a step
towards improving the REST support, what I can do is relay to the
service that a particular type of request was made through the message
context and retrieve the appropriate response from the message context
and reply to the sender. This wont be that much of a trouble in doing.
The point is since we are talking about services, the service will
decide what it would do with the request, not the server. If not, when
considering PUT, DELETE, etc. how am I to implement them?
I read through the references below, plus some others which were not
that very helpful. Hope that they may be of some help.
Thanks,
Senaka
References:
[1] http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1)
[2] http://java.sun.com/developer/technicalArticles/WebServices/restful/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
**********************************************************************
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org