Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

RESTful API Overview

 

You access the RESTful API by sending HTTPS requests to specific URLs (endpoints) on the JSA Console. To send these requests, use the HTTP implementation that is built in to the programming language of your choice. Each request contains authentication information, and parameters that modify the request.

JSA and API Versions

Every JSA version has a REST API version, as described in the following table:

Table 1: JSA and API Versions

JSA version

REST API version

API version support status

7.3.2

Version 10.n

Supported

7.3.1.n

Version 9.n

Supported.

7.3.0.n

Version 8.n

Deprecated in JSA 7.3.2.

2014.8.n and earlier

Version 7.n and earlier

No longer supported.

   

API Endpoints

An API endpoint contains the URL of the resource that you want to access and the action that you want to complete on that resource. The action is indicated by the HTTP method of the request: GET, POST, PUT, or DELETE.

Required Permissions to Access the API

Authentication information must be included in every API request as an HTTP header. Provide the required access credentials in one of the following ways:

  • A user name and password for a JSA user that is specified in the authorization header.

    You specify the user name and password by using HTTP basic authentication. Although you can make API requests by providing a user name and password for every request, use authorized service tokens for all API integrations with JSA. Only the user name and password option is supported for viewing the Documentation Page.

    For more information about creating user roles, security profiles, and users, see the Juniper Secure Analytics Administration Guide.

  • An authorized services token that is specified in the SEC header.

    To authenticate as an authorized service, you create an authentication token that uses authorized services. JSA authorized services have roles and security profiles assigned that control access to the various API resources.

    The token is valid until the expiry date that you specified when you created the authorized service.

    For more information about creating user roles, security profiles and authorized services, see the Juniper Secure Analytics Administration Guide.

The following table highlights the required role and the security profile impacts for each API endpoint:

Table 2: Role Permissions and Security Profile Requirements

API Endpoints

Roles Permissions

Security Profile

/api/analytics/*

Requires Admin permission.

Requires Admin security profile.

/api/ariel/*

Requires Admin permission for querying events or flows.

Requires Admin security profile.

/api/asset_model/*

Requires Vulnerability Management or Assets permissions.

Data returned restricted based on security profile assigned.

/api/auth/*

No permission restrictions.

No security profile restrictions.

/api/config/access/tenant_management

Requires Admin permission.

Requires Admin security profile.

/api/config/domain_management

Requires Admin permission.

Requires Admin security profile.

/api/config/extensions_management

Requires Admin permission.

Requires Admin security profile.

/api/gui_app_framework/*

Requires Admin permission.

Requires Admin security profile.

/api/help/*

No permission restrictions.

No security profile restrictions.

/api/qvm/*

Requires Assets permissions.

Requires a security profile with access to all networks, all log sources, and all domains.

/api/qrm/*

Requires Admin permission.

Requires Admin security profile.

/api/reference_data/*

Requires Admin permissions for POST and DELETE requests. Requires View Reference Data for GET requests.

Requires Admin security profile.

/api/scanner/*

Requires Vulnerability Management permissions.

Requires a security profile with access to all networks, all log sources, and all domains.

/api/services/*

No permission restrictions.

No security profile restrictions.

/api/siem/*

Requires Offenses permissions.

The Manage Offense Closing Reasons permission is required for creating offense closing reasons (POST /api/siem/offense_closing_reasons). The Assign Offenses to Users permission is required for updating the assigned to field of an offense (POST /api/siem/offenses/{offense_id} when the assigned_to parameter is supplied).

Data returned restricted based on security profile assigned.

/api/staged_config/*

Requires Admin permission.

Requires Admin security profile.

/api/system/*

Requires Admin permission.

Requires Admin security profile.

API Requests and Responses

When you send an API request, the server returns an HTTP response. The HTTP response contains a status code to indicate whether the request succeeded and the details of the response in the response body. Most resources format this response as JavaScript Object Notation (JSON). You can use the JSON packages or libraries that are built in to the programming language that you use to extract the data.

Version Headers

You use version headers to request a specific version of the API. If you don't provide a version header, the latest version of the API is used, which might break integrations when JSA is upgraded. If you provide a version header every time you use an API, it makes it easier to upgrade to newer versions of JSA without breaking your API clients.

The APIs use the major and minor components of semantic versioning. Natural numbers are used to designate major versions of the API, for example, '3'. Minor versions of the API are designated with a major and minor component, for example, '3.1'. You can set the version header to a major or a minor version of the API. Changes that are compatible with existing versions are introduced with an incremented minor version number. Any incompatible changes are introduced with a major version number increment.

When a major version of the API is specified in the version header without a minor component, the server responds with the latest minor version within the major API version. For example, if the client requests version '3', the server responds with version '3.1'. If you want to use version 3.0, you must request '3.0' in the version header. If you request a version greater than the latest version of an endpoint, the latest available version of that endpoint is returned. Each endpoint is listed under every version it is valid for, even if it's unchanged in the newer versions.

Endpoint Deprecation

An API endpoint is marked as deprecated to indicate that it is not recommended for use and will be removed in a future release. To give integrations time to use an alternative, a deprecated endpoint continues to function for at least 1 release before it is removed. The interactive API documentation page indicates that an endpoint is marked as deprecated. Also, the API response message for a deprecated endpoint includes the header Deprecated. An individual API endpoint, or an entire version of API endpoints can be marked as deprecated. The deprecated endpoints still continue to function until they are removed.

When an API endpoint completes the deprecation process, it is removed. Endpoints that are removed no longer respond successfully. An attempt to call a removed endpoint returns an error. An HTTP 410 Gone response is returned for individual removed endpoints. An HTTP 422 Unprocessable Entity response is returned for requests for a version that is no longer supported.

Include the version header in API requests to call a specific version of an API endpoint. API integrations that do not explicitly request a particular version are not supported. If you do not specify a version, your request is directed to the latest available version. If a release includes a new, incompatible version of an endpoint, your integration might break. Have your request version in one location in your code to ease upgrading as newer versions become available.