About Axis 2.0 again (via Mark Baker’s blog).
This page describes how “RESTful Web Services” are supported by Axis 2.0.
“REST is providing access to the resources through the two methods GET and POST. The REST Web services are reduced subset of the usual Web Service stack, and the Axis2 REST implementation assumes following properties.”
I really don’t understand what they mean by “REST implementation”. REST is an architectural style. REST is not implemented. REST tells us how to build a distributed application around resources using a set of rules. REST does not mean HTTP GET or PUT or POST or whatever. We can build systems which violate the principles of REST using HTTP GET and PUT or build RESTful applications without HTTP at all as I tried to demonstrate in my WS-Web post (The Web using SOAP:-) some time ago. I believe that it’s one thing for the API of a platform to help you if you want to build RESTful applications and a completely different to advocate that your platform implements REST. Perhaps it’s a wording thing. I don’t know.
I do hope Mark Baker and the rest 😉 of the RESTferians will correct me if I am wrong but it seems to me that “REST” is misunderstood and is becoming more of a tech buzzword rather than a principled approach to building distributed, resource-oriented systems.
6 responses to “REST in Axis 2.0???”
I agree it’s often misused/misapplied, but I don’t see a big problem with “REST implementation” since I assume it means “an implementation which was designed to be used RESTfully” (i.e. designed to enforce the constraints of REST). Would you have the same concern if somebody said “pipe-and-filter implementation”, or “client/server implementation”?
Hi Mark,
Yes, i would have had a problem if someone had said that their hosting or runtime environment is a “client/server implementation”. Client-server is an approach to building distributed systems. We build the components of our systems in a client-server manner. A framework/runtime/hosting environment is used to build systems like that. It may support a client-server model or it can be more flexible. But it’s not a “client-server implementation” itself.
Anyway, I can see how this is a minor detail compared to grand scale of things 🙂
Maybe the problem is with us (Axis2 folks) calling this “REST support.” I’ll tell you the motivation: allow users to write the biz logic once and expose that with a SOAP API and with an HTTP GET/POST API. The latter will over time be compliant with WSDL 2.0’s HTTP binding.
Not sure whether this helps understand our design point but that’s where it comes from.
Sanjiva.
And I forgot to add .. if you guys
ARGH! Sorry ’bout that …
.. if you guys think there’s a better way to do it please please come to the axis-dev mailing list and help us get it improved. This is a true open sourc community developed effort; if there’s a better way we’re happy to embrace and extend it ;-).
Sanjiva.
Hey Sanjiva,
thanks for the comments. I am sorry if you took my post to mean that this was not the right approach. On the contrary. I’m glad to see that support for all architectural styles is considered. I was just commenting on the wording. I think that “Support for RESTful applications” or “support for the REST architectural style” would have been better alternatives to “REST implementation”. But that’s just a minor issue with the wording rather than the excellent work that you guys are doing. Keep it up.