G'day,

I have been thinking about the idempotency of POST lately, and the
exchange with Steve Bjorg has prompted me to write about it. My current
direction is to treat a POST of null to a factory resource as
idempotent.

A null POST to a factory resource would create a resource that could be
PUT to safely. Either the null POST or the PUT could be repeated safely
if they time out. I'm cautious about using the POE specification due to
the way that it seems to use up the POST method for the created
resource, and doesn't really define a method for creating the temporary
resource in the first place. Null POST idempotency seems to me to be an
appropriate way of thinking about the problem: Add no state to be
demarcated by a temporary resource, then replace that null state with
the content I would have otherwise POSTed. The PUT also converts the
temporary resource into a resource with a normal lifetime.

Potential issues:

1. Idempotency of null POST
My biggest concern is about encoding the idempotency assumption into the
client. If it happened to be unsafe for a particular server, the client
could trigger unfortunate behaviour. For this reason it may be useful to
introduce a new method that performs this setup. I'm thinking something
like PREPARE might be appropriate.

2. Temporary Resource lifetime
Temporary resources would need to expire after some time to allow the
server to reclaim memory and other... well... resources. I suggest that
a rough timer would be the simplest approach: Sweep every 40s and
destroy temporary resources that are still present from the last sweep.
The exact mechanism and timing would be up to the server.

3. Temporary Resources cleaned up too soon
The client behaviour on seeing a 404 come back from PUT might be an
issue. Did the PUT succeed and has the resource been destroyed by normal
means, or did the resource timeout before a successful PUT? It may be
necessary to prevent a live resource from being converted to a 404 too
quickly. Perhaps keeping a 410 up for at least the normal lifetime of
the temporary would indicate to the client that its earlier PUT was
successful. This temporary resource lifetime would have to be long
enough to ensure all reasonable client activity worked correctly. If the
client sees a 404 it has no option but to return an error to its user
indicating that it doesn't know whether the PUT occured or not.

4. Overconsumption of server-side state
The final question is how to deal with clients that issue too many
PREPARE requests, thereby consuming unreasonable quanitities of
server-side resources. It may be important to impose a maximum PREPARE
rate based on source IP or other request characteristic.

Thoughts?

Benjamin.