not_found,reason:"missing" when querying couchbase via http

I have couchbase 2.5.1-1083-rel-enterprise on my mac, and 3.0.1-1444-rel-community on my windows machine.

When I create a test document in the default bucket using the admin UI in (2.5) and access it via http, e.g. http://localhost:8092/default/001 I see the document.
When I create any test document using the admin gui in (3.0) on windows and make the same http request, I get {“error”:“not_found”,“reason”:“missing”}, even though the document is visible in “Documents” and I can edit the document via the admin gui?
Has anyone else experienced anything similar in ver 3.0 ? It’s almost as if in version 3.0 you can no longer query a document via http using {server}/{bucket}/{id} url syntax?

I’ve tried creating buckets with and without passwords in 3.0 and this doesn’t appear to make any difference. Also, I can access the documents in 2.5 as well as 3.0 using the GUI as well as with a client library, so it’s not a case of the document not existing in the bucket.

Any advise would be appreciated.



I believe this is an expected change related to the removal of the unsupported _all_docs view. While that may have worked, it wasn’t intended as committed public interface. Things in the UI are supported, but how they’re implemented may change across versions.

If you’re looking to have an HTTP interface to retrieving docs, we’d recommend putting one together with one of the client libraries. @daschl has an example of this using Spring Boot and Spring Data which is only a few lines IIRC.

I agree with @ingenthr, this has to do with removing _alldocs in 3.0, which was never a public interface.

If you tell us what you’re trying to do, we can help you with implementing something similar. Fetching a document should be done through the SDKs (which in turn use a more efficient protocol underneath) and then you can expose it as a HTTP API too.

Hi ingenthr, dachl

Thanks for the reply and for confirming that this feature has been deprecated; I would have been quite concerned if you told me it should still be working!

What I was doing, was trying to very quickly verify that the installation is working as expected, a quick smoke and eyeball test. Since the basic query was returning a not found json result, I couldn’t trust the installation was working. If the requests are not supposed to be used, then why still return a 404, why listen on port 8092 and respond to some requests and not others? That option never occurred to me, instead, a possibly fault installation seemed more likely.

Also, the ability to query views directly from a browser is still there. When you manually create a view, there’s that shortcut link in the UI that allows you to preview the view results? This is quite handy and a quick way to write and test a view.

Yes, I know I could create a 1 liner self hosted MVC type service, e.g. NancyFx in .net or Express with node, … but that’s not the point. The point is to have a very simple means of kicking the tyres of a server after it’s installed to check there’s no smoke leaking anywhere.

I read through all 450-ish pages of the server manual and couldn’t find any reference anywhere to the basic services I should expect to be able to query without a client library. I did find some references to what was deprecated, and read that section carefully, and didn’t find any reference to this specific feature being removed, so was quite concerned that somehow my installation was faulty.


  • Would be nice to know what services are supported via http, and see some documentation on what’s supported, if anything.
  • Documentation should be updated to list features when they are deprecated, even if the features are undocumented, but especially for features that many people are referring to and using in their blog posts, and “getting started” guides, for example : (see"Query Data")
  • Would be helpful if getting started guide should include a very quick smoke test along the lines of 1) create a doc with id (x) 2) check the doc returns 3) create a view 4) check the view returns. Without requiring the use of a client library.
  • Optionally perhaps when creating a bucket, to allow you to tick a checkbox [x] Expose bucket documents via get? (and CLI could allow you to easily enable or disable this dev/test endpoint?)

Just some ideas.



Hey @Goblinfactory,

I think now I know what you’re trying to do and I can help you I guess.

First, let me clear up that this API you were using was never public and therefore just removed (so not even deprecated). Also, 8092 is the internal service port for Views, which is used by the SDKs to perform view and design doc queries. It is not intended for public either.

If you are looking for a HTTP that can be queried, look no further than the 8091 REST API, which is even documented officially:

In general, data operations should always be performed through a SDK, since different protocol and knowledge of the cluster topology are required (this is the whole purpose of the SDK, abstract protocols and the cluster topology management).

Only administrative functionality is available over 8091 and the Admin UI in turn. Each SDK contains getting started sections on how to run the classical hello world samples.

Does that help?

1 Like

Hi daschl

Yes, all clear. The requirement to use SDK is also understandable.
all sorted, thank you.



@Goblinfactory great! Please let us know if you’re running into issues or have further questions.

Hi Daschl

I’ve just seen this:

In the couchbase docs here, the docs encourage you to make rest queries, and the docs even show some curl examples. This appears to contradict what you have said in this thread, that we should only be using the client library (8092) for querying docs in the bucket and (8091) rest API for bucket and system management? (no doc [data] querying)


Querying can be performed through the REST API endpoint. The REST API supports and operates using the core HTTP protocol, and this is the same system used by the client libraries to obtain the view data.