---

title: Restful Api sidebar_position: 2

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

{
 "method":"/api/rest_j/v1/entrance/execute",
 "params": {
    "variable":{
    "k1":"v1"
    },
    "configuration":{
    "special":{
    "k2":"v2"
    },
    "runtime":{
    "k3":"v3"
    },
    "startup":{
    "k4":"v4"
    }
    }
    },
    "executeApplicationName":"spark",
    "executionCode":"show tables",
    "runType":"sql",
    "source":{
    "scriptPath": "/home/Linkis/Linkis.sql"
    }
}

• The parameters in the request body data are described as follows

Parameter name	Parameter definition	Type	Remarks
executeApplicationName	The engine service that the user expects to use, such as Spark, hive, etc.	String	cannot be empty
requestApplicationName	The name of the system that initiated the request	String	Can be empty
params	User-specified parameters for running the service program	Map	Required, the value inside can be empty
executionCode	Execution code submitted by the user	String	cannot be empty
runType	When users execute services such as spark, they can choose python, R, SQL, etc. runType	String	Cannot be empty
scriptPath	The storage path of the script submitted by the user	String	If it is an IDE, and executionCode cannot be empty at the same time

• Return to example

{
 "method": "/api/rest_j/v1/entrance/execute",
 "status": 0,
 "message": "Request executed successfully",
 "data": {
   "execID": "030418IDEhivebdpdwc010004:10087IDE_johnnwang_21",
   "taskID": "123"
 }
}

• 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

{
 "method": "/api/rest_j/v1/entrance/{execID}/status",
 "status": 0,
 "message": "Get status successful",
 "data": {
   "execID": "${execID}",
   "status": "Running"
 }
}

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

{
  "method": "/api/rest_j/v1/entrance/${execID}/log",
  "status": 0,
  "message": "Return log information",
  "data": {
    "execID": "${execID}",
    "log": ["error log","warn log","info log", "all log"],
    "fromLine": 56
   }
}

3.4 Get progress

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

• Submission method GET
  

• Return to example

{
  "method": "/api/rest_j/v1/entrance/{execID}/progress",
  "status": 0,
  "message": "Return progress information",
  "data": {
    "execID": "${execID}",
    "progress": 0.2,
    "progressInfo": [
        {
        "id": "job-1",
        "succeedTasks": 2,
        "failedTasks": 0,
        "runningTasks": 5,
        "totalTasks": 10
        },
        {
        "id": "job-2",
        "succeedTasks": 5,
        "failedTasks": 0,
        "runningTasks": 5,
        "totalTasks": 10
        }
    ]
  }
}

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

{
 "method": "/api/rest_j/v1/entrance/{execID}/kill",
 "status": 0,
 "message": "OK",
 "data": {
   "execID":"${execID}"
  }
}

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