Interacting with APIs

There are different options to transfer data between your shop and any external service. The method you choose will depend on the usecase:

  • if data must be pulled or pushed to the shop,
  • if one specific application (the shop or an external service) must initiate the calls,
  • if there are constraints on the implementation (i.e a cron job scheduler is required).

Requests to a shop

You may retrieve and update data from a shop using different methods:

The native webservice

The webservice is a REST API allowing you to interact with most of the database tables used by the core. It uses Basic access authentication to allow requests.

Resources:

Adding a module ObjectModel to the list of resources available

The hook addWebserviceResources must be registered by your module.

Then an array containing all the ressources (= Object Model subclasses) you want to add should be returned. For instance, in the module blockreassurance we have an ObjectModel class, called reassuranceClass. If we wanted to make it available in the webservice, it would look like this:

<?php
/**
 * Add an entity in the Webservice
 *
 * @param array $params All existing resources from the core
 * @return array New resources
 */
public function hookAddWebserviceResources($params)
{
    return array(
        'reassurance' => array(
            'description' => 'Module Reassurance example',
            'class' => 'reassuranceClass',
            'forbidden_method' => array('PUT', 'POST', 'DELETE')),
    );
}

This will add the resource reassurance available into the permissions list, based on the key.

Module controllers

As the webservice is only an interface to get and update objects on the database, it does not allow to run complex actions. Module controller may be implemented to allow any external service to reach your shop, then trigger specific actions or retrieve content.

You should implement a method that filters non-authenticated calls. This prevents guests accessing private content, or trigger actions on your behalf. This can be done by generating your own token and checking it everytime the controller is called. Tools::encrypt($token) may be useful.

Resources:

Requests from a shop

HTTP requests can be triggered from a shop to an external service.

Several methods allows requests to be sent (in order of preference):

  • Guzzle. The version 5 is included from PrestaShop 1.7.0 , but can be included in your module as well for older PS versions.
  • \Tools::file_get_contents(…)
    • Will rely on cURL or fopen(), depending on what is available on the shop.
    • Exists from PrestaShop 1.4
  • cURL
    • cURL is mandatory for PrestaShop 1.7 . For older versions, the extension must be checked first to avoid fatal errors.