1. Overview
Spotfire Server REST API for uploading library content.
1.1. Version information
Version : 1
1.2. Tags
-
library-upload : REST API for uploading library content.
2. Authentication and authorization
The API uses the OAuth 2.0 protocol for authentication and authorization, with the Spotfire Server itself as Authorization Server.
Note: The API does not use HTTP sessions so there is no need to maintain session cookies.
Note: All communication should always be done over HTTPS when using OAuth 2.0.
2.1. Basic steps
-
Register an API client using the
register-api-client
command to obtain client credentials.When registering the client you specify what type of client it is, what grants and scopes the client should be able to use etc.
-
Obtain an access token using one of the following alternatives
-
To use the Authorization Code grant follow the instructions in section 4.1 of RFC 6749.
-
To use the Client Credentials grant follow the instructions in section 4.4 of RFC 6749.
-
To use a Refresh Token follow the instructions in section 6 of RFC 6749.
- Additional information on how to get the access token
-
The OAuth 2.0 Authorization Server Metadata (RFC 8414) can be retrieved from:
http[s]://<host>[:<port>]/spotfire/.well-known/oauth-authorization-server
-
The Authorization Endpoint can be accessed at:
http[s]://<host>[:<port>]/spotfire/oauth2/auth
-
The Token Endpoint can be accessed at:
http[s]://<host>[:<port>]/spotfire/oauth2/token
-
When calling the Token Endpoint the client must authenticate using the HTTP Basic authentication scheme as described in section 2.3.1 of RFC 6749, using the credentials obtained when registering the client (unless the client profile is
native
oruser_agent
, in which case no credentials are issued). -
The initial request (to the Authorization Endpoint in the case of the Authorization Code grant, or to the Token Endpoint in the case of the Client Credentials grant) must include any and all scopes required to access the services that the client intend to access (see the documentation of each service for details).
-
-
Include the access token in all requests to the API, in an
Authorization
header as described in section 2.1 of RFC 6750.-
The access token has a limited lifetime, after which a new token must be obtained by repeating step 2.
-
An access token is only valid for the services and operations described in the scope parameter provided when obtaining the access token. The available scopes are described in the documentation for each service.
-
2.2. Additional information
-
Four client profiles are supported:
other
,web
,native
anduser_agent
. The profileother
should be used by a typically headless application performing requests on its own behalf. The profileweb
should be used by a server-side web application performing requests on behalf of an end-user. The profilenative
should be used by a native client, such as an iOS or Android app, performing requests on behalf of an end-user. The profileuser_agent
should be used by a client-side (JavaScript) web application, performing requests on behalf of an end-user. -
The Authorization Code, Client Credentials and Refresh Token grants are supported.
-
Clients with profile
web
,native
oruser_agent
can only use the Authorization Code and Refresh Token grants. Clients with profileother
can only use the Client Credentials grant. -
Refresh tokens MAY be issued to allow access also when no end-user is present (useful when for example performing periodic uploads or similar). To request a refresh token to be issued the scope
offline
should be included in the request to the Authorization Endpoint. For more information see section 1.5 of RFC 6749.-
Refresh tokens that are no longer needed SHOULD be revoked, as described in RFC 7009.
-
-
Public clients (clients without client credentials) MUST use PKCE (RFC 7636). Confidential clients MAY use _PKCE.
-
Native clients can use any of the three ways of receiving the response listed in section 7 of RFC 8252.
-
To use Private-Use URI Scheme Redirection a custom URI scheme must be registered when registering the client.
-
To use Claimed "https" Scheme URI Redirection an authorized redirect URI must be registered when registering the client.
-
Loopback Interface Redirection is supported for all native clients. The scheme must be
http
. The host must be either127.0.0.1
(IPv4) or[::1]
(IPv6). The path can be either/
or/auth
. The port is variable.
-
-
Native clients SHOULD adhere to the guidelines outlined in OAuth 2.0 for Native Apps (RFC 8252).
-
All clients SHOULD implement support for OAuth 2.0 Authorization Server Issuer Identification (RFC 9207).
3. API Endpoint URLs
All API services can be accessed at the following location, where ServicePath is one of the entries in the Resources listing below:
http[s]://<host>[:<port>]/spotfire/api/rest/library/v1/<ServicePath>
Example:
https://example.com:8443/spotfire/api/rest/library/v1/upload/<jobId>
You can download the Open API Specification (OAS) for this REST API as a JSON file from the Spotfire Server http[s]://<host>[:<port>]/spotfire/api/v2/api-docs?group=library
. This OAS file can be accessed at this location by all authenticated users (unless disabled through configuration). The OAS file can be used to generate client stubs, which will contain all types and methods that can be used with the API.
You can also browse the OAS for this REST API using the Swagger UI, available at http[s]://<host>[:<port>]/spotfire/api/swagger-ui.html?urls.primaryName=library
4. Usage
This API is used to upload files to the Spotfire library. All calls assume that a successful authentication has been made, see above. The upload of a file is made through a number of calls. Code examples are available which show how to use the API.
First an initial call is made to start the upload. This call contains information about the file, e.g. its title, path, and file type. This creates an upload job with a unique job id which is used in subsequent calls to upload the file. If the file cannot be uploaded to the specified location in the library, e.g. because the parent folder does not exist, then an error is returned. Even if the initial check is OK things can change while the upload is in progress; for instance it can still fail if the parent directory is removed during the upload.
The file can be uploaded in one or more chunks. This makes it possible to start the upload of a file before the entire file content has been produced. It is also possible to upload different chunks simultaneously. Smaller chunks are often advantageous from a network perspective - if the upload of a single chunk fails it is easier to resend a small chunk rather than a huge one.
When the initial call is made, it possible to also specify the number of chunks that will be sent, or the total number of bytes that will be sent. If these do not match what has been received by the API server when the upload job is finished, it is assumed that something has gone wrong and the upload will be rejected.
The response to an API call will contain links that are specific to an upload job, and that can be used for subsequent calls to the API, c.f. HATEOAS. These links correspond to the API paths shown below. Note that some links require parameters to be supplied before they can be used.
After the initial call the actual payload is uploaded through one or more requests. The content goes in the body of the upload requests. The payload should not be encoded.
It is recommended to provide a digest of the payload via HTTP headers, for verification by the API server. The Content-MD5
header can be used to provide a base64 encoded MD5 digest of the request body, e.g. Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
(RFC 1864), while the Digest
header can be used to provide one (or more) base64 encoded other checksum (SHA, SHA-256, SHA-512), e.g. Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=
(RFC 3230).
It is also good practice to set the Content-Length
HTTP header to signal the size of the chunk to upload. The administrator of the API server can impose size restrictions on uploads, for instance minimum chunk size (applicable to all chunks except the last one), or maximum upload size.
When all chunks have been uploaded, a call is made to signal that the upload is finished and the contents from the different chunks is combined into one file in the Spotfire library. When uploading data, there is an option to set a finished parameter on the request. In this case the upload job is automatically finished when the last chunk has been uploaded.
It is possible to cancel an ongoing upload job. It is also possible to check the status of an ongoing or recent upload job.
Note
|
There is a restriction on which file types that can be uploaded. Currently only Spotfire Binary Data Format (SBDF) files are supported (with library filetype spotfire.sbdf ).
|
Note
|
Clients should be as resilient as possible, e.g. they should be able to handle any 4XX or 5XX http status codes and not just the ones documented here. |
Note
|
In later versions of this API, additional JSON properties might be added. Make the JSON response parsing done by the API client forgiving, so it can accept unexpected properties and different ordering. |
5. Resources
5.1. Library-controller
5.1.1. Create upload job
PUT /upload
Description
Starts a library upload job
Parameters
Type | Name | Description | Schema | Example |
---|---|---|---|---|
Body |
Body |
Information about the content to be uploaded |
Responses
HTTP Code | Description | Schema |
---|---|---|
201 |
Upload job created |
|
400 |
Invalid or incomplete request |
|
403 |
Insufficient library permissions |
|
404 |
Job not found |
|
413 |
Job size limit exceeded |
|
415 |
Invalid content |
|
500 |
Internal server error |
|
503 |
Server busy |
Consumes
-
application/json
Produces
-
application/json
Security
Type | Name | Scope |
---|---|---|
oauth2 |
api.rest.library.upload |
5.1.2. Finish an upload
POST /upload/{jobId}/finish
Description
Finishes a started upload job
Parameters
Type | Name | Description | Schema | Example |
---|---|---|---|---|
Path |
jobId |
The job id |
string |
|
Responses
HTTP Code | Description | Schema |
---|---|---|
200 |
The finished job |
|
400 |
Invalid or incomplete request |
|
403 |
Insufficient library permissions |
|
404 |
Job not found |
|
500 |
Internal server error |
|
503 |
Server busy |
Produces
-
application/json
Security
Type | Name | Scope |
---|---|---|
oauth2 |
api.rest.library.upload |
5.1.3. Check the status of an upload job
GET /upload/{jobId}
Description
Can be used to see if the job succeeded or not, and what chunks have been successfully uploaded
Parameters
Type | Name | Description | Schema | Example |
---|---|---|---|---|
Path |
jobId |
The job id |
string |
|
Responses
HTTP Code | Description | Schema |
---|---|---|
200 |
The status of the job |
Produces
-
application/json
Security
Type | Name | Scope |
---|---|---|
oauth2 |
api.rest.library.upload |
5.1.4. Add data to an upload job
POST /upload/{jobId}
Description
Uploads data to an upload job
Parameters
Type | Name | Description | Schema | Example |
---|---|---|---|---|
Header |
Content-MD5 |
An MD5 digest, according to RFC 1864, of the uploaded data that can be used to verify data integrity. |
string |
|
Header |
Digest |
A digest, according to RFC 3230 and RFC 5843, of the uploaded data that can be used to verify data integrity. Supported algorithms are MD5, SHA, SHA-256 and SHA-512. |
string |
|
Path |
jobId |
The job id |
string |
|
Query |
chunk |
The chunk number |
integer |
|
Query |
finish |
Indicates whether the upload should be immediately finished after this request |
boolean |
Responses
HTTP Code | Description | Schema |
---|---|---|
200 |
Content added to upload job |
|
400 |
Invalid or incomplete request |
|
403 |
Insufficient library permissions |
|
404 |
Job not found |
|
413 |
Job size limit exceeded |
|
415 |
Invalid content |
|
500 |
Internal server error |
|
503 |
Server busy |
Produces
-
application/json
Security
Type | Name | Scope |
---|---|---|
oauth2 |
api.rest.library.upload |
5.1.5. Cancel an upload job
DELETE /upload/{jobId}
Description
Cancels an upload job
Parameters
Type | Name | Description | Schema | Example |
---|---|---|---|---|
Path |
jobId |
The job id |
string |
|
Responses
HTTP Code | Description | Schema |
---|---|---|
200 |
The cancelled job |
|
400 |
Invalid or incomplete request |
|
404 |
Job not found |
|
500 |
Internal server error |
Produces
-
application/json
Security
Type | Name | Scope |
---|---|---|
oauth2 |
api.rest.library.upload |
6. Definitions
6.1. UploadResponse
Defines the result of a request to the upload API. The response contains properties to checkstatus of the upload job, and job specific links to API operations concerning the specific upload job.
Name | Description | Schema |
---|---|---|
uploadLinkBaseRel |
A relative link to the API operation for uploading data chunks to the specific upload job. |
string |
getStatusLinkRel |
A relative link to the API operation for getting the status of the specific upload job. |
string |
cancelLinkRel |
A relative link to the API operation for cancelling the specific upload job. |
string |
finishLinkRel |
A relative link to the API operation for finishing the specific upload job. |
string |
uploadLinkBaseAbs |
An absolute link to the API operation for uploading data chunks to the specific upload job. |
string |
getStatusLinkAbs |
An absolute link to the API operation for getting the status of the specific upload job. |
string |
cancelLinkAbs |
An absolute link to the API operation for cancelling the specific upload job. |
string |
finishLinkAbs |
An absolute link to the API operation for finishing the specific upload job. |
string |
uploadedChunks |
A list containing the numbers of the already uploaded chunks. |
<integer> array |
cancelledAt |
The time at which the upload job was cancelled. |
string |
finishedAt |
The time at which the upload job was finished. |
string |
6.2. Error
Name | Description | Schema |
---|---|---|
code |
A predefined error code. |
string |
description |
A description of the error. |
string |
6.3. Envelope
The payload of an API exchange. Content will vary depending on the API method.
Name | Description | Schema |
---|---|---|
data |
object |
6.4. ErrorResponse
Name | Description | Schema |
---|---|---|
error |
The error response with an error code and a description of the error. |
7. Security
7.1. spotfire-api-oauth2
Type : oauth2
Flow : application
Token URL : /spotfire/oauth2/token
Name | Description |
---|---|
api.rest.library.upload |
Uploading content to the library |
8. Examples
To create a upload job
curl -X PUT 'https://example.com:8443/spotfire/api/rest/library/v1/upload' \ -H 'accept: application/json' \ -H 'authorization: Bearer <REDACTED>' \ -H 'Content-Type: application/json' \ -d '{ "data": { "item": { "description": "Example SBDF File", "keywords": [ "example" ], "parentPath": "/Examples/", "title": "example.sbdf", "type": "spotfire.sbdf" }, "numberOfBytes": 1234, "numberOfChunks": 1, "overwriteIfExists": true } }'
Job is created with job id 44ede823-9061-4ed6-8cdc-909e3dad8ecb
To add data to a job
curl -X POST 'https://example.com:8443/spotfire/api/rest/library/v1/upload/44ede823-9061-4ed6-8cdc-909e3dad8ecb?chunk=1&finish=true' \ -H 'accept: application/json' \ -H 'Content-Length: 1234' \ -H 'authorization: Bearer <REDACTED>' \ -H 'Content-Type: application/octet-stream' \ --data-binary @example.sbdf
Do not include finish=true
in case there are more chunks of data to be uploaded and once all uploaded to finish the job
curl -X POST 'https://example.com:8443/spotfire/api/rest/library/v1/upload/44ede823-9061-4ed6-8cdc-909e3dad8ecb/finish' \ -H 'accept: application/json' \ -H 'authorization: Bearer <REDACTED>'
9. Common Responses
HTTP Code | Description | Reason |
---|---|---|
401 |
Not Authenticated |
The client has not been authenticated |
403 |
Not Authorized |
The client is not authorized to access the requested resource |
500 |
Internal Server Error |
Something went wrong when the processing the request |
10. Error Codes
A request to the API that results in an ErrorResponse will have a response body with the following format:
{
"error": {
"code": "server_busy",
"description": "The server is currently too busy to handle the request"
}
}
where description
is a description of the error, and code
can be one of the following predefined API error codes:
Error Code | HTTP Status | Description |
---|---|---|
invalid_request |
400 |
The request was invalid or incomplete |
precondition_failed |
400 |
A precondition for the request was not met |
bad_digest |
400 |
The supplied digest is not valid or does not match the digest of the request body |
not_authenticated |
401 |
The API client is not authenticated |
not_authorized |
403 |
The API client is not authorized to access the requested resource |
not_found |
404 |
The requested resource cannot be found |
job_unknown |
404 |
The referenced job does not exist, or the client does not have access to it |
method_not_allowed |
405 |
The HTTP method is not allowed |
already_exists |
409 |
The resource already exists |
limit_exceeded |
413 |
A resource limit has been reached |
unsupported_mediatype |
415 |
The media type of the request payload is unsupported |
rate_limit_exceeded |
429 |
A resource limit has been reached |
internal_error |
500 |
The server encountered an error when processing the request |
server_busy |
503 |
The server is currently too busy to handle the request |
11. Configuration
The API is enabled by default. To disable it or to make other configuration changes, use the config-web-service-api
command. For more information see the section Configuration using the command line of the Spotfire© Server and Environment Installation and Administration manual.
12. Additional resources
For more information please refer to these resources:
-
The SDK zip contains an example written in C# for how to call the automation services API and on how to authenticate with the Spotfire Server. For more information on the example see the
readme.txt
in the example:<SDK.zip>\Examples\Integration\SpotfireDeveloper.ServerApiExample