PHP Server – access points
Pydio is based on the PHP scripting language for the server-side, the main entry point being the /index.php of the root of the installation. Queries parameters are sent via HTTP GET or HTTP POST to the script, and responses can be sent back with various content types, depending on the action. The most common format is currently XML (always encoded in UTF-8) but JSON can be used for some specific actions (particularly in the Settings panel actions), and the downloads trigger “force-download” headers and binary data.
The standard API usage would be calling index.php with at least a get_action parameter. This parameter can be seen as the target service the query is adressing. Additional parameters would then depend on this get_action value. This “actions” are in fact declared by all plugins, through XML files. See the Plugins Architecture paragraph for more details. Below, you can see a trace of the queries sent by the client to the server. The secure_token is a unique token attached to this instance of the GUI, for CSRF protection.
REST API v1
Actions can be triggered by the REST API: either using the API V1, that is listening on yourserver.com/pydio/api/ URL. If a “restParams” attribute is declared in the server callbacks in the XML files, and action is available through a REST call via /api/repository_alias/action_name/restParameters. Additional POST/GET parameters can be appended to the request as well.
REST API v2
Starting with Pydio 7, we introduced a new REST API that was designed from ground up to closely follow REST standards. The API v2 URLs are more specific and are mapped under the hood to specific pydio actions. Please see the References > REST API V2 for more information.
PHP Command line
Finally, all these actions can also be triggered from the command line, using PHP CLI and loading the /cmd.php file. Actions are in that case passed through the -a parameter, along with a repository id, users credential, and additional action parameters. The output is currently exactly the same as it would though an Http call.
Transpilation & Browserification
Another aspect is the ability to use all the existing open source libraries available on NPM registry. This was originally designed for NodeJS programs, that can handle dynamically the load of these dependencies (using import 'libname' instructions). When it comes to browser application, an additional step is required to statically link to all dependencies and make sure they will be loaded inside the browser at runtime. This is done using Browserify.
See next chapter "Setup Hacking".Back to top