✅ WEB- och WordPress -nyheter, teman, plugins. Här delar vi tips och bästa webbplatslösningar.

Skillnaden mellan cURL- och WordPress-förfrågningar

43

cURL är ett mycket populärt PHP-bibliotek som jag har refererat till i flera inlägg andra inlägg (1 och 2, till exempel). Och det är en som jag tycker bör granskas, utforskas och möjligen användas av alla som arbetar i PHP (ja, även de som arbetar i WordPress).

Men på grund av de inbyggda WordPress API:erna har vi en abstraktionsnivå som gör att vi kan uppnå mycket av samma funktionalitet (om inte samma funktionalitet).

Närmare bestämt pratar jag om wp_safe_remote_get.

Skillnaden mellan cURL- och WordPress-förfrågningar

Denna funktion är idealisk när HTTP-begäran görs till en godtycklig URL. Webbadressen är validerad för att undvika omdirigering och begäran om förfalskningsattacker.

Jag nämner specifikt den säkra varianten av denna funktion för definitionen ovan (det finns en annan variant, men det är viktigt att vidta försiktighetsåtgärder mot godtyckliga webbadresser av säkerhetsskäl).

cURL och WordPress-förfrågningar

Hur som helst, så hur skulle en funktion kunna se ut om vi skulle använda detta cURL-bibliotek?

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

Kort sagt (och detta är typiskt för de flesta cURL-förfrågningar):

  • initiera cURL-biblioteket,
  • ställ in alternativ som är specifika för din begäran (som kommer att variera beroende på nämnda begäran),
  • göra begäran,
  • utvärdera svaret
  • fånga eventuella nödvändiga undantag.

Och sedan om vi skulle använda samma variant av koden i WordPress?

<?php

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

Detta är mycket mindre och utan tvekan lättare att läsa (åtminstone för de som arbetar i WordPress). När det gäller argument så lägger jag inte heller in något annat i funktionen än URL:en.

Om du läser den länkade API-dokumentationen kommer du att se att vi har viss kontroll över det; det kommer dock att variera beroende på hur du behöver kommunicera med en given slutpunkt.

Hur du hanterar WP_Error är upp till dig. Att returnera en tom sträng är sällan det bästa alternativet; men för detta exempel är det tillräckligt. Fallet vi främst är ute efter är själva svaret och det är kodens fokus.

När använder vi det ena eller det andra?

När det gäller att arbeta med cURL och WordPress fjärrförfrågningar och bestämma vilken metod jag ska använda tenderar jag att följa denna regel:

  • Om det jag behöver kan uppnås med en WordPress API-funktion använder jag den.
  • Om inte, använder jag cURL.

Jag kan inte ge en mer solid regel.

Titta istället på den slutpunkt som du kommunicerar, bestäm vilken nivå av kontroll du behöver över förfrågan och fatta ett beslut om hur du vill hantera svaret.

Därifrån bör du ha en bra idé om vilket bibliotek du ska använda.

Inspelningskälla: tommcfarlin.com

Denna webbplats använder cookies för att förbättra din upplevelse. Vi antar att du är ok med detta, men du kan välja bort det om du vill. Jag accepterar Fler detaljer