couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Differing responses for retrieving a deleted document through GET and POST
Date Sat, 08 Oct 2011 18:38:00 GMT
On Sat, Oct 8, 2011 at 5:58 AM, Robert Newson <rnewson@apache.org> wrote:
> Max nails it here. the 200 code indicates the server successfully
> returned a body, which in this case exposes the fact that deleted
> documents are just documents with _deleted:true in them. A 200
> response for a single resource is still meaningful and accurate.
>
> Neither 206 or 410 are appropriate status codes in this case. The
> former is specifically for retrieving parts of an entity (and
> currently the spec only deals in explicit byte ranges of entities) and
> 410 is for a single resource that was once present but is now "Gone".
> As a side note, 410 would be a nice code for deleted documents
> (leaving 404 for the 'never existed' case).
>
> B.
>

We've had the 410 discussion before, but according to the spec it's
not quite appropriate here:

"The 410 (Gone) status code SHOULD be used if the server
   knows, through some internally configurable mechanism, that an old
   resource is permanently unavailable and has no forwarding address."

Since we can recreate docs, 404 seems most appropriate.

> On 8 October 2011 04:20, Jamie Talbot <jamie@jamietalbot.com> wrote:
>> Hey,
>>
>> Appreciate the response.  That does make sense - it's just a shame I
>> have to do that extra step each time, while being able to rely on
>> status codes everywhere else.  (In this particular scenario, sometimes
>> I will have multiple ids, sometimes only one, so the bulk API is the
>> simplest way to handle all cases.)  I had a look to see if I could
>> find what I would consider a better response code, but aside from 410
>> for 'none found' or 206 for 'some found', neither of which are
>> particularly clear, so I'm not really sure what I'd even want :)  200
>> it is!
>>
>> Best,
>>
>> Jamie.
>>
>> On Sat, Oct 8, 2011 at 12:37, Max Ogden <max@maxogden.com> wrote:
>>> hello,
>>>
>>> _all_docs is a "bulk" api which means that it is built to treat its
>>> responses with plurality. this means that the HTTP status code refers not to
>>> the documents but rather the "container" array that you get back.
>>>
>>> you requested all the docs matching some arbitrary set of ids and couch
>>> responds by saying "ok, got all those docs, here ya go" and sends the docs
>>> along with a 200 since the request executed correctly.
>>>
>>> you can either parse the JSON in your app or use non-bulk APIs if you want
>>> to rely solely on the status codes
>>>
>>> On Fri, Oct 7, 2011 at 7:02 PM, Jamie Talbot <jamie@jamietalbot.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I was wondering about what I think is an inconsistency in how
>>>> searching works for documents that have been deleted.  Having deleted
>>>> a document, it no longer appears in _all_docs, as expected.  A GET to
>>>> the document URL return 404 as expected.  However, POSTing the _id in
>>>> 'keys' to _all_docs still returns a document with 200, albeit with
>>>> deleted: true.  Sample steps to reproduce are below:
>>>>
>>>> majelbstoat@Neptune~ $ curl -X POST http://localhost:5984/dummy/ -H
>>>> "Content-Type: application/json" -d "{\"_id\": \"1234\", \"name\":
>>>> \"monkey\"}"
>>>> {"ok":true,"id":"1234","rev":"1-4f1a0c4ebfe937f06161d7c3d90f5cff"}
>>>> majelbstoat@Neptune~ $ curl -X POST http://localhost:5984/dummy/ -H
>>>> "Content-Type: application/json" -d "{\"_id\": \"5678\", \"name\":
>>>> \"magic\"}"
>>>> {"ok":true,"id":"5678","rev":"1-c924380de3517764a68af46a07b5fe6f"}
>>>> majelbstoat@Neptune~ $ curl -X DELETE
>>>> http://localhost:5984/dummy/1234?rev=1-4f1a0c4ebfe937f06161d7c3d90f5cff
>>>> {"ok":true,"id":"1234","rev":"2-2e793b782be7d156372200c5878910dc"}
>>>> majelbstoat@Neptune~ $ curl -X GET http://localhost:5984/dummy/_all_docs
>>>> {"total_rows":1,"offset":0,"rows":[
>>>>
>>>> {"id":"5678","key":"5678","value":{"rev":"1-c924380de3517764a68af46a07b5fe6f"}}
>>>> ]}
>>>> majelbstoat@Neptune~ $ curl -X POST
>>>> http://localhost:5984/dummy/_all_docs -H "Content-Type:
>>>> application/json" -d "{\"keys\": [\"1234\"]}"
>>>> {"total_rows":1,"offset":0,"rows":[
>>>>
>>>> {"id":"1234","key":"1234","value":{"rev":"2-2e793b782be7d156372200c5878910dc","deleted":true}}
>>>> ]}
>>>> majelbstoat@Neptune~ $ curl -X GET http://localhost:5984/dummy/1234
>>>> {"error":"not_found","reason":"deleted"}
>>>>
>>>> Is this a deliberate design decision, and if so is there a particular
>>>> reason for this?  I've been relying heavily on the use of HTTP status
>>>> codes, and receiving 404 in one context and 200 in another is what
>>>> confuses me.  I can of course rewrite the logic to check for a
>>>> 'deleted' key, but decoding the data to do so is less elegant and more
>>>> intensive than just observing the response status.  Unfortunately at
>>>> the moment I have consider all 200 responses suspect, which rather
>>>> diminishes its usefulness for me.
>>>>
>>>> (Version 1.1.0, OSX through Macports).
>>>>
>>>> Cheers,
>>>>
>>>> Jamie.
>>>>
>>>> ---
>>>> http://jamietalbot.com
>>>>
>>>
>>
>>
>>
>> --
>> ---
>> http://jamietalbot.com
>>
>

Mime
View raw message