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