Re: server applying PUT to a resource other than the request-URI

Have given this some more thought over the last days, and I now stay
completely by the side that "unnamed" PUT is a completely bad idea and
that POST should be used in those situations if really really needed,
even if it means applications need to learn the actual POST protocol

As Brian correctly points out in most cases applications needing servers
to assign resource names at PUT time is a information management design
error. The name should be assigned prior to the PUT, or you'll lose
idempotence and other aspects which is generally important for this kind
of operation.

Yes, it means one round-trip more to the server in applications needing
such naming assignments if they really want to use PUT for creting the
resource (instead of POST, but that's not the end of the world.

Playing games with redirects et al is nice, but does not solve the
problem in a good manner. Neither is adding a new method for the task.

So the recommendation to anyone needing this is

1. Rethink what you are doing. Are you really really sure it's a good

2. If you absolutely must operate in this manner use POST for creating
the resource. There is no standard POST application protocol for
creating server named resources so invent your own ontop of POST. This
could be as simple as having the complete payload just as PUT, or a more
elaborate protocol with added meta data such as the forms POST protocol
or something similar, it's up to the application.


Received on Friday, 24 October 2008 19:22:59 UTC