Restful Api

Linkis provides a convenient HTTP interface to facilitate the front-end upper application or the back-end to call through the Restful interface

1 Linkis interface specification

Linkis defines its own set of interface specifications when interacting between the front and back ends.

If you are interested in the interface specification, please click here view interface specification

2 HTTP interface summary

We provide the following interfaces to facilitate users to quickly submit execution jobs and obtain execution results.

  • Submit for execution
  • Get status
  • Get logs
  • Get progress
  • Kill mission

3 Interface details

3.1 Submit for execution

  • Interface /api/rest_j/v1/entrance/execute

  • Submission method POST

  1. {
  2.  "method":"/api/rest_j/v1/entrance/execute",
  3.  "params": {
  4.     "variable":{
  5.     "k1":"v1"
  6.     },
  7.     "configuration":{
  8.     "special":{
  9.     "k2":"v2"
  10.     },
  11.     "runtime":{
  12.     "k3":"v3"
  13.     },
  14.     "startup":{
  15.     "k4":"v4"
  16.     }
  17.     }
  18.     },
  19.     "executeApplicationName":"spark",
  20.     "executionCode":"show tables",
  21.     "runType":"sql",
  22.     "source":{
  23.     "scriptPath": "/home/Linkis/Linkis.sql"
  24.     }
  25. }
  • The parameters in the request body data are described as follows
Parameter nameParameter definitionTypeRemarks
executeApplicationNameThe engine service that the user expects to use, such as Spark, hive, etc.Stringcannot be empty
requestApplicationNameThe name of the system that initiated the requestStringCan be empty
paramsUser-specified parameters for running the service programMapRequired, the value inside can be empty
executionCodeExecution code submitted by the userStringcannot be empty
runTypeWhen users execute services such as spark, they can choose python, R, SQL, etc. runTypeStringCannot be empty
scriptPathThe storage path of the script submitted by the userStringIf it is an IDE, and executionCode cannot be empty at the same time
  • Return to example
  1. {
  2.  "method": "/api/rest_j/v1/entrance/execute",
  3.  "status": 0,
  4.  "message": "Request executed successfully",
  5.  "data": {
  6.    "execID": "030418IDEhivebdpdwc010004:10087IDE_johnnwang_21",
  7.    "taskID": "123"
  8.  }
  9. }
  • execID is the uniquely identified execution ID generated for the task after the user task is submitted to UJES. It is of String type. This ID is only useful when the task is running, similar to the concept of PID. ExecID is designed as (requestApplicationName length) (executeAppName length 1) (Instance length 2)${requestApplicationName}${executeApplicationName}${entranceInstance information ip+port}${requestApplicationName}${umUser}${index}
  • taskID is the unique ID of the task submitted by the user. This ID is generated by the database self-increment and is of Long type

3.2 Get status

  • Interface /api/rest_j/v1/entrance/${execID}/status

  • Submission method GET

  • Return to example

  1. {
  2.  "method": "/api/rest_j/v1/entrance/{execID}/status",
  3.  "status": 0,
  4.  "message": "Get status successful",
  5.  "data": {
  6.    "execID": "${execID}",
  7.    "status": "Running"
  8.  }
  9. }

3.3 Obtaining logs

  • Interface /api/rest_j/v1/entrance/${execID}/log?fromLine=${fromLine}&size=${size}

  • Submission method GET

  • The request parameter fromLine refers to the number of lines from which to get, and size refers to the number of lines of logs that this request gets

  • Return example, where the returned fromLine needs the parameters of the next log request

  1. {
  2.   "method": "/api/rest_j/v1/entrance/${execID}/log",
  3.   "status": 0,
  4.   "message": "Return log information",
  5.   "data": {
  6.     "execID": "${execID}",
  7.     "log": ["error log","warn log","info log", "all log"],
  8.     "fromLine": 56
  9.    }
  10. }

3.4 Get progress

  • Interface /api/rest_j/v1/entrance/${execID}/progress

  • Submission method GET

  • Return to example

  1. {
  2.   "method": "/api/rest_j/v1/entrance/{execID}/progress",
  3.   "status": 0,
  4.   "message": "Return progress information",
  5.   "data": {
  6.     "execID": "${execID}",
  7.     "progress": 0.2,
  8.     "progressInfo": [
  9.         {
  10.         "id": "job-1",
  11.         "succeedTasks": 2,
  12.         "failedTasks": 0,
  13.         "runningTasks": 5,
  14.         "totalTasks": 10
  15.         },
  16.         {
  17.         "id": "job-2",
  18.         "succeedTasks": 5,
  19.         "failedTasks": 0,
  20.         "runningTasks": 5,
  21.         "totalTasks": 10
  22.         }
  23.     ]
  24.   }
  25. }

3.5 kill task

  • Interface /api/rest_j/v1/entrance/${execID}/kill

  • Submission method GET

  • Return example, where the returned fromLine needs the parameters of the next log request

  1. {
  2.  "method": "/api/rest_j/v1/entrance/{execID}/kill",
  3.  "status": 0,
  4.  "message": "OK",
  5.  "data": {
  6.    "execID":"${execID}"
  7.   }
  8. }

3.6 System User Agent Settings

  • Gateway proxy settings

    Modify the proxy.properties file in the gateway installation directory conf and add content: token=user1,user2

    Note: The token is the secret key given to the system user, and the right is the other users that the system user can act as proxy. For example, token=*, the user is not restricted.

  • http request proxy settings

    Add two parameter settings to the Headers parameter of the request

    ``` Proxy-User = proxy user xxx Validation-Code = system token configured by the gateway

  1. ```