Subject: Re: PacePutToCreate

From: Ezra Cooper <[email-masked]>
Date: Fri, 9 Jul 2004 14:51:39 -0700

On Jul 8, 2004, at 6:24 PM, Robert Sayre wrote:

> Although the definition of PUT says the effect on the server state is
> undefined, the 201 Response definition[2] states that you have to 
> create the
> resource. So it would appear that you have to serve it there, at least 
> for
> GET. I'll note that the AtomAPI doesn't currently require the EditURI 
> to be
> the same URI created by POSTing to the PostURI.

If I understand this right, you have to serve the entry for a GET to 
the URI where the resource was successfully created; but to Steve's 
question, the server could deny a PUT to any path where the server 
didn't want to serve it up again. So, an example series of transactions 
where the client stubbornly tried to choose it's own path:

   Client:   PUT /base-uri/some/crazy/path
   Server:  301 That's a Crazy Path
   Server:  Location: /base-uri/good-path/nonce-value-1

   Client:  PUT /base-uri/good-path/nonce-value-1
   Server:  201 Created
   Server:  Location: /base-uri/good-path/nonce-value-1

   Client:   PUT /base-uri/some/crazy/path
   Server:  301 That's a Crazy Path
   Server:  Location: /base-uri/good-path/nonce-value-2

   Client:   PUT /base-uri/some-other-crazy/path
   Server:  301 That's a Crazy Path
   Server:  Location: /base-uri/good-path/nonce-value-3

   Client:  PUT /base-uri/good-path/nonce-value-3
   Server:  201 Created
   Server:  Location: /base-uri/good-path/nonce-value-3

   Client:  PUT /archives/2004/07/08/pace_put_to_cre.html
   Server:  201 I Love Your Path
   Server:  Location: /archives/2004/07/08/pace_put_to_cre.html

This seems to me an elegant way to solve the non-idempotence problem, 
together with the question of non-entry-resources.

The only negative I see is that it always requires an extra round-trip 
so that the client knows the right path (of course that's the same with 
any of these magic-token approaches to idempotence). That would 
definitely be an issue when putting big images, or any images from cell 
phones. But the client could post an empty (or minimal) entry until it 
succeeds and knows the URI. Then it could "fill in" that resource with 
a second PUT. To save on bandwidth, maybe we should specify that 
behavior, of PUTting a minimal entry until you have a legit URI?

Would this proposal entail dropping the ability to create a top-level 
resource with POST?

Ezra

---

From: Robert Sayre <[email-masked]>
Date: Fri, 09 Jul 2004 18:20:55 -0400

On 7/8/04 10:47 PM, "Ezra Cooper" <[email-masked]> wrote:

> question, I believe the server could deny a PUT to any path where the
> server didn't want to serve it up again. So, an example series of
> transactions where the client stubbornly tried to choose it's own path:
> 

[examples]

> Is that right?

Yes, but I'm not sure that doing this on purpose is following the spirit of
the RFC. The client should be making a good-faith guess for the path.

> 
> This seems to me an elegant way to solve the non-idempotence problem.
> any of these magic-token approaches to idempotence).

We could mix the two approaches. Instead of asking for a magic token, ask
for a URI to PUT.

> That would 
> succeeds and knows the URI. Then it could update that resource with a
> second PUT? Is that correct?
> 

Yes, it could then update with a second PUT.

Robert Sayre