CODEWITHSUNDEEP
httprestput
chx
chx

Reputation: 11760

HTTP PUT semantics

Quoting questions from http://www.garfieldtech.com/blog/put-up-with-put ( this is for the Drupal open source project, a little bit meta as no code is here):

GET, HEAD, and PUT are idempotent, but "incidental" side effects such as logging or statistics gathering are OK and not a violation of their idempotence. RFC 2616 has this to say on idempotence:

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. (RFC 2616 section 9.1.2)

I'm not clear on "the side effects are the same" qualifier. Does that mean it can be a repeat of the same side effect, or a net-0 effect?

And then... we've been allowing forward revisions, that is, creating a new version that is not yet the default version, but will be. How does that play into idempotence and PUT? If a new revision is created, then repeating the PUT is not a no-op. Rather, it would create yet another revision. The spec says:

A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server

Put another way:

PUT /node/5 {title: "Hello world"}

Results in:

And that's totally fine, by my read of the spec. However, what of:

PUT /node/5 {title: "Bonjour le monde"}

Results in:

Is that still spec-valid behavior? And if not, does that mean that any system that uses a Create-Read-Archive-Purge (CRAP) model instead of CRUD, or that supports forward revisioning, is inherently not-PUT-compatible?

Upvotes: 3

Views: 1720

Answers (1)

Julian Reschke
Julian Reschke

Reputation: 41997

Creating version resources as side effect is fine. What's relevant is what the client asked for, not what the server decides to do in addition.

See http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-21.html#idempotent.methods -- it's really time to stop looking at RFC 2616.

Upvotes: 2

Related Questions