incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Differing responses for retrieving a deleted document through GET and POST
Date Sat, 08 Oct 2011 10:58:38 GMT
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.

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