WP REST API vs admin-ajax.php vs Zorunlu Kullanım Eklentisi: WordPress'te AJAX İsteklerini İşleme

WordPress REST API, 4.7 sürümünde WordPress çekirdeğiyle birleştirildi. Bundan önce, geliştiriciler, WordPress'te AJAX isteklerini işleyen /wp-admin/admin-ajax.php dosyasından sonra admin-ajax olarak bilinen varsayılan AJAX uygulamasına güveniyorlardı.

WordPress REST API'sinin piyasaya sürülmesinden bu yana, birçok eklenti geliştiricisi, eklentilerini AJAX yerine REST API'sini kullanacak şekilde dönüştürmeye başladı. Daha yeni bir teknoloji olmasının yanı sıra, tipik bir REST isteği sırasında daha az WordPress çekirdeği yüklendiğinden ve REST yanıtı her zaman şemasına dayalı olarak tahmin edilebilir bir biçimde olduğundan REST API daha iyi bir seçenek olarak kabul edilir. Ancak, bir AJAX isteğinden daha mı hızlı ? Eşzamansız isteklerinizin ham performansı kritikse başka bir seçenek var mı?

Bu makalede, her yaklaşımın artılarını ve eksilerini karşılaştıracağız. Ayrıca, hangisinin daha hızlı olduğunu görmek için bazı testler uygulayacağız ve ayrıca istek işlemenizi nasıl hızlandırabileceğinize bakacağız.

Yaşlı Köpekte Hala Hayat Var: AJAX

WordPress'te admin-ajax.php dosyası biçimindeki AJAX desteği, rahatsız edici sayfa yeniden yüklemeleri olmadan birkaç yönetici UI işlevini işlemenin bir yolu olarak 2006'da eklendi. Ayrıca WordPress eklentisi ve tema geliştiricileri tarafından bir WordPress sitesinde eşzamansız isteklerde bulunmanın bir yolu olarak yoğun bir şekilde kullanılmıştır. admin-ajax.php için tipik bir AJAX isteği yapıldığında, temel işlevlerin yüklendiğinden emin olmak için birkaç çekirdek WordPress dosyası daha yükler.

• /wp-load.php
• /wp-config.php
• /wp-settings.php (çoğu çekirdek dosyayı, tüm etkin eklentileri ve temaları ve REST API'sini yükler)
• /wp-admin/includes/admin.php
• /wp-admin/includes/ajax-actions.php

Bu dosyaları yükledikten sonra WordPress, birkaç temel işlevin admin_init kancasını çağırır. Aşağıdaki temel işlevler, WordPress 5.9'da bu kancaya kaydedilir:

• handle_legacy_widget_preview
• wp_admin_headers
• default_password_nag_handler
• WP_Privacy_Policy_Content::text_change_check
• WP_Privacy_Policy_Content::add_suggested_content
• register_setting
• add_privacy_policy_content
• send_frame_options_header
• register_admin_color_schemes
• _wp_check_for_scheduled_split_terms
• _wp_check_for_scheduled_update_comment_type
• _wp_admin_bar_init
• _maybe_update_core
• _maybe_update_plugins
• _maybe_update_themes

Bu işlevler çağrıldıktan sonra, WordPress sonunda $_GET['action'] veya $_POST['action'] değişkeninde sağlanan AJAX eylemini çağırır. Bu, bir geri arama işlevini tetikler, ilgili WordPress verilerini alır ve yanıtta sunar.

Bloktaki Yeni Çocuk: WP REST API

WordPress geliştirme ekosisteminde nispeten yeni olsa da, WordPress REST API, statik site oluşturuculardan başsız tek sayfalık uygulamalara kadar, eşzamansız istekler dışında bir dizi uygulama için kullanılabilir.

Tipik bir REST API isteği, admin-ajax.php isteğinden biraz farklı görünür. REST uç noktaları WordPress Yeniden Yazma API'sı tarafından işlendiğinden, istek /index.php iletilir ve ardından WordPress'in geri kalanını normal şekilde yükler.

• /index.php
• /wp-blog-header.php
• /wp-load.php
• /wp-config.php
• /wp-settings.php ( çekirdek dosyaların çoğunu, tüm etkin eklentileri ve temaları ve REST API'sini yükler)

admin-ajax.php üzerinden gönderilen isteklerin aksine, REST API, WordPress yönetici bölümünü /wp-admin/includes/admin.php aracılığıyla yüklemez ve admin_init eylem kancasını tetiklemez. Buna dayanarak, yöneticiye özgü işlevselliğe dayanmayan, ancak admin-ajax.php kullanarak eşzamansız istekler yapan tüm eklentiler veya temalar, REST API'ye geçerek hafif bir performans artışı görmelidir.

WordPress Ekosisteminde REST API Kabulü

REST API'nin WordPress'e dahil edilmesinden bu yana, WordPress Core ile tema ve eklenti geliştiricileri tarafından büyük ölçüde benimsenmiştir.

REST API'nin en popüler kullanımı, yeni WordPress Blok Düzenleyicinin geliştirilmesinde olmuştur. Yeni düzenleyici için özel bloklar oluşturmak, büyük ölçüde api-fetch paketi aracılığıyla REST API'nin kullanılmasına bağlıdır.

REST API ve api-fetch paketi ayrıca WordPress'i daha geniş bir kullanım senaryosu yelpazesine açar. Popüler ön uç JavaScript çerçeveleriyle çalışan geliştiriciler, şablon oluşturmak için PHP'ye güvenmeye gerek kalmadan WordPress temaları veya harika görünümlü eklenti arayüzleri oluşturabilir. Sadece bu da değil, WordPress'e daha önce kolayca mümkün olmayan tek sayfalık uygulamalara ve mobil uygulamalara güç verme yeteneği verir.

Son olarak, WordPress eklenti geliştiricilerine özel eklenti verileriyle çalışmak için standart bir yol sunar. Örneğin, WooCommerce, WordPress REST API ile tamamen entegredir. Bu, ürünler ve siparişler gibi WooCommerce verilerinin WP REST API istek biçimleri ve kimlik doğrulama yöntemleri kullanılarak oluşturulmasına, okunmasına, güncellenmesine ve silinmesine olanak tanır. Bu entegrasyondan önce, geliştiricilerin bu verilere harici olarak erişmek için kendi özel uç noktalarını oluşturmaları gerekiyordu.

The Dark Horse: Eklenti Kullanılmalı

Yazılım geliştirmedeki çoğu durumda olduğu gibi, bir sorunu çözmenin birden çok yolu vardır. admin-ajax.php ve REST API sağlam seçenekler olsa da, özel bir uç nokta oluşturmanın da kendi avantajları vardır. Bunların en büyüğü performanstır.

Bir WordPress web sitesinde özel uç noktalar oluşturmanın birkaç farklı yolu vardır. Mümkün olan en hızlı uç nokta muhtemelen WordPress'ten tamamen bağımsız olacaktır. Web sunucusuna yüklenen ve belirli bir GET isteğini işleyen bağımsız bir PHP dosyası kadar basit olabilir. Hızlı olsa da, muhtemelen o kadar da yardımcı olmaz çünkü herhangi bir WordPress temel işlevine erişimi olmayacaktır. Bu işlevlere erişim genellikle geliştirme zamanından büyük ölçüde tasarruf sağlar.

Özel eşzamansız HTTP isteklerini işlemek için kullanılması gereken bir eklentide özel bir uç nokta oluşturmak daha iyi bir yaklaşım olacaktır. Bu şekilde, WordPress çekirdek yüklendikten sonra, ancak eklentiler ve temalar yüklenmeden önce herhangi bir özel isteğe yanıt verebilir. Bu hem en iyi performansı sağlar hem de REST API veya admin-ajax.php kullanan diğer eklentilerden kaynaklanan çakışmaları önler.

Aşağıda, bir GET veya POST değişkeni hfm-ajax ve yanıtta time() değerini veren, kullanılması zorunlu bir eklentinin basit bir örneği verilmiştir.

 <?php /** * Plugin Name: Hellfish Media Custom AJAX * Description: Custom Request Handler * Author: Hellfish Media * Version: 1.0 * Author URI: https://hellfish.media */ if ( ! isset( $_GET['hfm-ajax'] ) ) { return; } // Define the WordPress "DOING_AJAX" constant. if ( ! defined( 'DOING_AJAX' ) ) { define( 'DOING_AJAX', true ); } wp_send_json( array( 'time' => time() ) );

Bunu https://hellfish.media sitesine yükleseydim, https://hellfish.media/?hfm-ajax=1 erişilebilirdi.

Kıyaslamaları Oluşturma

Kullanılması gereken eklenti işlevi, karşılaştırmalı değerlendirme testimiz için mükemmeldir, bu nedenle tek yapmamız gereken, işlevselliğini admin-ajax.php ve REST API için kopyalamaktır. İlk olarak, yanıttaki time değerini döndüren kıyaslama işlevini oluşturacağız. Bu, isteklerin önbelleğe alınmadığını görmeyi kolaylaştırır.

 function hfm_benchmark_request() { wp_send_json( array( 'time' => time() ) ); }

Bu işlevi admin-ajax.php için kaydetmek için, işlevi bir wp_ajax_nopriv_{$action} kancasına bağlamamız gerekir.

 add_action( 'wp_ajax_nopriv_benchmark_request', 'hfm_benchmark_request' );

admin-ajax.php isteğini test etmek için oturum açmamıza gerek kalmaması için bir wp_ajax_nopriv_{$action} kancası kullanıyoruz.

Bu işlevi REST API'ye kaydetmek için, onu rest_api_init kancasına bağlarız ve özel bir REST API yolu kurarız.

 add_action( 'rest_api_init', 'hfm_register_custom_rest_route'); function hfm_register_custom_rest_route() { register_rest_route( 'benchmark/v1', '/benchmark', array( 'methods' => GET, 'callback' => 'hfm_benchmark_rest_request', 'permission_callback' => '__return_true', ) ); } function hfm_benchmark_rest_request() { return array( 'time' => time() ); }

Tüm bu kodu özel bir eklentiye veya bir temanın veya alt temanın functions.php dosyasına koyabiliriz. Karşılaştırma amacıyla, WordPress 5.9 çalıştıran SpinupWP tarafından yönetilen, ek eklentiler, varsayılan bir tema ve sayfa önbelleğe alma devre dışı bırakılmış 1GB/1vCPU Dijital Okyanus damlacığı üzerinde çalışacağım.

Sayıları Çalıştırmak

Gerçek kıyaslamayı gerçekleştirmek için, sunucunun nasıl performans gösterdiğine dair bir fikir edinmek için aynı anda birden fazla isteği başlatmanıza olanak tanıyan bir komut satırı kıyaslama aracı olan ApacheBench'i kullanacağız. Geçerli istekleri test ettiğimden emin olmak için Postman'de test edilen her URL'nin çıktısını da doğruladım.

Testleri çalıştırmak ve çıktıyı bir dosyaya kaydetmek için bir apachebench dizini oluşturacağım.

 mkdir ~/apachebench cd apachebench

Önce admin-ajax.php sürümünü test edelim. AJAX isteği durumunda, test kodunda tanımlanan wp_ajax_nopriv_ kancasının $action değeriyle eşleşen benchmark_request değerine sahip bir action değişkeni içeren bir sorgu dizesi iletiriz.

 ab -n 100 -c 1 -g ajax.tsv \ https://dev.hellfish.media/wp-admin/admin-ajax.php?action=benchmark_request

Yukarıdaki komut /wp-admin/admin-ajax.php dosyasına 100 GET isteği gönderir ve yanıt sürelerini günlüğe kaydeder.

[email protected]:~/apachebench$ ab -n 100 -c 1 -g ajax.tsv \
> https://dev.hellfish.media/wp-admin/admin-ajax.php?action=benchmark_request
Bu ApacheBench, Sürüm 2.3 <$Revizyon: 1843412 $>
Telif Hakkı 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Apache Software Foundation'a lisanslıdır, http://www.apache.org/

Kıyaslama dev.hellfish.media (sabırlı olun).....yapıldı


Sunucu Yazılımı: nginx
Sunucu Ana Bilgisayar Adı: dev.hellfish.media
Sunucu Bağlantı Noktası: 443
SSL/TLS Protokolü: TLSv1.2,ECDHE-RSA-CHACHA20-POLY1305,2048,256
Sunucu Temp Anahtarı: X25519 253 bit
TLS Sunucu Adı: dev.hellfish.media

Belge Yolu: /wp-admin/admin-ajax.php?action=benchmark_request
Belge Uzunluğu: 19 bayt

Eşzamanlılık Düzeyi: 1
Testler için geçen süre: 1.995 saniye
Tamamlanan istekler: 100
Başarısız istekler: 0
Toplam aktarılan: 56600 bayt
Aktarılan HTML: 1900 bayt
Saniyedeki istek sayısı: 50,13 [#/sn] (ortalama)
İstek başına süre: 19.948 [ms] (ortalama)
İstek başına süre: 19.948 [ms] (ortalama, tüm eşzamanlı istekler arasında)
Aktarım hızı: 27,71 [Kbayt/sn] alındı

Bağlantı Süreleri (ms)
            min ortalama[+/-sd] medyan maks
Bağlantı: 2 2 0.2 2 3
İşleme: 16 18 2.2 17 34
Bekleme: 16 18 2,2 17 34
Toplam: 18 20 2,3 19 36

Belirli bir süre içinde sunulan isteklerin yüzdesi (ms)
  %50 19
  %66 20
  %75 20
  %80 20
  %90 22
  %95 23
  %98 27
  %99 36
 %100 36 (en uzun istek)

100 istekle ortalama yanıt süresi 19.86 ms idi . Bu, REST API üzerinde aynı test için iyi bir temel sağlar, o halde şimdi bunu test edelim.

 ab -n 100 -c 1 -g rest.tsv \ https://dev.hellfish.media/wp-json/benchmark/v1/benchmark

[email protected]:~/apachebench$ ab -n 100 -c 1 -g rest.tsv \
> https://dev.hellfish.media/wp-json/benchmark/v1/benchmark
Bu ApacheBench, Sürüm 2.3 <$Revizyon: 1843412 $>
Telif Hakkı 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Apache Software Foundation'a lisanslıdır, http://www.apache.org/

Kıyaslama dev.hellfish.media (sabırlı olun).....yapıldı


Sunucu Yazılımı: nginx
Sunucu Ana Bilgisayar Adı: dev.hellfish.media
Sunucu Bağlantı Noktası: 443
SSL/TLS Protokolü: TLSv1.2,ECDHE-RSA-CHACHA20-POLY1305,2048,256
Sunucu Temp Anahtarı: X25519 253 bit
TLS Sunucu Adı: dev.hellfish.media

Belge Yolu: /wp-json/benchmark/v1/benchmark
Belge Uzunluğu: 19 bayt

Eşzamanlılık Düzeyi: 1
Testler için geçen süre: 2.624 saniye
Tamamlanan istekler: 100
Başarısız istekler: 0
Toplam aktarılan: 66200 bayt
Aktarılan HTML: 1900 bayt
Saniyedeki istek sayısı: 38,11 [#/sn] (ortalama)
İstek başına süre: 26.240 [ms] (ortalama)
İstek başına süre: 26.240 [ms] (ortalama, tüm eşzamanlı istekler arasında)
Aktarım hızı: 24,64 [Kbayt/sn] alındı

Bağlantı Süreleri (ms)
            min ortalama[+/-sd] medyan maks
Bağlantı: 2 2 0.2 2 3
İşleme: 22 24 1,6 24 33
Bekleme: 22 24 1.4 23 33
Toplam: 24 26 1.7 26 35

Belirli bir süre içinde sunulan isteklerin yüzdesi (ms)
  %50 26
  %66 26
  %75 27
  %80 27
  %90 28
  %95 29
  %98 35
  %99 35
 %100 35 (en uzun istek)

Şaşırtıcı bir şekilde, REST API bu karşılaştırmada biraz daha yavaştır ve 100 istek üzerinden ortalama 26.14ms yanıt süresi vardır. Bu testlerde AJAX API, REST API'den yaklaşık %27,3 daha hızlıdır. Farkları en son karşılaştırdığımda, yaklaşık %18'lik bir fark vardı, ancak REST API, AJAX API'sinden daha hızlıydı.

Peki ya mutlaka kullanılması gereken eklenti?

 ab -n 100 -c 1 -g custom-ajax.tsv https://dev.hellfish.media/?hfm-ajax=1

[email protected]:~/apachebench$ ab -n 100 -c 1 -g custom-ajax.tsv \
> https://dev.hellfish.media/?hfm-ajax=1
Bu ApacheBench, Sürüm 2.3 <$Revizyon: 1843412 $>
Telif Hakkı 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Apache Software Foundation'a lisanslıdır, http://www.apache.org/

Kıyaslama dev.hellfish.media (sabırlı olun).....yapıldı


Sunucu Yazılımı: nginx
Sunucu Ana Bilgisayar Adı: dev.hellfish.media
Sunucu Bağlantı Noktası: 443
SSL/TLS Protokolü: TLSv1.2,ECDHE-RSA-CHACHA20-POLY1305,2048,256
Sunucu Temp Anahtarı: X25519 253 bit
TLS Sunucu Adı: dev.hellfish.media

Belge Yolu: /?hfm-ajax=1
Belge Uzunluğu: 19 bayt

Eşzamanlılık Düzeyi: 1
Testler için geçen süre: 0,560 saniye
Tamamlanan istekler: 100
Başarısız istekler: 0
Toplam aktarılan: 43100 bayt
Aktarılan HTML: 1900 bayt
Saniyedeki istek sayısı: 178.52 [#/sn] (ortalama)
İstek başına süre: 5.602 [ms] (ortalama)
İstek başına süre: 5.602 [ms] (ortalama, tüm eşzamanlı istekler arasında)
Aktarım hızı: 75,14 [Kbayt/sn] alındı

Bağlantı Süreleri (ms)
            min ortalama[+/-sd] medyan maks
Bağlantı: 2 2 0.2 2 3
İşleme: 3 4 0.3 4 5
Bekleme: 3 4 0.3 3 5
Toplam: 5 6 0.4 5 7

Belirli bir süre içinde sunulan isteklerin yüzdesi (ms)
  %50 5
  %66 6
  %75 6
  %80 6
  %90 6
  %95 6
  %98 7
  %99 7
 %100 7 (en uzun istek)

Beklendiği gibi, bu hem AJAX hem de REST API'lerinden daha hızlıdır. Özel istek işleyici için ortalama süre, diğer seçeneklere kıyasla çok hızlı olan 5,49 ms'dir .

Bu verileri doğrulamak için aynı testleri bazı içerikler, birkaç eklenti ve etkinleştirilmiş özel bir tema ile çalıştırmaya karar verdim. WP Migrate DB Pro'yu, bazı demo içeriği, özel bir teması ve aşağıdakiler de dahil olmak üzere bir sürü aktif eklentisi olan https://hellfish.media demo sitemizin bir kopyasını oluşturmak için kullandım:

• Gelişmiş Özel Alanlar PRO
• Gelişmiş Formlar
• WP DB Yedekleme
• EWWW Görüntü İyileştirici
• Basit Özel Gönderi Siparişi
• WordPress İthalatçısı
• WP Geçiş DB Pro
• WP Aktarım Ortamı Lite
• WP İtici

Ortalama istek süreleri aşağıda listelenmiştir:

• yönetici-ajax: 92.4ms
• REST API: 89.47ms
• özel istek işleyici: 6.57ms

İlk fark ettiğiniz şey, kullanılması gereken eklentiye kıyasla hem admin-ajax.php hem de REST API istek sürelerindeki genel artıştır. Hem admin-ajax.php hem de REST API istekleri yaklaşık 4 kat daha yavaştır, ancak kullanılması gereken eklenti yalnızca 1 ms daha yavaştır. Fark edeceğiniz ikinci şey, admin-ajax.php artık REST API'sinden ortalama olarak daha yavaş olduğu, ancak bunun yalnızca birkaç milisaniye olduğudur.

Farklı bir eklenti grubuna veya farklı bir temaya sahip bir web sitesi, farklı bir sonuç kümesi görebilir, ancak bu tamamen sitede çalışan tema ve eklentilere ve bunların nasıl kodlandığına bağlıdır.

Eklentiler Eşzamansız İstek Performansını Nasıl Etkiler?

WordPress tarafından bir admin-ajax.php veya REST API isteği her sunulduğunda, WordPress çekirdeğinin çoğu, aktif tema ve tüm aktif eklentiler yüklenir. WP Migrate DB Pro'yu geliştirdiğimizde bunu ilk elden deneyimledik. İlk sürümlerde, destek taleplerimizin çoğunu taşıma işlemleriyle çakışan eklentiler oluşturuyordu. Bazı eklentiler o kadar sık ​​ortaya çıktı ki, WP Migrate DB Pro ile çakıştığı bilinen eklentilerin bir listesini yayınlamaya başladık.

Bu ideal bir çözüm değildi, bu yüzden Uyumluluk Modu'nu geliştirdik.

Uyumluluk Modu, kullanıcının WP Migrate DB Pro tarafından yapılan istekler için hangi eklentilerin yükleneceğini seçmesine olanak tanır. Varsayılan olarak, tüm eklentilerin yüklenmesi engellenir. Bu, başka bir eklentinin geçiş sürecini bozma olasılığını büyük ölçüde azaltır.

Uyumluluk Modu, get_option('active_plugins') her çağrıldığında option_active_plugins filtresine bağlanan ve hangi eklentilerin etkin olduğunu değiştirebilecek bir işlevi yürüten, kullanılması gereken bir eklenti yükler.

Eşzamansız istekler çalıştırırken eklentilerin yüklenmesini önlemek için aynı prensibi kullanabilirsiniz. Aşağıda, belirli eklentileri bir AJAX isteğinden hariç tutmak için kullanılabilecek, mutlaka kullanılması gereken bir eklenti örneği verilmiştir.

 /** * Plugin Name: Hellfish Media Exclude plugins * Description: Exclude plugins from ajax requests * Author: Hellfish Media * Version: 1.0 * Author URI: https://hellfish.media */ /** * Plugin Name: Hellfish Media Exclude plugins * Description: Exclude plugins from ajax requests * Author: Hellfish Media * Version: 1.0 * Author URI: https://hellfish.media */ add_filter( 'option_active_plugins', 'hfm_exclude_plugins' ); function hfm_exclude_plugins( $plugins ) { /** * If we're not performing our AJAX request, return early. */ if ( ! defined( 'DOING_AJAX' ) || ! DOING_AJAX || ! isset( $_REQUEST['action'] ) || 'benchmark_request' !== $_REQUEST['action'] ) { return $plugins; } /** * The list of plugins to exclude. Flip the array to make the check that happens later possible */ $denylist_plugins = array_flip( array( 'advanced-custom-fields-pro/acf.php', 'advanced-forms/advanced-forms.php', 'classic-editor/classic-editor.php', 'wp-db-backup/wp-db-backup.php', 'ewww-image-optimizer/ewww-image-optimizer.php', 'limit-login-attempts-reloaded/limit-login-attempts-reloaded.php', 'simple-custom-post-order/simple-custom-post-order.php', 'theme-switcha/theme-switcha.php', 'woocommerce/woocommerce.php', 'wordpress-importer/wordpress-importer.php', 'wp-mail-log/wp-mail-log.php', 'amazon-s3-and-cloudfront/wordpress-s3.php', 'wp-offload-ses/wp-offload-ses.php', 'wppusher/wppusher.php' ) ); /** * Loop through the active plugins, if it's not in the deny list, allow the plugin to be loaded * Otherwise, remove it from the list of plugins to load */ foreach ( $plugins as $key => $plugin ) { if ( ! isset( $denylist_plugins[ $plugin ] ) ) { continue; } unset( $plugins[ $key ] ); } return $plugins; }

Bir REST API isteği için yüklenen eklentilerin listesini hariç tutmak istiyorsanız iki seçeneğiniz vardır. REST API uç noktası bir WordPress çekirdek uç noktasıysa, REST_REQUEST sabitinin tanımlanıp tanımlanmadığını ve true olarak ayarlanıp ayarlanmadığını kontrol edebilirsiniz. Bu sabit, rest_api_loaded çekirdek işlevinde tanımlanır. Dolayısıyla, DOING_AJAX kontrolleri yerine aşağıdakileri yapabilirsiniz:

 if ( ! defined( 'REST_REQUEST' ) || ! REST_REQUEST ) { return $plugins; }

register_rest_route (kıyaslamalarımızda kullandığımızın aynısı) kullanılarak kaydedilen özel bir uç noktaysa, bu sabiti kullanmak mümkün görünmüyor. Bunun yerine, PHP $_SERVER önceden tanımlanmış sabitinde REQUEST_URI değişkenini alabilir ve özel bitiş noktamızla eşleşip eşleşmediğini görebiliriz.

 $request_uri = parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH ); if ( '/wp-json/benchmark/v1/benchmark/' !== trailingslashit( $request_uri ) ) { return $plugins; }

Bu kodu mutlaka kullanılması gereken bir eklenti olarak uyguladım ve önce admin-ajax.php için, ardından özel REST API uç noktamız için kıyaslamaları yeniden çalıştırdım.

• yönetici-ajax: 18.25ms
• REST API: 28.58ms

Her iki zaman da, tüm aktif eklentiler yüklendiğinde aynı kıyaslamalardan önemli ölçüde daha hızlıdır ve herhangi bir aktif eklenti olmadan ilk kıyaslamalarda gördüklerimizle daha fazla aynı hizadadır.

WordPress REST API'sini Kullanmalı mısınız?

2016'da, REST API, WordPress çekirdeğiyle birleştirildiğinde ve ilk karşılaştırma ölçütlerimi oluşturduğumda, admin-ajax.php yerine REST API'yi kullanmanın küçük bir hız avantajı vardı. Bugün ise durum tam tersi gibi görünüyor. WordPress çekirdeği veya REST API geliştirmesine dahil olmadığım için, durumun neden böyle olduğunu veya buna neyin neden olabileceğini söyleyemem. Yine de ilginç.

Diğer geliştiricilerin kullanması için uç noktalar oluşturmak, REST API ile daha az karmaşıktır. Gelişmiş Özel Alanlar için REST API entegrasyonunu eklediğimizde, REST standartlarından, şemasından ve kimlik doğrulama yöntemlerinden yararlanabileceğimizi ve yalnızca tanımlanan REST API uç noktalarında ACF alan verilerini kaydedebileceğimizi takdir ettik. REST API ayrıca admin-ajax.php kullanmaktan daha iyi belgelenmiştir ve bu nedenle uygulanması daha kolaydır.

admin-ajax.php ve özel istek işleyici, döndürmek istediğiniz verileri almak için daha fazla çalışma gerektirebilirken, aynı zamanda bu verileri biçimlendirme konusunda size daha fazla esneklik sağlar. Ve belirttiğimiz gibi, peşinde olduğunuz şey ham performanssa, özel bir istek işleyici bariz bir seçimdir.

Güvenilirlik açısından, REST API ve admin-ajax.php hala aktif eklentilerin veya temaların kalitesine ve bütünlüğüne bağlıdır. Kötü kodlanmış bir eklenti, REST API veya admin-ajax.php istekleriyle yine de kolayca etkileşime girebilir ve bunun olasılığı sitenize yüklenen eklentilerin sayısıyla artar.

Genel olarak, en azından REST API kullanmayı düşünmek kesinlikle iyi bir fikirdir. Özel API uç noktaları eklemek, admin-ajax.php ile karşılaştırıldığında nispeten basittir ve mevcut kodu değiştirmek de fazla zaman almaz.

Yönetici-ajax isteklerinizi REST API'ye dönüştürdünüz mü? Performansın arttığını, azaldığını veya hiç değişmediğini gördünüz mü? Aşağıdaki yorumlarda bize bildirin.