The response format is JSON. Examples are found in the use-cases.
Also see the deploy guide.
Note:
To build a multi-application system, use one or three config server(s) per application.
Best practise is using a containerized architecture,
also see multinode-HA.
The current API version is 2. The API port is 19071 - use
vespa-model-inspect service configserver
to find config server hosts. Example:
http://myconfigserver.mydomain.com:19071/application/v2/tenant/default/session.
Write operations return successfully after a majority of config servers have persisted
changes (e.g. 2 out of 3 config servers).
Entities:
session-id
The session-id used in this API is generated by the server and is required
for all operations after creating a session.
The session-id is valid if it is an active session or it was created before
session lifetime
has expired, the default value being 1 hour.
path
An application file path in a request URL or parameter refers to a
relative path in the application package.
A path ending with "/" refers to a directory.
Note:
Use convergence
to confirm configuration activation on all nodes.
POST /application/v2/tenant/default/prepareandactivate
Creates a new session with the application package that is included in the request,
prepares it and then activates it.
See details in the steps later in this document
Examples (both requests return the same response):
POST /application/v2/tenant/default/session
POST /application/v2/tenant/default/session?from=http://myconfigserver.mydomain.com:19071/application/v2/tenant/default/application/default/environment/default/region/default/instance/default
Any errors or warnings from deleting the resource.
PUT /application/v2/tenant/default/session/[session-id]/prepared
Prepares an application with the session-id given.
Parameters
Parameter
Default
Description
applicationName
N/A
Name of the application to be deployed
environment
default
Environment where application should be deployed
region
default
Region where application should be deployed
instance
default
Name of application instance
debug
false
If true, include stack trace in response if prepare fails.
timeout
360 seconds
Timeout in seconds to wait for session to be prepared.
Request body
None
Response
Returns a session-id and a link to activate the session.
Log with any errors or warnings from preparing the application.
An activate URL for activating
the application with this session-id, if there were no errors.
A list of actions (possibly empty) that must be performed in order to apply some config changes
between the current active application and this next prepared application.
These actions are organized into three categories; restart, reindex, and refeed:
Restart actions are done after the application has been activated
and are handled by restarting all listed services.
See
schemas for details.
Reindex actions are special refeed actions that Vespa
handles automatically, if the
reindex endpoint below is used.
Refeed actions require several steps to handle.
See schemas for details.
Example:
PUT /application/v2/tenant/default/session/3/prepared
GET /application/v2/tenant/default/session/[session-id]/prepared
Returns the state of a prepared session.
The response is the same as a successful prepare operation (above),
however the configChangeActions element will be empty.
PUT /application/v2/tenant/default/session/[session-id]/active
Activates an application with the session-id given.
The session-id must be for a prepared session.
The operation will make sure the session is activated on all config servers.
Parameters
Parameter
Default
Description
timeout
60 seconds
Timeout in seconds to wait for session to be activated (when
several config servers are used, they might need to sync
before activate can be done).
Request body
None
Response
Returns a session-id, a message and a URL to the activated application.
PUT /application/v2/tenant/default/session/3/active
GET /application/v2/tenant/default/application/
Returns a list of the currently active applications for the given tenant.
Parameters
None
Request body
None
Response
Returns a list of applications
Array of active applications
Example:
GET /application/v2/tenant/default/application/
GET /application/v2/tenant/default/application/default
Gets info about the application.
Parameters
None
Request body
None
Response
Returns information about the application specified.
config generation
Example:
GET /application/v2/tenant/default/application/default
GET /application/v2/tenant/default/application/default/environment/default/region/default/instance/default/reindexing
Returns reindexing status for the given application.
Parameters
N/A
Request body
N/A
Response
JSON detailing current reindexing status for the application, with all its clusters and document types.
Status for each content cluster in the application, by name:
Status of each document type in the cluster, by name:
Last time reindexing was triggered for this document type.
Current status of reindexing.
Optional start time of reindexing.
Optional end time of reindexing.
Optional progress of reindexing, from 0 to 1.
Pseudo-speed of reindexing.
Example:
GET /application/v2/tenant/default/application/default/environment/default/region/default/instance/default/reindexing
POST /application/v2/tenant/default/application/default/environment/default/region/default/instance/default/reindex
Triggers reindexing of specified document types in
specified clusters of an application.
Reindexing starts with the next redeployment of the application.
To stop an ongoing reindexing, see updating reindexing below.
All document types in all clusters are reindexed unless restricted, using parameters as specified:
Parameters
Name
Description
clusterId
A comma-separated list of content clusters to limit reindexing to.
All clusters are reindexed if this is not present.
documentType
A comma-separated list of document types to limit reindexing to.
All document types are reindexed if this is not present.
indexedOnly
Boolean: whether to trigger reindexing only for document types with indexing
mode index and at least one field with the indexing statement
index. Default is false.
speed
Number (0–10], default 1: Indexing pseudo speed -
balance speed vs. resource use. Example: speed=0.1
Request body
N/A
Response
A human-readable message indicating what reindexing was triggered.
Example:
POST /application/v2/tenant/default/application/default/environment/default/region/default/instance/default/reindex?clusterId=foo,bar&documentType=moo,baz&indexedOnly=true
PUT /application/v2/tenant/default/application/default/environment/default/region/default/instance/default/reindex
Modifies reindexing of specified document types in
specified clusters of an application.
Specifically, this can be used to alter the pseudo-speed of the reindexing, optionally halting it by specifying
a speed of 0; reindexing for the specified types will remain dormant until either speed is increased again,
or a new reindexing is triggered (see trigger reindexing).
Speed changes become effective with the next redeployment of the application.
Reindexing for all document types in all clusters are affected if no other parameters are specified:
Parameters
Name
Description
clusterId
A comma-separated list of content clusters to limit the changes to.
Reindexing for all clusters are modified if this is not present.
documentType
A comma-separated list of document types to limit the changes to.
Reindexing for all document types are modified if this is not present.
indexedOnly
Boolean: whether to modify reindexing only for document types with indexing
mode index and at least one field with the indexing statement
index. Default is false.
speed
Number [0–10], required: Indexing pseudo speed -
balance speed vs. resource use. Example: speed=0.1
Request body
N/A
Response
A human-readable message indicating what reindexing was modified.
Example:
PUT /application/v2/tenant/default/application/default/environment/default/region/default/instance/default/reindex?clusterId=foo,bar&documentType=moo,baz&speed=0.618
GET /application/v2/tenant/default/application/default/environment/default/region/default/instance/default/content/[path]
Returns content at the given path for an application.
See getting content for usage and response.
Gets information about which tenant and application a hostname is used by.
Parameters
None
Request body
None
Response
Returns a message with tenant and application details.
Example:
GET /application/v2/host/myhost.mydomain.com
Error Handling
Errors are returned using standard HTTP status codes.
Any additional info is included in the body of the return call, JSON-formatted.
The general format for an error response is:
HTTP status code
Error code
Description
400
BAD_REQUEST
Bad request. Client error. The error message should indicate the cause.
400
INVALID_APPLICATION_PACKAGE
There is an error in the application package. The error message should indicate the cause.
400
OUT_OF_CAPACITY
Not enough nodes available for the request to be fulfilled.
401
Not authorized. The error message should indicate the cause.
404
NOT_FOUND
Not found. E.g. when using a session-id that doesn't exist.
405
METHOD_NOT_ALLOWED
Method not implemented. E.g. using GET where only POST or PUT is allowed.
409
ACTIVATION_CONFLICT
Conflict, returned when activating an application fails due
to a conflict with other changes to the same application (in
another session). Client should retry.
500
INTERNAL_SERVER_ERROR
Internal server error. Generic error. The error message should indicate the cause.
Access log
Requests are logged in the access log which can be found at
$VESPA_HOME/logs/vespa/configserver/access-json.log, example:
Use Cases
It is assumed that the tenant default is already created in these use cases,
and the application package is in app.
Prepare the application with the URL in the prepared link from the response:
$ curl -s -X PUT "http://host:19071/application/v2/tenant/default/session/1/prepared?applicationName=default"
Activate the application with the URL in the activate link from the response:
$ curl -s -X PUT "http://host:19071/application/v2/tenant/default/session/1/active"
Modify the application package
Dump services.xml from session 1:
$ curl -s -X GET "http://host:19071/application/v2/tenant/default/session/1/content/services.xml"
Session 1 is activated and cannot be changed - create a new session based on the active session:
$ curl -s -X POST "http://host:19071/application/v2/tenant/default/session?from=http://host:19071/application/v2/tenant/default/application/default/environment/default/region/default/instance/default"
Modify rpcport to 12346 in services.xml, deploy the change:
$ curl -s -X PUT --data-binary @app/services.xml \
"http://host:19071/application/v2/tenant/default/session/2/content/services.xml"
Get services.xml from session 2 to validate:
$ curl -s -X GET "http://host:19071/application/v2/tenant/default/session/2/content/services.xml"
To add the file files/test1.txt, first create the directory, then add the file:
$ curl -s -X PUT "http://host:19071/application/v2/tenant/default/session/2/content/files/"
$ curl -s -X PUT --data-binary @app/files/test1.txt \
"http://host:19071/application/v2/tenant/default/session/2/content/files/test1.txt"
Prepare and activate the session:
$ curl -s -X PUT "http://host:19071/application/v2/tenant/default/session/2/prepared?applicationName=fooapp"
$ curl -s -X PUT "http://host:19071/application/v2/tenant/default/session/2/active"
Rollback
If you need to roll back to a previous version of the application package
this can be achieved by creating a new session based on the previous known
working version by passing the corresponding session-id in the
from argument, see creating a session