Sitebuilder API is a programming interface to various functions of Sitebuilder. Using this API, you can administrate Sitebuilder without visual web interface (Administrator Panel), integrate Sitebuilder with other third-party control panels or applications.
Access to Sitebuilder API is provided through the set of XML Web services. You can easily use Sitebuilder API from various operating systems or platforms by using HTTP and XML. Available SOAP toolkits let you use Java, .NET, PHP or virtually any other programming languages or development environments.
Sitebuilder 4.2 for Windows implements several versions of public Sitebuilder API. They are API v3.2 and API v3.2.1 (the legacy APIs available in Sitebuilder 3.2.x for Windows),
API v4.0 (Single Sign-On (SSO) support, account profile management, simplified site publishing settings management, updated license
management) and API v4.1 (new SSO version support, the plan management enhancements and so on).
Sitebuilder 4.2 for Linux/Unix implements only API v3.2, API v4.0 and API v4.1
Also there are differences between Windows and Linux/Unix implementations of Sitebuilder API in some platform specific areas: SOAP fault details, the site publishing settings etc. The developers should pay attention to these differences, when creating the applications interacting through API with Sitebuilders on both platforms.
Sitebuilder provides a high degree of support for backward compatibility. The applications created using Sitebuilder API v3.2.x will run on Sitebuilder 4.x (on same platform). However, some changes in the behavior of these applications may be observed. For example, Sitebuilder 4.x doesn't support the publish scenario "Known FTP host" anymore. The functionality of the older versions of the Sitebuilder API depends on this feature are emulating by "behind the scenes" creation of the required host objects. As a result, the value of the site publishing settings may not meet the expectations of the applications based on the Sitebuilder 3.2.x
|API version||Reference manual||Base location of the web services end points|
|Sitebuilder for Windows||Sitebuilder for Linux/Unix|
|3.2||Sitebuilder API v3.2 Reference||/ServiceFacade/Version_3_2/||/ServiceFacade/|
|3.2.1||Sitebuilder API v3.2.1 Reference||/ServiceFacade/3.2.1/||not supported|
|4.0||Sitebuilder API v4.0 Reference||/ServiceFacade/4.0/||/ServiceFacade/4.0/|
|4.1||Sitebuilder API v4.1 Reference||/ServiceFacade/4.1/||/ServiceFacade/4.1/|
|4.5||Sitebuilder API v4.5 Reference||/ServiceFacade/4.5/||/ServiceFacade/4.5/|
This section is targeted to explain the Plesk Sitebuilder domain model, namely, to show which managed objects exist in Sitebuilder and how they are related to each other.
Plesk Sitebuilder domain model objects are as follows:
To understand the users and plans hierarchy, refer to the Figure 3.
The diagrams designed to illustrate the most important objects relationships in Plesk Sitebuilder use the following graphical conventions:
This diagram represents the hierarchical structure of users and plans in Sitebuilder.
Admin is a User automatically assigned to a General Plan - a License. Limited by the License, Admin creates his Sites and Plans, and assigns to these Plans another Users - Resellers and Site Owners. Both Resellers and Site Owners create their Sites according to the Plan to which each is assigned. Along with creating Sites, Reseller can also create his own Plans and Users, and assign these Users to his Plans. The Users that the Reseller creates are, again, Resellers and Site Owners who, again, create either their Sites and Plans (in case of a Reseller User), or their Sites only (in case of a Site Owner User). And the situation is repeated again and again, which results in creating multi-level hierarchy of Sitebuilder Plans and Users.
Plans are organized in such a hierarchy where, if moving top-down, the amount of Plan Resources is decreasing and increasing at the same time. The point is that Resellers do not create Plans by simply redistributing the parent Plan resources among them, some Resources (exactly, Hosts, Site Families, and Page Sets) can freely be created and used in addition to the inherited ones. This diagram illustrates how it happens:
When creating a Plan, Admin operates with the pool of Resources composed of the Resources provided (or restricted) by the License (Parent Plan Resources on the diagram) and the Resources that he created himself (Own Resources). A Reseller assigned to this Plan, in turn, can create Plans from the Parent Plan Resources adding to them his Own Resources. And so on.
The following diagram explains how a Reseller creates a Plan adding his Own Resources to the ones inherited from his Parent Plan, and how a Site created upon this Plan utilizes the resources:
Here, a Reseller (in fact, Admin is a Reseller, too, but of the highest level in the system) takes Design Templates, Hosts, Site Families, Page Sets and Modules provided by the Plan he is assigned to (Parent Plan Resources), adds to them Hosts, Site Families and Page Sets he created or somehow obtained (Admin/Reseller Resources), and creates his Own Plan from them. Then, a User assigned to this Plan can create a Site which will utilize all those resources the Reseller included to his Plan.