RESTiness refers to how the service is exposed to the outside world, not to the way Axis handles the request internally. The message receiver determines how Axis handles the request internally.

A REST interface exposes the service as a resource with a unique URL. It supports the following possible operations/methods on that resource (and no others):
- GET
- POST
- PUT
- DELETE

Anne

On 6/29/06, heikki <[EMAIL PROTECTED]> wrote:
Hi there,

it seems I'm not quite getting how Axis2 handles REST vs. SOAP ..

>From the documentation I had gathered that this element in the server side's axis2.xml :

<parameter name="enableREST" locked="false">true</parameter>

should cause REST handling of incoming messages. I had therefore also assumed that setting this parameter to false, or removing it altogether, would cause Axis2 to handle incoming messages as SOAP -- which would mean (I thought) discarding the envelope before binding the payload to the type expected in the SEI.

However, I see no difference in behaviour at all ! Whether I set this parameter to false or true or take it out; Axis2 keeps handling messages as REST messages ! So if I have a client sending SOAP (instead of REST) messages, the SOAP message does not get processed correctly, as it's trying to bind the SOAP:Envelope type to the type expected in the SEI -- it does this even though the enableREST param is false !

I have now modified the generated MyServiceMessageReceiverInOut such that its fromOM() method checks for SOAP-ness of the param and if so, it discards the SOAP envelope before trying to bind the payload. This way it now correctly handles both SOAP and REST messages coming in. But I have a distinct feeling that this is fishy; that I shouldn't have to do this; that I'm missing something here; and that the enableREST parameter setting should have some impact on how Axis2 behaves.


Anyone care to explain these matters ?

thank you !
Heikki Doeleman



Reply via email to