Der Unterschied zwischen cURL- und WordPress-Anfragen

cURL ist eine sehr beliebte PHP-Bibliothek, auf die ich in mehreren Beiträgen und anderen Beiträgen verwiesen habe (z. B. 1 und 2 ). Und es ist eines, von dem ich denke, dass es von jedem überprüft, erforscht und möglicherweise von jedem verwendet werden sollte, der mit PHP arbeitet (ja, sogar von denen, die mit WordPress arbeiten).

Aber aufgrund der nativen WordPress-APIs haben wir eine Abstraktionsebene, die es uns ermöglicht, einen Großteil der gleichen Funktionalität (wenn nicht sogar die gleiche Funktionalität) zu erreichen.

Konkret spreche ich von wp_safe_remote_get.

Diese Funktion ist ideal, wenn die HTTP-Anforderung an eine beliebige URL gesendet wird. Die URL wird validiert, um Umleitungs- und Anforderungsfälschungsangriffe zu vermeiden.

Ich erwähne speziell die sichere Variante dieser Funktion für die obige Definition (es gibt eine andere Variante, aber es ist wichtig, aus Sicherheitsgründen Vorkehrungen gegen willkürliche URLs zu treffen).

cURL- und WordPress-Anfragen

Wie könnte eine Funktion aussehen, wenn wir diese cURL-Bibliothek verwenden würden?

<?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
    );
}

Kurz gesagt (und das ist typisch für die meisten cURL-Anfragen):

• cURL-Bibliothek initialisieren,
• spezifische Optionen für Ihre Anfrage festlegen (die je nach Anfrage variieren),
• den Antrag stellen,
• die Antwort auswerten
• alle notwendigen Ausnahmen abfangen.

Und wenn wir dann dieselbe Variante des Codes in WordPress verwenden würden?

<?php

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

Dies ist viel kleiner und wohl einfacher zu lesen (zumindest für diejenigen, die in WordPress arbeiten). In Bezug auf Argumente übergebe ich außer der URL auch nichts an die Funktion.

Wenn Sie die verlinkte API-Dokumentation lesen, werden Sie sehen, dass wir eine gewisse Kontrolle darüber haben; Sie hängt jedoch davon ab, wie Sie mit einem bestimmten Endpunkt kommunizieren müssen.

Außerdem liegt es an Ihnen, wie Sie mit dem WP_Error umgehen. Die Rückgabe eines leeren Strings ist selten die beste Option; Für die Zwecke dieses Beispiels ist dies jedoch ausreichend. Der Fall, nach dem wir in erster Linie suchen, ist der Hauptteil der Antwort, und darauf konzentriert sich der Code.

Wann verwenden wir das eine oder das andere?

Wenn es darum geht, mit cURL- und WordPress-Remote-Anfragen zu arbeiten und zu bestimmen, welche Methode verwendet werden soll, neige ich dazu, diese Regel zu befolgen:

• Wenn das, was ich brauche, mit einer WordPress-API-Funktion erreicht werden kann, verwende ich sie.
• Wenn nicht, verwende ich cURL.

Ich kann keine solidere Regel aufstellen.

Schauen Sie sich stattdessen den Endpunkt an, den Sie kommunizieren, bestimmen Sie, wie viel Kontrolle Sie über die Anfrage benötigen, und treffen Sie eine Entscheidung, wie Sie mit der Antwort umgehen möchten.

Von dort aus sollten Sie eine gute Vorstellung davon haben, welche Bibliothek Sie verwenden sollen.