API İstekleri Yapmak için Neden WordPress HTTP İşlevlerini Kullanmalısınız?

Bazen WordPress sitenizin web'deki diğer hizmetlerle konuşması gerekir. Bu neredeyse yalnızca HTTP protokolü kullanılarak gerçekleşir. Bunun yaygın bir örneği, WordPress kurulumunuzun eklentilerin, temaların ve WordPress çekirdeğinin yeni sürümlerini kontrol etmek için wordpress.org sunucularıyla bağlantı kurmasıdır.

Ayrıca bir WordPress eklentisinde veya temasında yapılması çok yaygın bir şeydir. Harici bir hizmetle etkileşime giren herhangi bir eklenti, burada ve orada bazı HTTP istekleri yapmak zorundadır. Mailchimp listenize abone ekleme, Amazon SES aracılığıyla e-posta gönderme veya görüntüleri Amazon S3'e boşaltma gibi şeylerin tümü, bir dizi HTTP isteğinde bulunmayı içerir.

Bu yazıda, WordPress'in bu istekleri yapmak için sunduğu yerleşik HTTP işlevlerine ve bu işlevleri kullanmanın neden neredeyse her zaman iyi bir fikir olduğuna daha yakından bakacağız.

Ama önce, biraz arka plan.

Yanlış Yapmak – PHP İşlevlerini Kullanmak

PHP'nin kendisi, HTTP istekleri yapmak için birkaç farklı yol sunar. fsockopen() , fread() ve fwrite() kullanarak HTTP istekleriniz için doğrudan Ağ işlevleriyle çalışabilirsiniz, ancak sonuçta hem zaman kaybedersiniz hem de iyi bir sebep olmadan birçok tekerleği yeniden icat etmiş olursunuz.

PHP'nin HTTP protokol sarmalayıcısını işleyebilen dosya okuma işlevlerinden birini kullanmak biraz daha iyi olacaktır. Bu, biraz zahmetli fopen() ile çok daha kolay olan file() ve file_get_contents() işlevlerini içerir. Basit bir tek astar aslında sizi oldukça uzağa götürecektir:

 // Example code only, don't do this! $response = file_get_contents('https://www.google.com/');

Ancak bu kodu WordPress eklentinize veya alt temanıza yapıştırmadan önce, lütfen birçok barındırma sağlayıcısının URL'leri bu şekilde açmayı açıkça devre dışı bıraktığını unutmayın. Bu nedenle, yerel geliştirme ortamınızda işe yarayan, üretim ortamınızda çalışmayabilir.

Ayrıca, PHP işlevlerini kullanarak bir İnternet URL'sinden içerik almanın mümkün olması, bunun günlük geliştirmede en iyi yaklaşım olduğu anlamına gelmez. HTTP isteğine bir başlık belirtmenin görünüşte masum gereksinimini eklemek, yukarıdaki örneği çok daha karmaşık hale getirir (örneğin, Yığın Taşması):

 // Example code only, don't do this! // Create a stream $opts = array( "http" => array( "method" => "GET", "header" => "Accept-language: en\r\n", ) );​ // DOCS: https://www.php.net/manual/en/function.stream-context-create.php $context = stream_context_create( $opts );​ // Open the file using the HTTP headers set above // DOCS: https://www.php.net/manual/en/function.file-get-contents.php $file = file_get_contents( 'https://www.google.com/', false, $context );

Artık o kadar kolay değil. Ardından, bu örneğin yerinde herhangi bir hata işleme olmadığını düşünün. Bu nedenle, uzaktaki sunucunun kibarca yanıt vereceğinden %100 emin değilseniz (ipucu: değilsiniz), üretim kodunda kullanılmadan önce bu anlaşılması güç basit file_get_contents() öğesini sarmak için daha fazla kod eklemeniz gerekir.

PHP HTTP Kitaplıklarının Bolluğu

Ham PHP kullanarak HTTP istekleri yapmak biraz hantal olduğundan, HTTP istekleri oluşturmayı kolaylaştıran düzinelerce yardımcı kitaplığın olması şaşırtıcı olmamalıdır.

Daha geniş PHP dünyasında, WordPress'in dışında bağımlılık yönetimi için Composer'a dayanan Guzzle ve Httpful, HTTP isteklerini işlemek için en popüler kütüphaneler arasındadır, ancak kelimenin tam anlamıyla aralarından seçim yapabileceğiniz düzinelerce başka kitaplık vardır. Hepsi kendi güçlü ve zayıf yönleriyle.

WordPress dünyasında, özellikle bu kodu diğer WordPress kullanıcılarına gönderecekseniz, Composer kitaplıklarını kullanmadan önce biraz dikkatli olmamız gerekiyor. Bunun başlıca iki nedeni vardır.

Her şeyden önce, sizin veya kullanıcılarınızın Besteci Bağımlılık Cehennemi'nin bazı sürümlerine girme riski vardır. Kısacası, aynı WordPress kurulumundaki başka bir eklenti, eklentinizin yaptığıyla aynı bağımlılığı kullanır, ancak bu eklenti bu bağımlılığın farklı bir sürümünü kullanır.

WordPress, eklentileri yüklemek için belirleyici bir yola sahiptir. Eklenti sırasını kırmak teknik olarak mümkün olsa da, kesinlikle önerilmez. Ayrıca, eklentinizi önce yüklenmeye zorlamak için hangi hileleri oynarsanız oynayın, diğer geliştiriciler de oynayabilir. Bu nedenlerden dolayı, eklentinizin, gönderdiğiniz bağımlılığın sürümlerini mi yoksa başka, belki de uyumsuz bir sürümü mü kullanacağını asla bilemezsiniz.

Tüm Composer bağımlılıklarını kendi PHP ad alanınıza sarabilen Imposter eklentisini kullanarak bu sorunu çözmenin yolları vardır. Bu yoldan gidebilirsiniz, ancak HTTP isteklerini yönetmek için bir Besteci paketi kullanma fikri, aniden çok daha büyük bir soruna dönüştü ve muhtemelen derleme sürecinizi de değiştiriyor.

Kendi ürünümüz WP Offload Media'da, desteklenen depolama sağlayıcılarından (Amazon AWS, Digital Ocean vb.) üçüncü taraf kitaplıkları kullanıyoruz ve bunlar da Guzzle HTTP kitaplığını kullanıyor. Diğer eklentilerle uyumluluk sorunlarını önlemek için, tüm bu bağımlılıkları ayrı bir ad alanına sarmak için Imposter kullanıyoruz.

HTTP istekleri için bir üçüncü taraf kitaplığı kullanmadan önce iki kez düşünmemizin diğer nedeni, WordPress filtreleme sürecini kısa devre yapmasıdır.

WordPress'in en iyi özelliklerinden biri, eylemler ve filtreler aracılığıyla pek çok şeyin özelleştirilebilmesi ve HTTP isteklerinin yapılması bir istisna değildir. Bu gönderinin sonraki bölümünde daha fazla ayrıntıya gireceğiz, ancak site sahiplerine HTTP isteklerini özel ihtiyaçlarına uyacak şekilde değiştirme fırsatı vermek doğal olarak iyidir. Gerçekten iyi bir nedeniniz olmadıkça bu özelliği kaldırmamalısınız.

wp_remote_get, wp_remote_post ve Arkadaşlarına Merhaba Deyin

Son 12 yıldır WordPress, HTTP istekleriyle başa çıkmak için kendi yerleşik işlevleriyle birlikte göndermiştir, yani wp_remote_get() , wp_remote_post() ve wp_remote_head() , GET, POST ve HEAD HTTP fiillerinin her biri için bir işlev. Bu üç global işlevin tümü, sırayla İstekler kitaplığını kullanan WP_Http sınıfı çevresinde sarmalayıcılar olarak çalışır. WordPress'in HTTP istekleri yapmak için cURL'yi nasıl kullandığı hakkındaki yazımızda daha önce İstekler kitaplığı hakkında biraz yazdık.

wp_remote_get() kullanmak şu kadar basit olabilir:

 $response = wp_remote_get( 'https://www.google.com/' );

wp_remote_* ailesindeki işlevleri kullanmayı tercih etmeniz için pek çok neden var, işte en önemlilerini düşünüyorum.

Onlar Her Zaman Oradalar

wp_remote_* işlevleri, WordPress'te neredeyse en başından beri kullanılmaktadır, bu nedenle bunların mevcut olmaması konusunda endişelenmenize kesinlikle gerek yoktur.

Eklenti yüklemeleri ve otomatik güncellemeler gibi WordPress çekirdeğindeki bazı önemli işlevler, bu işlevlerin orada olmalarına ve sadece çalıştıklarına güvenirler. Dolayısıyla HTTP istekleri için üçüncü taraf kitaplıkları eklemek için gerçek bir neden yok, zaten iyi ve güvenilir bir kitaplığa erişiminiz var.

Çok Yetenekliler

Bu işlevlerin ikinci parametresi aracılığıyla ek argümanlar ileterek HTTP protokolünün hemen hemen tüm özelliklerine erişebilirsiniz.

Başlıklar ekleyebilir, kullanıcı aracısı dizesini değiştirebilir, HTTP protokolünün belirli bir sürümünü zorlayabilir vb. Gerekirse HTTP fiilleri. Aslında bu blog yazısında iki HTTP fiili için sarmalayıcı eklemeye bakacağız.

Uzak sunucuya göndermeden önce HTTP isteğini biraz değiştirdiğim bir örnek:

 $args = array( // Increase the timeout from the default of 5 to 10 seconds 'timeout' => 10, // Overwrite the default: "WordPress/5.8;www.mysite.tld" header: 'user-agent' => 'My special WordPress installation', // Add a couple of custom HTTP headers 'headers' => array( 'X-Custom-Id' => 'ABC123', 'X-Secret-Thing' => 'secret', ), // Skip validating the HTTP servers SSL cert; 'sslverify' => false, ); $response = wp_remote_get( 'https://www.example.com/', $args );

Geçerli argümanların tam listesi hiçbir yerde tam olarak belgelenmemiştir, ancak HTTP sınıfının kaynak dosyasında veya bu yararlı yorumda bulunabilir.

Kısacası, wp_remote_get() , wp_remote_post() ve wp_remote_head() , aklıma gelen HTTP istekleri için çoğu kullanım durumunu işleyebilir. Dolayısıyla gerçekte WordPress'te kesinlikle üçüncü taraf bir HTTP kitaplığı kullanmanız gereken çok az durum vardır.

Temeldeki İstekler kitaplığını kullanarak, aynı anda birden çok istek yapmak için yerleşik işlevleri kullanmak bile mümkündür, ancak bu, bu blog yazısı için biraz kapsam dışıdır.

Özelleştirmeleri Kolaydır

Bir HTTP isteğinin yürütülmesi sırasında, tüm wp_remote_* işlevleri, sizin ve başkalarının tam davranışı değiştirmenize ve hatta harici URL'lerin istenmesini engellemenize izin veren birçok farklı WordPress filtresini çağırır.

Bu, yalnızca kendi HTTP isteklerinizi çok ayrıntılı bir şekilde kontrol etmekle kalmaz, aynı zamanda diğer eklentiler tarafından yapılan HTTP isteklerine ve hatta WordPress çekirdeğinin kendisine müdahale edebileceğiniz anlamına gelir.

Büyük bir şirkette birkaç dahili WordPress kurulumundan sorumlu olduğunuzu hayal edin. Dahili BT güvenlik kurallarına uymak için, HTTP isteklerinde kullanıcı aracısı dizesine otomatik olarak eklenen dahili site URL'sini gizlemeniz gerekir. Bunu nasıl başaracaksınız?

Peki, wp_remote_get() ve tüm arkadaşları, istek gönderilmeden önce http_request_args filtresini tetikleyecek, böylece bunu basit bir WordPress filtresi kullanarak değiştirebiliriz:

 function my_http_request_args($args) { $args['user-agent'] = 'WordPress'; return $args; } add_filter('http_request_args', 'my_http_request_args');

Bazı site sahiplerinin, harici URL'lere giden HTTP trafiğini tamamen engelleme ihtiyacı olabilir. wp_remote_get() , wp_remote_post() veya wp_remote_head() kullanılarak yapılan tüm istekler WP_HTTP_BLOCK_EXTERNAL ve WP_ACCESSIBLE_HOSTS sabitlerine saygı duyacaktır. WP Migrate DB Pro belgelerimizde bunlar hakkında biraz yazdık.

Tanımlanırsa, bu iki sabit, bir site sahibinin tüm giden trafiği durdurmasına izin verir, ancak isteğe bağlı olarak bir dizi istisnaya da izin verir:

 define( 'WP_HTTP_BLOCK_EXTERNAL', true ); define( 'WP_ACCESSIBLE_HOSTS', 'api.example.com,www.example.com' );

Başka bir ana bilgisayara yapılan istek şimdi bir WP_Error döndürür:

 $response = wp_remote_get( 'https://www.google.com' ); /* Returns: WP_Error Object ( [errors] => Array ( [http_request_not_executed] => Array ( [0] => User has blocked requests through HTTP. ) ) … )*/

Kullanıcılarınız, kodunuzdaki yerleşik HTTP işlevlerini kullanarak, tek bir satır fazladan kod yazmanıza gerek kalmadan HTTP isteklerinin tüm bu düşük düzeyli kontrolünü elde eder. Bu ne kadar harika!!?

Onlar Ulaştırma Agnostiği

İstekler kitaplığının onu yukarıda bağlantılı olanlardan birkaçından ayıran güzel bir özelliği, taşımadan bağımsız olmasıdır. Daha spesifik olarak, HTTP istekleri söz konusu olduğunda, web sunucusunda kurulu olan cURL modülüne bağlı değildir.

İstekler kitaplığı, kuruluysa cURL kullanmayı tercih eder. Ancak, cURL'nin mevcut olmaması gibi pek olası olmayan bir durumda, İstekler kitaplığı bunun yerine fsockopen() kullanmaya geri dönebilir.

Her iki durumda da, İstekler kitaplığı işi bitirecek, böylece test etmek, belgelemek veya endişelenmek için daha az bağımlılığınız olacak.

wp_remote_put ve wp_remote_delete ne olacak?

Uzak API'ler ile biraz çalıştıysanız ve HTTP fiillerinde yolunuzu biliyorsanız, şimdiye kadar wp_remote_put() veya wp_remote_delete() bahsetmediğimi fark etmişsinizdir. GET, POST ve HEAD için yerleşik uygulamalarımız olduğundan, açıkça PUT ve DELETE için de bir uygulama olması gerekir. Doğru?

Hayır. WordPress Core ekibi henüz tüm standart HTTP fiillerini uygulamadı. Ancak, gelecekteki bir sürümde gerçekleşebilmesi için bunları WordPress sorun izleyicisine ekleme konusunda devam eden bir tartışma var.

Bu işlevlere daha erken ihtiyaç duyarsanız, WP_Http sınıfının modüler yapısı, wp_remote_request sarmalayıcı işleviyle birleştiğinde, bu ikisini kendi kodunuza eklemeyi çok kolaylaştırır:

 if ( ! function_exists( 'wp_remote_put' ) ) { function wp_remote_put($url, $args) { $defaults = array('method' => 'PUT'); $r = wp_parse_args( $args, $defaults ); return wp_remote_request($url, $r); } } if ( ! function_exists( 'wp_remote_delete' ) ) { function wp_remote_delete($url, $args) { $defaults = array('method' => 'DELETE'); $r = wp_parse_args( $args, $defaults ); return wp_remote_request($url, $r); } }

Bu işlev bildirimlerini function_exists() içine sarmanın önemli olduğunu unutmayın, çünkü sitenizdeki başka bir eklentinin bunları zaten uygulamış olma olasılığı çok yüksektir. Ayrıca, WordPress Core ekibi bunları gerçekten WordPress'in gelecekteki bir sürümüne eklerse, bu iyi bir korumadır.

Çözüm

Umarım bu, üçüncü taraf bir kitaplık kullanmak veya kendi kitaplığınızı kullanmak yerine WordPress'teki yerleşik HTTP işlevlerini nasıl ve neden kullanmanız gerektiğine dair iyi bir giriş olmuştur.

Yukarıda gördüğümüz gibi, WordPress, iyi belgelenmiş ve bakımı yapılmış harika bir HTTP API'si ile birlikte gelir. Herhangi bir alternatife göre kullanmanın birçok avantajı vardır. Bu avantajlar yalnızca bir geliştirici olarak size değil, aynı zamanda WordPress site yöneticilerine ve tüm WordPress ekosistemine de uzanır.

HTTP işlevleri hakkında sorularınız mı var? Herhangi bir önemli yönü veya özelliği kaçırdım mı veya herhangi bir ipucunuz var mı? Aşağıdaki yorumlarda bana bildirin.