Spotify Web API Java
This is a Java wrapper/client for the Spotify Web API.
Table of Contents
- Installation
- Jitpack
- Documentation
- General Usage
- Authorization
- Examples
- Contributions
- Code Overview
Installation
The artifact is available through
Maven Central via
Sonatype.
Or to use a snapshot of the latest commit you can use jitpack.io as described further down below.
Maven
Latest official release:
<dependency>
<groupId>se.michaelthelin.spotify</groupId>
<artifactId>spotify-web-api-java</artifactId>
<version>9.0.0-RC1</version>
</dependency>
Latest snapshot:
<dependency>
<groupId>com.github.thelinmichael</groupId>
<artifactId>spotify-web-api-java</artifactId>
<version>master-SNAPSHOT</version>
</dependency>
Gradle
Latest official release:
implementation 'se.michaelthelin.spotify:spotify-web-api-java:9.0.0-RC1'
Latest snapshot:
implementation 'com.github.thelinmichael:spotify-web-api-java:master-SNAPSHOT'
Jitpack
In order to use Jitpack you need to add their repository to your pom.xml
:
Maven
<repositories>
<repository>
<id>jitpack.io</id>
<url>https://jitpack.io</url>
</repository>
</repositories>
Gradle
allprojects {
repositories {
maven { url 'https://jitpack.io' }
}
}
Documentation
See this project's Javadoc.
A huge thanks to c-schuhmann for his amazing work on the documentation!
General Usage
SpotifyApi spotifyApi = new SpotifyApi.Builder()
.setAccessToken("taHZ2SdB-bPA3FsK3D7ZN5npZS47cMy-IEySVEGttOhXmqaVAIo0ESvTCLjLBifhHOHOIuhFUKPW1WMDP7w6dj3MAZdWT8CLI2MkZaXbYLTeoDvXesf2eeiLYPBGdx8tIwQJKgV8XdnzH_DONk")
.build();
final GetSomethingRequest getSomethingRequest = spotifyApi.getSomething("qKRpDADUKrFeKhFHDMdfcu")
.market(CountryCode.SE)
.build();
void getSomething_Sync() {
try {
final Something something = getSomethingRequest.execute();
System.out.println("Name: " + something.getName());
} catch (Exception e) {
System.out.println("Something went wrong!\n" + e.getMessage());
}
}
void getSomething_Async() {
try {
final Future<Something> somethingFuture = getSomethingRequest.executeAsync();
final Something something = somethingFuture.get();
System.out.println("Name: " + something.getName());
} catch (Exception e) {
System.out.println("Something went wrong!\n" + e.getMessage());
}
}
Authorization
Please see Spotify's Authorization Guide too!
For authorization requests the API object requires at least to have
your application's client ID and client secret set as its properties.
When using the authorization code flow, the application's redirect URI is required too. Those properties will then be
automatically used by functions that depend on them.
SpotifyApi spotifyApi = new SpotifyApi.Builder()
.setClientId("<your_client_id>")
.setClientSecret("<your_client_secret>")
.setRedirectUri("<your_redirect_uri>")
.build();
There are three ways to retrieving an access token:
Use the client credentials flow when the requests don't require permission from a specific user. This flow doesn't
return a refresh token and is useful for simple requests, like fetching albums or searching for tracks.
Example: ClientCredentialsExample.java
Using the authorization code flow to retrieve an access token is necessary if the requests are bound to a specific user.
Using this flow returns a refresh token, which can be used to renew the access token before it expires. This is how it
works:
-
The authorization code flow requires a code, which is part of the redirectUri
's query parameters when the user has
opened a custom URL in a browser and authorized the application.
Example: AuthorizationCodeUriExample.java
-
When the code has been retrieved, it can be used in another request to get an access token as well as a refresh token.
Example: AuthorizationCodeExample.java
-
Now, the refresh token in turn can be used in a loop to retrieve new access and refresh tokens.
Example: AuthorizationCodeRefreshExample.java
When you've fetched an access and refresh token, you have to add them to your API properties for automatic usage in
requests. The implementer has to handle the access token's expiration.
spotifyApi
.setAccessToken("<your_access_token>")
.setRefreshToken("<your_refresh_token>")
.build();
The authorization code flow with PKCE is quite like the Authorization Code Flow except that no client secret is necessary
(therefore, it is a good option for mobile and desktop applications). Instead, your application should generate a
code verifier and a code challenge before each authentication request.
The code verifier is a cryptographically random string between 43 and 128 characters in length. It can contain letters, digits, underscores, periods, hyphens, or tildes.
To generate the code challenge, your app should hash the code verifier using the SHA256 algorithm. Then, base64url encode the hash that you generated.
This flow provides your app with an access token which can be refreshed, too.
The steps are similar as above:
-
The authorization code flow with PKCE requires a code, which is part of the redirectUri
's query parameters when the user has
opened a custom URL in a browser and authorized the application. The code challenge is supplied to this request as a query parameter.
Example: AuthorizationCodePKCEUriExample.java
-
When the code has been retrieved, it can be used in another request to get an access token as well as a refresh token.
The code verifier is supplied to this request a query parameter.
Example: AuthorizationCodePKCEExample.java
-
Now, the refresh token in turn can be used in a loop to retrieve new access and refresh tokens.
Example: AuthorizationCodePKCERefreshExample.java
When you have fetched an access and refresh token, you have to add them to your API properties for automatic usage in
requests. The implementer must handle the access token's expiration. The refresh token can be exchanged for an
access token only once, after which it becomes invalid.
Examples
-
Albums
-
Artists
-
Browse
-
Episodes
-
Follow
-
Library
-
Personalization
-
Player
-
Playlists
-
Search
-
Shows
-
Tracks
-
User's Profile
Contributions
See CONTRIBUTING.md.
- Build:
mvn clean install
- Test:
mvn clean test
Requirements: Java, Maven.
Code Overview
This project's main Java package is divided into four sections:
- enumerations
- exceptions
- model objects
- requests.
Those unit-tested parts are connected through various classes that make the API accessible for other Java projects. You
can find details about specific parts or single classes in the sections below.
Enumerations
src/main/java/se.michaelthelin.spotify/enums/
Enumerations allow elements to "be of a type" and limit them to a known value set. They are currently not specified in a
unique place, but are rather scrambled across the online reference. Thus, the reference only allows for construction
of enum classes from this sparse information.
Exceptions
src/main/java/se.michaelthelin.spotify/exceptions/
Exceptions are thrown when errors occur. They are following RFC-specified
HTTP status codes and are packed with a more detailed error
description.
Model Objects
src/main/java/se.michaelthelin.spotify/model_objects/
The model objects are entities that form the API's responses in arranged formats. They are mostly specified in the
Web API Object Model and in the
Web API Authorization Guide. Though, unreferenced model
objects exist. This project subdivides those into...
- "miscellaneous" model objects: these are mentioned somewhere in the reference, but not in the model object list
- "special" model objects: these are not mentioned at all, but appear in API answers nonetheless.
Java classes representing those model objects include private instance variables, a private constructor, but public getter
methods as well as an embedded...
- builder class, including the setter functions and a public build method
- JSON-util class, implementing the
createModelObject
method.
Requests
src/main/java/se.michaelthelin.spotify/requests/
The request classes mirror the structure of Spotify's Web Api endpoints. They are divided into several categories like
authorization
, data/albums
or data/tracks
. They must extend from AbstractDataRequest
and contain an
implementation of the request's execute
method. They have to embed a builder class too, enabling dynamic request
creation.
Tests
src/test/java/se.michaelthelin.spotify/
Unit tests ensure that implemented features work. This project's unit tests are implemented with JUnit
and mockito for mocking.
Fixtures
src/test/fixtures/
Fixtures are JSON files that represent the data returned from the API server. We use the examples directly provided by
the Web API Endpoint Reference with minor tweaks. Tweaks
are needed because the reference sometimes contains invalid data examples.