La différence entre les requêtes cURL et WordPress

cURL est une bibliothèque PHP très populaire que j’ai référencée dans plusieurs autres articles (1 et 2, par exemple). Et c’est celui qui, je pense, devrait être revu, exploré et éventuellement utilisé par quiconque travaille en PHP (oui, même ceux qui travaillent sur WordPress).

Mais grâce aux API WordPress natives, nous avons un niveau d’abstraction qui nous permet d’obtenir une grande partie des mêmes fonctionnalités (sinon les mêmes fonctionnalités).

Plus précisément, je parle de wp_safe_remote_get.

Cette fonction est idéale lorsque la requête HTTP est adressée à une URL arbitraire. L’URL est validée pour éviter la redirection et les attaques de contrefaçon de demande.

Je mentionne spécifiquement la variante sûre de cette fonction pour la définition ci-dessus (il existe une autre variante, mais il est important de prendre des précautions contre les URL arbitraires pour des raisons de sécurité).

requêtes cURL et WordPress

Quoi qu’il en soit, à quoi pourrait ressembler une fonction si nous devions utiliser cette bibliothèque cURL ?

<?php

try {
    $curl = curl_init();
    curl_setopt($curl, CURLOPT_CUSTOMREQUEST, 'GET');
    curl_setopt($curl, CURLOPT_URL, $url);
    curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 0);
    curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, 0);
    $response = curl_exec($curl);

    if (is_object($response)) {
        return false;
    }

    if (false === $response) {
        throw new Exception(curl_error($curl), curl_errno($curl));
    }

    curl_close($curl);
} catch (Exception $e) {
    trigger_error(
        sprintf(
            'Curl failed with error #%d: %s',
            $e->getCode(),
            $e->getMessage()
        ),
        E_USER_ERROR
    );
}

En bref (et c’est typique pour la plupart des requêtes cURL) :

• initialiser la librairie cURL,
• définir des options propres à votre demande (qui varieront en fonction de ladite demande),
• faire la demande,
• évaluer la réponse
• attraper toutes les exceptions nécessaires.

Et puis si on utilisait la même déclinaison du code dans WordPress ?

<?php

$response = wp_safe_remote_get($url);
if (is_wp_error($response)) {
    return '';
}
$response = $response['body'];

C’est beaucoup plus petit et sans doute plus facile à lire (au moins pour ceux qui travaillent dans WordPress). En termes d’arguments, je ne transmets rien non plus dans la fonction autre que l’URL.

Si vous lisez la documentation de l’API liée, vous verrez que nous avons un certain contrôle sur cela ; cependant, cela variera en fonction de la manière dont vous devez communiquer avec un point de terminaison donné.

De plus, la façon dont vous gérez WP_Error dépend de vous. Retourner une chaîne vide est rarement la meilleure option ; cependant, pour les besoins de cet exemple, c’est suffisant. Le cas que nous recherchons principalement est le corps de la réponse et c’est l’objet du code.

Quand utilise-t-on l’un ou l’autre ?

Quand il s’agit de travailler avec les requêtes distantes cURL et WordPress et de déterminer quelle méthode utiliser, j’ai tendance à suivre cette règle :

• Si ce dont j’ai besoin peut être réalisé avec une fonction API WordPress, je l’utilise.
• Sinon, j’utiliserai cURL.

Je ne peux pas fournir une règle plus solide.

Au lieu de cela, examinez le point de terminaison avec lequel vous communiquez, déterminez le niveau de contrôle dont vous avez besoin sur la demande et prenez une décision sur la manière dont vous souhaitez gérer la réponse.

À partir de là, vous devriez avoir une bonne idée de la bibliothèque à utiliser.