axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <>
Subject Re: Improving REST Support
Date Thu, 24 Jan 2008 01:29:36 GMT
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:- =>
> 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 

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.


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

View raw message