From dev-return-18433-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Thu Oct 6 20:45:52 2011 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1F3237D32 for ; Thu, 6 Oct 2011 20:45:52 +0000 (UTC) Received: (qmail 62318 invoked by uid 500); 6 Oct 2011 20:45:51 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 62185 invoked by uid 500); 6 Oct 2011 20:45:51 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 62173 invoked by uid 99); 6 Oct 2011 20:45:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Oct 2011 20:45:51 +0000 X-ASF-Spam-Status: No, hits=-2000.5 required=5.0 tests=ALL_TRUSTED,NORMAL_HTTP_TO_IP,RP_MATCHES_RCVD,WEIRD_PORT X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Oct 2011 20:45:50 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id AEF012AD214 for ; Thu, 6 Oct 2011 20:45:29 +0000 (UTC) Date: Thu, 6 Oct 2011 20:45:29 +0000 (UTC) From: "Benjamin Young (Commented) (JIRA)" To: dev@couchdb.apache.org Message-ID: <39173852.5119.1317933929718.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (COUCHDB-642) Support rev in PUT URL MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/COUCHDB-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122275#comment-13122275 ] Benjamin Young commented on COUCHDB-642: ---------------------------------------- >From a REST perspective nothing in the query string or header should take precedence over the content body. Meaning, the "rev" query parameter value really shouldn't override the "_rev" keys value in the document. Updating the _rev in the JSON object seems like a very small "cost" in exchange for the cumbersome "order of preference" given to various query parameters or headers. The content body is the canonical source for the document--especially in regards to a PUT. The DELETE case doesn't require a content body, so issuing it with a "rev" is mandatory as it semantically specifies the resource your deleting. You can delete documents via POST, but in that case the _rev is included in the content body (as it should be)--which matches the PUT use case. -1 as it's just not worth the "confusion cost" for a nice-to-have. > Support rev in PUT URL > ---------------------- > > Key: COUCHDB-642 > URL: https://issues.apache.org/jira/browse/COUCHDB-642 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface > Environment: trunk 08 Feb 2010 > Reporter: Brian Candler > Priority: Minor > Attachments: 0001-Allow-for-the-current-revision-number-to-be.patch > > > A DELETE request lets you append ?rev=xxxx to the URL. But this doesn't work with a PUT request; you have to put the _rev in the body instead (even though the _id is taken from the URL path) > $ curl -X PUT -d "{}" http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo > {"ok":true,"id":"foo","rev":"1-967a00dff5e02add41819138abb3284d"} > $ curl -X PUT -d "{}" http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo?rev=1-967a00dff5e02add41819138abb3284d > {"error":"conflict","reason":"Document update conflict."} > $ curl -X PUT -d '{"_rev":"1-967a00dff5e02add41819138abb3284d"}' http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo > {"ok":true,"id":"foo","rev":"2-7051cbe5c8faecd085a3fa619e6e6337"} > Allowing ?rev in the URL would make PUT and DELETE more consistent, and would allow you to replace an existing JSON doc with another one without having to merge the _rev into it first. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira