- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Fri, 24 Oct 2008 21:22:22 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-Id: <1224876142.3231.153.camel@henriknordstrom.net>
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 used. 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 idea? 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. Regards Henrik
Received on Friday, 24 October 2008 19:22:59 UTC