Ero cURL- ja WordPress-pyyntöissä

Viimeisin päivitys joulu 28, 2022

Sisältö

cURL on erittäin suosittu PHP-kirjasto, johon olen viitannut useissa viesteissä (esimerkiksi 1 ja 2 ). Ja se on mielestäni sellainen, jota kaikkien PHP:ssä työskentelevien (kyllä, jopa WordPressissä työskentelevien) pitäisi tarkistaa, tutkia ja mahdollisesti käyttää.

Mutta WordPressin natiivisovellusliittymien ansiosta meillä on abstraktiotaso, jonka avulla voimme saavuttaa suurelta osin samat toiminnot (ellei samoja toimintoja).

Tarkemmin sanottuna puhun wp_safe_remote_get -sovelluksesta.

Tämä toiminto on ihanteellinen, kun HTTP-pyyntö tehdään mielivaltaiseen URL-osoitteeseen. URL-osoite tarkistetaan uudelleenohjauksen välttämiseksi ja väärennöshyökkäysten pyytämiseksi.

Mainitsen erityisesti tämän toiminnon turvallisen muunnelman yllä olevaa määritelmää varten (on toinen muunnelma, mutta on tärkeää ryhtyä varotoimiin mielivaltaisia URL-osoitteita vastaan turvallisuussyistä).

cURL- ja WordPress-pyynnöt

Joka tapauksessa, miltä funktio voisi näyttää, jos käyttäisimme tätä cURL-kirjastoa?

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

Lyhyesti sanottuna (ja tämä on tyypillistä useimmille cURL-pyynnöille):

alusta cURL-kirjasto,
aseta pyyntöäsi koskevat vaihtoehdot (jotka vaihtelevat mainitun pyynnön mukaan),
tehdä pyyntö,
arvioi vastausta
saa kiinni tarvittavista poikkeuksista.

Ja sitten jos käyttäisimme samaa koodin muunnelmaa WordPressissä?

<?php

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

Tämä on paljon pienempi ja luultavasti helpompi lukea (ainakin WordPressissä työskenteleville). Argumenttien osalta en myöskään välitä funktioon mitään muuta kuin URL-osoitetta.

Jos luet linkitetyn API-dokumentaation, huomaat, että meillä on jonkin verran hallintaa siihen. Se kuitenkin vaihtelee sen mukaan, kuinka sinun täytyy kommunikoida tietyn päätepisteen kanssa.

Lisäksi, kuinka käsittelet WP_Erroria, on sinun päätettävissäsi. Tyhjän merkkijonon palauttaminen on harvoin paras vaihtoehto; kuitenkin tämän esimerkin tarkoituksiin se riittää. Ensisijaisesti etsimme tapausta, joka on vastauksen runko ja se on koodin painopiste.

Milloin käytämme toista tai toista?

Kun on kyse cURL- ja WordPress-etäpyyntöjen kanssa työskentelystä ja käytettävän menetelmän määrittämisestä, noudatan yleensä tätä sääntöä:

Jos tarvitsemani voidaan saavuttaa WordPress API -toiminnolla, käytän sitä.
Jos ei, käytän cURL-osoitetta.

En voi antaa vahvempaa sääntöä.

Katso sen sijaan päätepistettä, johon olet yhteydessä, määritä, minkä tason hallintaa tarvitset pyynnölle, ja tee päätös siitä, miten haluat käsitellä vastausta.

Sieltä sinulla pitäisi olla hyvä idea siitä, mitä kirjastoa haluat käyttää.

: tommcfarlin.com