PUT or POST?

[Nikita Tovstoles <ni...@doppelganger.com>]

    We have a webapp that needs to support binary updloads from a remove 
fat client: if our client crashes we'd like it to automatically "send" a 
zipped log file to our web application. the delivered file would NOT be 
stored in Tomcat server's file system - but inserted into db.

Apparently our fat client can issue either a POST or a PUT request. The 
client developer has a slight preference for PUT. I must admit to not 
being familiar with HTTP PUTs - are there any downside to using PUTs 
(aside from having to override doPut())?

thanks
-nikita

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] Re: PUT or POST?

[Christopher Schultz <ch...@christopherschultz.net>]

Nikola,

> It is also a question of semantics. If the technical side is the
> same, then let us communicate our intentions clearly.
> 
> PUT - request that will create an object on the server side,
> accessible via the given URL. Used for object upload.

This is a good point: one of the headers that should be submitted along
with the PUT request is the URL through which the new object should be
available after the PUT successfully completes. If you do not intend to
make that new object available at the specified URL after the PUT, then
you are violating HTTP spec.

Not sure if you care about this violation, but it's something to consider.

-chris

Re: [OT] Re: PUT or POST?

[Nikola Milutinovic <al...@yahoo.com>]

> > Apparently our fat client can issue either a POST or a PUT request. The
> > client developer has a slight preference for PUT. I must admit to not
> > being familiar with HTTP PUTs - are there any downside to using PUTs
> > (aside from having to override doPut())?
>
> I don't think your code will not be any different -- aside from having
> to override the doPut() method in your servlet.
>
> However, the HTTP spec has rules that are most strict when using PUT;
> you have to respect all of the content-* headers among other things, and
> are required to return a 501 NOT IMPLEMENTED if you do not support such
> options.
>
> The bottom line is that HTTP PUT appears to have a more robust set of
> options, but you really should implement them properly. HTTP POST will
> allow you to be a bit lazier in your implementation.

It is also a question of semantics. If the technical side is the same, then let us communicate our intentions clearly.

GET - request which will not change the state of the server side (a.k.a. idempotent method). Used for querying server side.
POST - request that will change the state of the server side. Used for submitting data to the server side.
PUT - request that will create an object on the server side, accessible via the given URL. Used for object upload.
DELETE - delete an an object from the server URL space.

So, one could argue that POST and PUT have similar semantics. They both send data to the server and expect the state of the server side to change. However, PUT is more oriented to the pre-web app era and more inclined to notions of manipulating static content. POST is more inclined to web applications and to notions of submitting data to be processed.

If you expect that crash data will create an object, real or virtual, that will be accessible via the URL you will provide for PUT method, then PUT seams like a good choice. If you are submitting data and some other object may come to exist (like crash report) or not, as a result of that data submission, then POST is a more proper choice.


Nix.



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

[OT] Re: PUT or POST?

[Christopher Schultz <ch...@christopherschultz.net>]

Nikita,

> We have a webapp that needs to support binary updloads from a remove
> fat client: if our client crashes we'd like it to automatically "send" a
> zipped log file to our web application. the delivered file would NOT be
> stored in Tomcat server's file system - but inserted into db.
> 
> Apparently our fat client can issue either a POST or a PUT request. The
> client developer has a slight preference for PUT. I must admit to not
> being familiar with HTTP PUTs - are there any downside to using PUTs
> (aside from having to override doPut())?

I don't think your code will not be any different -- aside from having
to override the doPut() method in your servlet.

However, the HTTP spec has rules that are most strict when using PUT;
you have to respect all of the content-* headers among other things, and
are required to return a 501 NOT IMPLEMENTED if you do not support such
options.

The bottom line is that HTTP PUT appears to have a more robust set of
options, but you really should implement them properly. HTTP POST will
allow you to be a bit lazier in your implementation.

-chris