Client application should implement the following stages of data exchange:
Converting a requested command to an XML API packet.
Preparing the packet for delivery via HTTP and sending to Plesk.
Receiving response from Plesk and extracting the resulting information from the packet.
The figure above demonstrates how a client application can be structured and how this structure serves the data turnaround. Each module of this sample application is responsible for a particular task, that is:
- XML packet builder accepts a command from the application GUI or a third-party module. XML packet builder contains a command-to-XML converter for each known command. Format of the resulting XML packet is fully compliant with the XML API version supported by the client application.
- HTTP packet sender accepts the XML packet. The packet does not contain any information about the target server and access details, so HTTP packet sender should store these settings or should be able to get them on demand. HTTP packet sender forms an HTTP header with Plesk user credentials and send the packet to the XML API server.
- HTTP packet receiver gets the result HTTP packet from the server side, removes the HTTP header and moves the pure XML response to XML packet parser.
- XML packet parser analyses the response packet for the execution status and forms a matching error message if the result is negative. Then it sends the extracted and handled data back to the GUI or calling module.
The figure above shows HTTP operations as a part of HTTP library. Actually, these operations can be implemented from scratch, but the easier approach is using some ready-made and tested HTTP library. The division into HTTP sender and HTTP receiver is conditional: This was done with the only purpose to separate send and receive HTTP operations graphically.
Later on, we consider each step in detail, though not coming into the peculiarities of requests for each supported operation. The detailed information about supported operations follows in the Reference chapter.