Davanum Srinivas' weblog

That's certainly an understandable position. I've even been known to submit a patch or two to Axis.

However, I have a few scenarios that I don't even begin to know how to approach. Example, how should Axis handle the following status code?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2

Sam,

Of course i was not referring to you :) One main difference is humans who use the browser to interact with the server know exactly what it means and know that they have to update bookmarks etc. But what do we do in the code is the question. Let's put this another way, what would the guy doing Python/XHTML handle this? suppose he is writing a cronjob that runs that code?

-- dims

Dims - here is a very related discussion, complete with related problems:

http://www.intertwingly.net/blog/2002/10/14/HTTP-301

At that time, the Radio Userland aggregator would follow the redirects, but would not change the subscriptions. Dave Winer then added a table to accumulates redirection info, and then added code to check the table.

Dims, that wasn't bug in Axis. It was a problem with the server I was communicating with.

Robert,

though my comments were triggered by your post, it was not a direct result of it...It has been stewing inside me for a while now. it's a general potshot :)

-- dims

Dims --

I won't argue whether AXIS (or JAX-RPC) is good or evil and when, but I think that AXIS gets a bum rap because people don't appreciate its role or place. Apache SOAP qualifies as an early prototype, and AXIS was the first product version built on the lessons learned. Few if any of the people who currently throw stones at AXIS/JAX-RPC/WS-* had the foresight or vision to throw those stone in advance. (Frankly, many of AXIS's flaws are inherited from JAX-RPC, IMHO...)

Folks should be thankful that hard work was invested to test ideas in a very public forum, that a useful but imperfect product resulted, and that a new version is underway.

You get a pat on the back for your hard work and a tip of my hat for getting back on the horse for the next lap.

Cheers.
-- Paul

"Specifically by engaging on the specs in the standards bodies"

Been there, done that. Quite often, the answer is "abandon this work" since its existence is necessarily counter to Web architecture. WSDL comes to mind. UDDI too. Ditto WS-MetadataExchange, WS-Addressing (more or less), and probably others I'm forgetting.

I also tried suggesting changes to Axis to support the SOAP 1.2 Web method feature, but those were nixed in favour of a change which didn't "shake the boat" so much and by treating the web method separately from the RPC operation. It's a total hack with inconsistent request and response semantics (for RESTful developers), since the Axis stack assumes protocol independence.

Mark,

Could you please review what we are doing in Axis2? We absolutely want to do things the right way. This missive was part of that effort. To get enough info to do the right thing. We need your help :)

thanks,
dims

I think part of the problem is that it's still not clear to Axis developers what RESTful really means. Consider the RESTful "echo" example from http://ws.apache.org/axis2/rest-ws.html

Despite the "setDoREST(true)" bit, the call is still invoked via;

OMElement result = call.invokeBlocking("echo", payload);

So the operation is "echo", not the HTTP operation. That's what's gotta change in Axis for it to be usable RESTfully. Well, I'm oversimplifying a little bit, but that's basically it...

So Mark, we've been here before :-).

What Axis2 is implementing is something that will fully support the WSDL2 HTTP binding with a common programming model for HTTP and for SOAP.

I know for a fact that doesn't meet your requirements of "supporting REST."

If you really want an API for doing REST (aka HTTP) then please use HTTPConnection or some such beast and be happy with it.

It makes no sense to do that in Axis2 (or Axis3 or Axis4 IMO); what we need is to support Web services as a unifying model for SOAP and REST both. The plan in Axis2 is to get that as right as possible. (Undoubtedly we won't get it right; hopefully it'll be closer than the previous iteration.)

"It makes no sense to do that in Axis2 (or Axis3 or Axis4 IMO); what we need is to support Web services as a unifying model for SOAP and REST both."

SOAP can be used RESTfully, don't forget. My comment above was describing why the Axis2 APIs can't do that, easily. If there was a single place in the API for the "operation", then this would simplify things tremendously for developers.

Is "invokeBlocking" new or old? http://ws.apache.org/axis2/api/org/apache/axis/clientapi/Call.html doesn't show it. If it's old, then that's good news, since the rest of the Call API looks pretty good to me; mostly just SOAPEnvelopes in and out (setAction scares me though). The setTransportType stuff could still be done better, because you need to be able to distinguish between, say, HTTP PUT and POST of a SOAP envelope, and it would be far more intuitive to specify that at send* invocation time, not setTransportType time.

I'm kind of working backwards there, from the existing API towards an improved one. Starting from scratch would be a nice luxury, since it's really not very hard to support both RESTful and RPC at the same time. It's a shame that the existing API embraces "protocol independence" so tightly - the root of all its problems in supporting RESTful interactions.

I agree Axis2 lack a way to say is it GET or POST when it is HTTP. But when we design the API we work hard to make it "protocol independant". It is matter of different expectations and we have to cooose between :(

Unfortunately, Srinath, a "protocol independent" API - where the application semantics are independent of the underlying protocol - necessarily means an API unsuitable for RESTful use.

Srinath,

We have a way of setting the transport (http / commons-http) why can't we add a way to specify some transport specific params (GET/POST) along with it?

-- dims

Setting the HTTP operation arbitrarily doesn't make sense. If you have some XML to send, it CANNOT be GET. If you have nothing to send then GET or POST is fine.

This is why what we really need to do is support codegen for the WSDL 2.0 HTTP binding. Then whatever is in the WSDL we can do.

An API for REST that satisfies Mark will never be an API for SOAP. Mark if that's not true please comment.

Sanjiva.

Sanjiva,

+1 to "codegen for the WSDL 2.0 HTTP binding". BUT i think we can strike a balance that will satisfy everyone though we may have to draw the line somewhere. Let's us work thru the issues (comments here and on Savas' blog) and ask Mark to review the API again soon (after 0.95).

-- dims

I like the Apache example of sticking a REST EPR in a SOAP envelop. With that approach you could still use alot of the WS-* specs.