If the execution is successful, the result will be demonstrated at the bottom of the screen. Then printed nicely with a syntax highlighting.

Provisioning Scenarios Using Remote API

After the first steps you can be ready to write some automated scenarios using remote API. There could be a lot of various provisioning scenarios. Let’s analyze one of them.

For example, you sell virtual servers with Plesk pre-installed. We assume Plesk is already installed on the server or there’s a ready-to-use image for that. You want to perform post-installation steps if your customer orders a VPS. Here’s what such post-installation steps may look like.

• perform Plesk initialization (to provide customer specific information)
• install a license key
• create a first domain

First, to perform Plesk initialization, you need to make POST request to /server/init end-point. We’ll use “curl” and create a temporary file with payload for convenience. Let’s name it plesk-init.json and put the following content in it:

{
"admin": {
"name": "John Smith",
"email": "john-smith@example.com"
  },
"password": "setup",
"server_name": "example.com"
}

Then, perform an API call. If “admin” credentials aren’t set, you can use “root” system user credentials instead (or “administrator” in case of Windows):

curl -k -u root:****** -X POST -d @plesk-init.json "https://<plesk-host>:8443/api/v2/server/init"

The response will be the following:

{
"status": "success"
}

The next step is to install the license key. The end-point /server/license will help you to achieve this:

curl -k -u admin:****** -X POST -d '{ "code": "AX2P00-****" }' "https://<plesk-host>:8443/api/v2/server/license"

The successful result is reported with 200 OK HTTP code and the following content:

{
"status": "success"
}

The last step in our scenario is to create a webspace (domain with hosting). You can create the plesk-domain.json file to store payload temporary and avoid typing it in the command line. Here’s the possible content of the plesk-domain.json file:

{
"name": "example.com",
"hosting_type": "virtual",
"hosting_settings": {
"ftp_login": "ftplogin",
"ftp_password": "ftppassword"
},
"ipv4": ["212.XXX.XXX.XXX"],
"plan": {
"name": "Unlimited"
}
}

And this is the API request:

curl -k -u admin:****** -X POST -d @plesk-domain.json "https://<plesk-host>:8443/api/v2/domains"

The successful response can also look like the following:

{
"id": 1,
"guid": "222c4c4f-168a-4d2f-a867-687123ef8294"
}

You can store GUID in an external system if you need to make an external reference to Plesk business object. Our mission’s accomplished and you are ready to provide the virtual server with Plesk to your end-customer.

One More Thing…

OK, everything’s ready, minus one last step. You may want to send a one-time login link to your customer (buyer of a virtual server with Plesk), and you do it like this:

curl -k -u admin:****** -X POST -d '{ "params": [ "--get-login-link" ] }' "https://<plesk-host>:8443/api/v2/cli/admin/call"

You’ll get the following output:

{
"code": 0,
"stdout": "https:\/\/example.com:8443\/login?secret=lxkmiMfdJzLOBQ6s...",
"stderr": ""
}

The “stdout” property will contain the links – usually two links per one-time login attempt, which you can send to an end customer.

REST API or XML-RPC API?

As you can see, the current version of REST API doesn’t cover as many functions as XML-RPC API. On the other hand, real integrations use a very limited subset of XML-RPC API operations. Because we want to keep REST API simple and useful.

So, the approach of re-implementing every method in REST API doesn’t sound like a good idea to us. The most popular scenarios are already covered by REST API methods. In the end, we’ll continue to increase the functional coverage, but keep API small and simple at the same time.

You can initialize your Plesk remotely, fetch meta information about server (or you /server end-point as a “ping” request). You can manage clients and domains, or even execute the CLI utility over the REST API interface. But ultimately, you can do it all in a much more convenient way compared to XML-RPC API.