Gitlab's API (GET /projects/:id/repository/tree) throws 404 page not found

Question

According to GitLabs API documentation to get a repository tree via restful api call I should do the following, this excerpt is from the documentation which can be found here, it says that

List repository tree

Get a list of repository files and directories in a project.

GET /projects/:id/repository/tree Parameters:

id (required) - The ID of a project

path (optional) - The path inside repository. Used to get contend of subdirectories

ref_name (optional)-The name of a repository branch or tag or if not given the default branch

But when I do call to the above web service it returns

404 The page you were looking for doesn't exist.

I call http://myserverurl/api/v3/projects/:id/repository/tree?private_token=myprivatetoken and I get 404, of-course I pass the id of the project here which is an integer like 4, 5, 6 etc.

All the other API's work fine except for this one, is there something I am missing here?

These are my error logs from the production.log file

Started GET
"/api/v3/projects/:id/repository/tree?private_token=mytoken&id=4" for
at 2013-06-13 12:48:36 +0530 ActionController::RoutingError (No route
matches [GET] "/api/v3/projects/:id/repository/tree"):
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_dispatch/middleware/debug_exceptions.rb:21:in
`call'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_dispatch/middleware/show_exceptions.rb:56:in
`call'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/rack/logger.rb:32:in
`call_app'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/rack/logger.rb:16:in
`block in call'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/tagged_logging.rb:22:in
`tagged'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/rack/logger.rb:16:in
`call'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_dispatch/middleware/request_id.rb:22:in
`call'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/methodoverride.rb:21:in
`call'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/runtime.rb:17:in
`call' vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/lock.rb:15:in
`call'
vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:136:in
`forward'
vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:245:in
`fetch'
vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:185:in
`lookup'
vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:66:in
`call!'
vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:51:in
`call'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/engine.rb:479:in
`call'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/application.rb:223:in
`call'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/railtie/configurable.rb:30:in
`method_missing'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/builder.rb:134:in
`call'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/urlmap.rb:64:in
`block in call'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/urlmap.rb:49:in
`each'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/urlmap.rb:49:in
`call'
vendor/bundle/ruby/1.9.1/gems/puma-2.0.1/lib/puma/configuration.rb:66:in
`call'
vendor/bundle/ruby/1.9.1/gems/puma-2.0.1/lib/puma/server.rb:364:in
`handle_request'
vendor/bundle/ruby/1.9.1/gems/puma-2.0.1/lib/puma/server.rb:243:in
`process_client'
vendor/bundle/ruby/1.9.1/gems/puma-2.0.1/lib/puma/server.rb:142:in
`block in run'
vendor/bundle/ruby/1.9.1/gems/puma-2.0.1/lib/puma/thread_pool.rb:92:in
`call'
vendor/bundle/ruby/1.9.1/gems/puma-2.0.1/lib/puma/thread_pool.rb:92:in
`block in spawn_thread'

Answer 1

The Gitlab API page ""Status Code" section mentions:

404 Not Found

A resource could not be accessed, e.g. an ID for a resource could not be found

So either the id is incorrect (which it shouldn't be if other API calls succeeds).

Or 'tree' isn't enough, but a path should be provided (unless the project tree is empty).

Or there is some kind of permission issue which would prevent, on the server, the API to access the content of that repo.

But if the issue persists for any path, then it is worth to add that case to the list of GitLab issues.

As the OP mentions, that is also an indication that the API isn't available in the code.

Answer 2

This was my issue, I didn't realize that this api was available only on master branch as of 19/06/2013, when I switched my branch from stable to master it resolved the above issue, to switch the branch I used

sudo -u git -H git checkout master

Then I had to do

sudo bundle install

to install some extra gems on master branch and then I restarted nginx and gitlab using sudo service nginx restart and sudo service gitlab start and finally that seemed to resolve all api issues I had.