You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Version 6.0 introduces some breaking changes to the library. This is a complete re-write to make azd more robust, easy to extend and use. Currently azd uses single Client Api class per Azure DevOps Api (such as BuildApi, CoreApi, GitApi etc..), this is splitted into request builders to provide a declarative syntax and fluent Api style coding experience with single client instance to construct and execute the request.
v6.0 introduces additional configurations such as,
Organization url is not hard coded, so the request can be constructed for Azure DevOps Services as well TFS server.
Authentication: AccessTokenCredentialinterface provides the functionality of choosing the authentication provider. Currently azd supports Personal access token and OAuth on-behalf of authentication.
Json -> POJO and viceversa: SerializerContextinterface provides the serialization and deserialization functionalities.
Paged response/continuation token: All the collects that derives from SerializableCollectionEntity exposes getNextPageLink() method which returns next page based link if continuation token is found in the header.
Note that, some Apis return link:rel=next; in the header and it is not managed by getNextPageLink() method. Instead use getResponse().getResponseHeaders() which returns the HttpResponseHeader object to retrieve the URL.
ClientRequest: ClientRequest is responsible for sending and executing the request and deserializing the response.
Client object: AzDServiceClient helps to create the client object and demands authentication provider.
Declarative syntax: Unlike the Legacy Apis such as BuildApi, GitApi or CoreApi, the client object created using AzDServiceClient can be used to construct the requests and get the response back. See below for example.
TFS or Azure DevOps server support: Support for TFS and Azure DevOps services.
Why changing now?
With the help of community contributors the functionalities of azd has grown huge, to make the code base maintaintable, easy to use, and align the usage more close to Azure DevOps Api. Also, v6.0 introduces declarative syntax to query the Api.
A glimpse of the usage:
// 1. Choose the authentication provider;// AccessTokenCredential interface has few implementations.// --> PersonalAccessTokenCredential - Use with your personal access token.// --> OAuthAccessTokenCredential - Use for on-behalf of user and generate access token aka jwt.// --> OAuthAccessTokenCredential provides automatic token refresh functionality.// For Azure DevOps Services or TFS server the authentication provider object can be created as below// https://dev.azure.com/{organization}// https://server:port/tfs/{collection}varoauthTokenCredential = newOAuthAccessTokenCredential(organizationUrl, projectName, appSecret, authCode, callbackUrl);
varpersonalAccessTokenCredential = newPersonalAccessTokenCredential(organizationUrl, project, personalAccessToken);
// 2. Create the client object with choosen authentication provider.AzDServiceClientclient = AzDService.builder()
.authentication(personalAccessTokenCredential)
.buildClient();
//orAzDServiceClientclient = AzDService.builder()
.authentication(oauthTokenCredential)
.buildClient();
// Single client instance and declarative syntax.client.core().projects().list();
// Usage with query parameters.client.core().projects().list(config -> {
config.queryParameters.top = 100;
config.queryParameters.stateFilter = ProjectState.ALL;
config.queryParameters.getDefaultTeamImageUrl = true;
config.queryParameters.skip = 10;
});
// All the Apis have overloaded methods that returns a CompletableFuture<> object.client.core().projects().listAsync();
What happens to legacy Apis?
Legacy Apis are not going to change and will remain as is, indeed the internal implementations are going to change. The Legacy Apis will implement the new functionalities internally thus providing same output as before. Due to the deprecation of Apis that are used by Legacy Apis a minimal code change is required if you're using any of the Deprecated Apis. It is highly recommended that you move to new implementation.
📢 Announcement!!! ❗❗
Version
6.0
introduces some breaking changes to the library. This is a complete re-write to makeazd
more robust, easy to extend and use. Currentlyazd
uses singleClient Api
class perAzure DevOps Api
(such asBuildApi
,CoreApi
,GitApi
etc..), this is splitted into request builders to provide a declarative syntax and fluent Api style coding experience with singleclient
instance to construct and execute the request.v6.0 introduces additional configurations such as,
What is changing?
Connection
AzDAsyncApi
BaseRestClient
RestClient
RestClientProvider
JsonMapper
AzDService
OAuthAccessTokenBuilder
AccessTokenCredential
ClientRequest
Features
v6.0
brings new features and functionalities.interface
provides the functionality of choosing the authentication provider. Currentlyazd
supports Personal access token and OAuth on-behalf of authentication.interface
provides theserialization
anddeserialization
functionalities.getNextPageLink()
method which returns next page based link if continuation token is found in the header.Note that, some Apis return link:rel=next; in the header and it is not managed by
getNextPageLink()
method. Instead usegetResponse().getResponseHeaders()
which returns theHttpResponseHeader
object to retrieve the URL.authentication provider
.Legacy Apis
such asBuildApi
,GitApi
orCoreApi
, the client object created using AzDServiceClient can be used to construct the requests and get the response back. See below for example.Why changing now?
With the help of community contributors the functionalities of
azd
has grown huge, to make the code base maintaintable, easy to use, and align the usage more close toAzure DevOps Api
. Also,v6.0
introduces declarative syntax to query the Api.A glimpse of the usage:
What happens to legacy Apis?
Legacy Apis
are not going to change and will remain as is, indeed the internal implementations are going to change. TheLegacy Apis
will implement the new functionalities internally thus providing same output as before. Due to the deprecation ofApis
that are used byLegacy Apis
a minimal code change is required if you're using any of the Deprecated Apis. It is highly recommended that you move to new implementation.PS: Latest code can be found here.
The text was updated successfully, but these errors were encountered: