axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <>
Subject RE: Improving REST Support
Date Wed, 23 Jan 2008 19:36:02 GMT
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:- =>
resource => {name}/{subname}

2. We need to read this from the services.xml and store it on the message

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

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.



> 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 []
> Sent: Tuesday, January 22, 2008 8:23 PM
> To:
> 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]
> [2]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> **********************************************************************
> 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:
> For additional commands, e-mail:

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

View raw message