Go API client for bitbucket

REST Resources Provided By: Bitbucket Server - REST

This is the reference document for the Atlassian Bitbucket REST API. The REST API is for developers who want to:

• integrate Bitbucket with other applications;
• create scripts that interact with Bitbucket; or
• develop plugins that enhance the Bitbucket UI, using REST to interact with the backend.

You can read more about developing Bitbucket plugins in the Bitbucket Developer Documentation.

Getting started

Because the REST API is based on open standards, you can use any web development language or command line tool capable of generating an HTTP request to access the API. See the developer documentation for a basic usage example.

If you're already working with the Atlassian SDK, the REST API Browser is a great tool for exploring and experimenting with the Bitbucket REST API.

Structure of the REST URIs

Bitbucket's REST APIs provide access to resources (data entities) via URI paths. To use a REST API, your application will make an HTTP request and parse the response. The Bitbucket REST API uses JSON as its communication format, and the standard HTTP methods like GET, PUT, POST and DELETE. URIs for Bitbucket's REST API resource have the following structure:

    http://host:port/context/rest/api-name/api-version/path/to/resource

For example, the following URI would retrieve a page of the latest commits to the jira repository in the Jira project on https://stash.atlassian.com.

    https://stash.atlassian.com/rest/api/1.0/projects/JIRA/repos/jira/commits

See the API descriptions below for a full list of available resources.

Alternatively we also publish a list of resources in WADL format. It is available here.

Paged APIs

Bitbucket uses paging to conserve server resources and limit response size for resources that return potentially large collections of items. A request to a paged API will result in a values array wrapped in a JSON object with some paging metadata, like this:

    {
        \"size\": 3,
        \"limit\": 3,
        \"isLastPage\": false,
        \"values\": [
            { /_* result 0 *_/ },
            { /_* result 1 *_/ },
            { /_* result 2 *_/ }
        ],
        \"start\": 0,
        \"filter\": null,
        \"nextPageStart\": 3
    }

Clients can use the limit and start query parameters to retrieve the desired number of results.

The limit parameter indicates how many results to return per page. Most APIs default to returning 25 if the limit is left unspecified. This number can be increased, but note that a resource-specific hard limit will apply. These hard limits can be configured by server administrators, so it's always best practice to check the limit attribute on the response to see what limit has been applied. The request to get a larger page should look like this:

    http://host:port/context/rest/api-name/api-version/path/to/resource?limit={desired size of page}

For example:

    https://stash.atlassian.com/rest/api/1.0/projects/JIRA/repos/jira/commits?limit=1000

The start parameter indicates which item should be used as the first item in the page of results. All paged responses contain an isLastPage attribute indicating whether another page of items exists.

Important: If more than one page exists (i.e. the response contains \"isLastPage\": false), the response object will also contain a nextPageStart attribute which must be used by the client as the start parameter on the next request. Identifiers of adjacent objects in a page may not be contiguous, so the start of the next page is not necessarily the start of the last page plus the last page's size. A client should always use nextPageStart to avoid unexpected results from a paged API. The request to get a subsequent page should look like this:

    http://host:port/context/rest/api-name/api-version/path/to/resource?start={nextPageStart from previous response}

For example:

    https://stash.atlassian.com/rest/api/1.0/projects/JIRA/repos/jira/commits?start=25

Authentication

Any authentication that works against Bitbucket will work against the REST API. The preferred authentication methods are HTTP Basic (when using SSL) and OAuth. Other supported methods include: HTTP Cookies and Trusted Applications.

You can find OAuth code samples in several programming languages at bitbucket.org/atlassian_tutorial/atlassian-oauth-examples.

The log-in page uses cookie-based authentication, so if you are using Bitbucket in a browser you can call REST from JavaScript on the page and rely on the authentication that the browser has established.

Errors & Validation

If a request fails due to client error, the resource will return an HTTP response code in the 40x range. These can be broadly categorised into:

HTTP Code	Description
400 (Bad Request)	One or more of the required parameters or attributes: were missing from the request; incorrectly formatted; or inappropriate in the given context.
401 (Unauthorized)	Either: Authentication is required but was not attempted. Authentication was attempted but failed. Authentication was successful but the authenticated user does not have the requisite permission for the resource. See the individual resource documentation for details of required permissions.
403 (Forbidden)	Actions are usually \"forbidden\" if they involve breaching the licensed user limit of the server, or degrading the authenticated user's permission level. See the individual resource documentation for more details.
404 (Not Found)	The entity you are attempting to access, or the project or repository containing it, does not exist.
405 (Method Not Allowed)	The request HTTP method is not appropriate for the targeted resource. For example an HTTP GET to a resource that only accepts an HTTP POST will result in a 405.
409 (Conflict)	The attempted update failed due to some conflict with an existing resource. For example: Creating a project with a key that already exists Merging an out-of-date pull request Deleting a comment that has replies etc. See the individual resource documentation for more details.
415 (Unsupported Media Type)	The request entity has a Content-Type that the server does not support. Almost all of the Bitbucket REST API accepts application/json format, but check the individual resource documentation for more details. Additionally, double-check that you are setting the Content-Type header correctly on your request (e.g. using -H \"Content-Type: application/json\" in cURL).

For 400 HTTP codes the response will typically contain one or more validation error messages, for example:

    {
        \"errors\": [
            {
                \"context\": \"name\",
                \"message\": \"The name should be between 1 and 255 characters.\",
                \"exceptionName\": null
            },
            {
                \"context\": \"email\",
                \"message\": \"The email should be a valid email address.\",
                \"exceptionName\": null
            }
        ]
    }
    

The context attribute indicates which parameter or request entity attribute failed validation. Note that the context may be null.

For 401, 403, 404 and 409 HTTP codes, the response will contain one or more descriptive error messages:

    {
        \"errors\": [
            {
                \"context\": null,
                \"message\": \"A detailed error message.\",
                \"exceptionName\": null
            }
        ]
    }
    

A 500 (Server Error) HTTP code indicates an incorrect resource url or an unexpected server error. Double-check the URL you are trying to access, then report the issue to your server administrator or Atlassian Support if problems persist.

Personal Repositories

Bitbucket allows users to manage their own repositories, called personal repositories. These are repositories associated with the user and to which they always have REPO_ADMIN permission.

Accessing personal repositories via REST is achieved through the normal project-centric REST URLs using the user's slug prefixed by tilde as the project key. E.g. to list personal repositories for a user with slug \"johnsmith\" you would make a GET to:

http://example.com/rest/api/1.0/projects/~johnsmith/repos

In addition to this, Bitbucket allows access to these repositories through an alternate set of user-centric REST URLs beginning with:

http://example.com/rest/api/1.0/users/~{userSlug}/repos

E.g. to list the forks of the repository with slug \"nodejs\" in the personal project of user with slug \"johnsmith\" using the regular REST URL you would make a GET to:

http://example.com/rest/api/1.0/projects/~johnsmith/repos/nodejs/forks

Using the alternate URL, you would make a GET to:

http://example.com/rest/api/1.0/users/johnsmith/repos/nodejs/forks

Overview

This API client was generated by the OpenAPI Generator project. By using the OpenAPI-spec from a remote server, you can easily generate an API client.

• API version: 7.3.1
• Package version: 1.4.0
• Build package: org.openapitools.codegen.languages.GoClientExperimentalCodegen For more information, please visit https://github.com/TwoStone/bitbucket-server-api

Installation

Install the following dependencies:

go get github.com/stretchr/testify/assert
go get golang.org/x/oauth2
go get golang.org/x/net/context

Put the package under your project folder and add the following in import:

import sw "./bitbucket"

Configuration of Server URL

Default configuration comes with Servers field that contains server objects as defined in the OpenAPI specification.

Select Server Configuration

For using other server than the one defined on index 0 set context value sw.ContextServerIndex of type int.

ctx := context.WithValue(context.Background(), sw.ContextServerIndex, 1)

Templated Server URL

Templated server URL is formatted using default variables from configuration or from context value sw.ContextServerVariables of type map[string]string.

ctx := context.WithValue(context.Background(), sw.ContextServerVariables, map[string]string{
	"basePath": "v2",
})

Note, enum values are always validated and all unused variables are silently ignored.

URLs Configuration per Operation

Each operation can use different server URL defined using OperationServers map in the Configuration. An operation is uniquely identifield by "{classname}Service.{nickname}" string. Similar rules for overriding default operation server index and variables applies by using sw.ContextOperationServerIndices and sw.ContextOperationServerVariables context maps.

ctx := context.WithValue(context.Background(), sw.ContextOperationServerIndices, map[string]int{
	"{classname}Service.{nickname}": 2,
})
ctx = context.WithValue(context.Background(), sw.ContextOperationServerVariables, map[string]map[string]string{
	"{classname}Service.{nickname}": {
		"port": "8443",
	},
})

Documentation for API Endpoints

All URIs are relative to https://example.com

Class	Method	HTTP request	Description
BranchesApi	CreateBranch	Post /rest/branch-utils/1.0/projects/{projectKey}/repos/{repositorySlug}/branches	Delete branch
BranchesApi	DeleteBranch	Delete /rest/branch-utils/1.0/projects/{projectKey}/repos/{repositorySlug}/branches
BranchesApi	GetBranchesPaged	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/branches	Get Branches
BranchesApi	GetDefaultBranch	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/branches/default	Get default branch
BuildStatusApi	GetBuildStatusesPaged	Get /rest/build-status/1.0/commits/{commitHash}	Get build statuses
BuildStatusApi	PostBuildResult	Post /rest/build-status/1.0/commits/{commitHash}	Post build-result
CommitsApi	GetCommit	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/commits/{commitId}	Get commit
CommitsApi	GetCommitsPaged	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/commits	Get commits
PostWebhookApi	DeletePostWebhook	Delete /rest/webhook/1.0/projects/{projectKey}/repos/{repositorySlug}/configurations/{ID}	Delete post webhook
PostWebhookApi	GetPostWebhooks	Get /rest/webhook/1.0/projects/{projectKey}/repos/{repositorySlug}/configurations	Get Post Webhooks
ProjectsApi	GetProject	Get /rest/api/1.0/projects/{projectKey}	REST resource for working with projects
ProjectsApi	GetProjectsPaged	Get /rest/api/1.0/projects	Get Projects
PullRequestsApi	CreatePullRequest	Post /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/pull-requests	Create Pull Request
PullRequestsApi	DeletePullRequest	Delete /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/pull-requests/{pullRequestId}	Delete pull request
PullRequestsApi	GetDefaultReviewers	Get /rest/default-reviewers/1.0/projects/{projectKey}/repos/{repositorySlug}/reviewers	Get default reviewers
PullRequestsApi	GetDiff	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/pull-requests/{pullRequestId}.diff	Get PR Diff
PullRequestsApi	GetPullRequest	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/pull-requests/{pullRequestId}	Get pull request
PullRequestsApi	GetPullRequestsPaged	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/pull-requests	Get Pull Request Page
PullRequestsApi	GetRestApi10ProjectsProjectKeyReposRepositorySlugPullRequestsPullRequestIdPatch	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/pull-requests/{pullRequestId}.patch	Get PR Patch
PullRequestsApi	UpdatePullRequest	Put /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/pull-requests/{pullRequestId}	Update pull request
RepositoriesApi	BrowseRepositoryPaged	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/browse	browseRepository
RepositoriesApi	BrowseRepositoryPathPaged	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/browse/{path}	browseRepositoryPath
RepositoriesApi	CreateRepository	Post /rest/api/1.0/projects/{projectKey}/repos	Create repository
RepositoriesApi	GetConfiguredDefaultBranch	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/default-branch	Get default branch
RepositoriesApi	GetRepositoriesPaged	Get /rest/api/1.0/projects/{projectKey}/repos	Get Repositories
RepositoriesApi	GetRepository	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}	Get Repository
RepositoriesApi	SearchRepositoriesPaged	Get /rest/api/1.0/repos	Search repositories
WebhookApi	CreateWebhook	Post /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/webhooks	Create webhook
WebhookApi	DeleteWebhook	Delete /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/webhooks/{webhookId}	Delete Webhook
WebhookApi	GetWebhook	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/webhooks/{webhookId}	Get Webhook
WebhookApi	GetWebhooksPaged	Get /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/webhooks	Get webhooks
WebhookApi	UpdateWebhook	Put /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/webhooks/{webhookId}	Update webhook

Documentation For Models

• Branch
• BranchMetadata
• BranchMetadataAheadBehind
• BranchMetadataBuildStatus
• BranchMetadataJiraIssue
• BranchMetadataOutgoingPullRequest
• BranchMetadataOutgoingPullRequestOneOf
• BranchMetadataOutgoingPullRequestOneOf1
• BranchesPage
• BranchesPageAllOf
• BuildStatus
• BuildStatusPage
• BuildStatusPageAllOf
• Children
• ChildrenAllOf
• ChildrenAllOfValues
• Commit
• CommitParents
• CommitsPage
• CommitsPageAllOf
• CreateBranch
• CreateRepository
• DefaultBranch
• DeleteBranch
• Directory
• Errors
• ErrorsErrors
• File
• FileLines
• FileOrDirectory
• Link
• Page
• Path
• PostWebhook
• Project
• ProjectLinks
• ProjectsPage
• ProjectsPageAllOf
• PullRequest
• PullRequestDelete
• PullRequestState
• PullRequestUpdate
• PullRequestsPage
• PullRequestsPageAllOf
• RepositoriesPage
• RepositoriesPageAllOf
• Repository
• RepositoryLinks
• RepositoryRef
• RepositoryRefRepository
• RepositoryRefRepositoryProject
• User
• UserRole
• Webhook
• WebhookConfiguration
• WebhookEvent
• WebhooksPage
• WebhooksPageAllOf

Documentation For Authorization

usernamePassword

• Type: HTTP basic authentication

Example

auth := context.WithValue(context.Background(), sw.ContextBasicAuth, sw.BasicAuth{
    UserName: "username",
    Password: "password",
})
r, err := client.Service.Operation(auth, args)

Documentation for Utility Methods

Due to the fact that model structure members are all pointers, this package contains a number of utility functions to easily obtain pointers to values of basic types. Each of these functions takes a value of the given basic type and returns a pointer to it:

• PtrBool
• PtrInt
• PtrInt32
• PtrInt64
• PtrFloat
• PtrFloat32
• PtrFloat64
• PtrString
• PtrTime

Author