axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <>
Subject Re: Supporting PUT on Axis2/C
Date Tue, 29 Jan 2008 09:57:08 GMT

I spoke to Keith, who worked on REST support on Axis2/Java, and according
to him, you can basically upload files using PUT. In this kind of a
situation the the operation would require having one parameter which is a
FILE pointer. We are looking forward to implement that on Axis2/C, which
would justify the use of a PUT method in RESTful Services' scenarios. Well
on the contrary we could have a servlet like scenario too. But, the
intentions were to implement REST.


See my comments below

> > if there is a need to support PUT as part of  REST my guess is we need
> > to discuss a bit more of where exactly we need PUT to be. The
> > semantics of PUT is to 'store' something in the  server and IMHO our
> > current service model does not have such a semantic [either in REST or
> > SOAP]. The semantic we have right now is a file as an input to a
> > service (if there is file argument somewhere) and that IMHO should be
> > sent in some format in a POST (may be multipart/form-data ?)
> >
> Well can we not leave the semntics of "store" to the service
> implementer? As the engine, what we are interested in is, if it is a PUT
> request, locate the operation that maps to it and pass on the payload.
> Then as far as the engine is concerned we are done. The semantics on
> what to do in within the operation that maps to a PUT is up to the user.
> IMHO, if we try and deal with the REST PUT semantics at the engine
> level, we are making things overly complicated.

I see the point. What I am trying to get at is to see whether there is a
separation where we would use PUT against a POST during a REST call.
in other words
why would I call a service with PUT instead of POST ? if the semantics
of the service is
up to the implementer then it really does not matter whether the
header says PUT or POST - all
that matters would be the information that helps to map to the
service/operation [ Which I believe is the URL ]
But I have to agree that the engine enforcing REST semantics is an
overly complicated solution. If this is
something like providing a servlet like solution [ it was the best
analogy I could think of. Basically you get
doGet,doPost,doPut and doDelete methods that can be overridden at
will] then +1 to go ahead with it.

Ajith Ranabahu

Reading, after a certain age, diverts the mind too much from its
creative pursuits. Any man who reads too much and uses his own brain
too little falls into lazy habits of thinking - Albert Einstein

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

View raw message