WordPress REST API Nedir ve Nasil Kullanilir

WordPress'i çoğu insan, tarayıcıda açılan hazır bir web sitesi olarak tanır: temanın çizdiği başlıklar, yazılar, menüler. Oysa perde arkasında WordPress, verinizi (yazılar, sayfalar, kategoriler, kullanıcılar, yorumlar) yapısal bir biçimde tutan bir uygulamadır. REST API işte bu veriye tema katmanından tamamen bağımsız, standart bir kapı açar. Bir istemci (JavaScript ile çalışan bir arayüz, bir mobil uygulama, başka bir sunucu ya da sadece komut satırındaki curl) https://siteniz.com/wp-json/ adresine HTTP isteği yollar; WordPress de karşılığında HTML değil, makinelerin kolayca işleyebildiği JSON döner.

Bu yazıda REST API'nin ne olduğunu, wp-json uç noktalarının nasıl gezildiğini, yazı ve sayfa verisinin nasıl çekildiğini, Application Password ile güvenli kimlik doğrulamayı, register_rest_route ile kendi uç noktanızı eklemeyi ve headless (başsız) mimari ile mobil uygulama senaryolarını uygulamalı örneklerle ele alacağız. Sonunda güvenlik ve rate limit tarafında pratikte gördüğümüz tuzaklara ve sık sorulan sorulara da değineceğiz. WordPress'i henüz kurmadıysanız önce WordPress kurulumu rehberine göz atmanızı öneririm; REST API varsayılan olarak her modern WordPress kurulumunda açıktır, ekstra bir eklenti gerektirmez.

WordPress REST API Nedir?#

REST API, "Representational State Transfer" mimarisine uyan bir arabirimdir. Sade Türkçesiyle: kaynaklara (yazı, sayfa, kullanıcı gibi) adresler verirsiniz ve bu adreslere HTTP metotlarıyla (GET, POST, PUT, DELETE) istek atarak veriyi okur, oluşturur, günceller ya da silersiniz. WordPress 4.7 sürümünden (2016) beri REST API çekirdeğe gömülü gelir; yani ayrı bir kurulum yapmanıza gerek yoktur, site ayaktaysa API de ayaktadır.

Klasik WordPress'te bir sayfa isteği tarayıcıya tema tarafından üretilmiş HTML döndürür. REST API'de ise aynı içerik, sunum katmanından soyutlanmış saf veri olarak gelir. Bu ayrım şu kapıyı açar: WordPress'i yalnızca içerik deposu (headless CMS) olarak kullanıp arayüzü React, Vue ya da bir mobil uygulama ile ayrı yazabilirsiniz. Aşağıdaki tablo iki yaklaşımı karşılaştırır.

API'nin en güzel yanı, kendini tanıtmasıdır. Bir adres istemeniz yeterli:

curl https://siteniz.com/wp-json/

Bu istek, sitenin desteklediği tüm ad alanlarını (namespaces), rotaları ve kimlik doğrulama yöntemlerini listeleyen büyük bir JSON döndürür. Yani belgeleri okumadan önce API'yi doğrudan gezerek keşfedebilirsiniz.

wp-json Uç Noktalarını Tanımak#

Tüm REST uç noktaları /wp-json/ ön eki altında toplanır. Çekirdeğin sunduğu rotalar wp/v2 ad alanında yer alır; buradaki v2 sürüm numarasıdır ve ileride kırıcı değişiklikler yapılırsa v3 gibi yeni bir ad alanı açılır, eskisi çalışmaya devam eder. En çok kullanılan uç noktalar şunlardır:

Bir uç noktaya sorgu parametreleri ekleyerek sonucu daraltabilir, sıralayabilir ve sayfalayabilirsiniz. Örneğin son 5 yazıyı tarihe göre azalan sırada çekmek için:

curl "https://siteniz.com/wp-json/wp/v2/posts?per_page=5&orderby=date&order=desc"

Sık kullanılan parametreleri hatırda tutmakta fayda var:

• per_page — sayfa başına kayıt sayısı (varsayılan 10, en fazla 100).
• page — hangi sayfa; sayfalama için page=2, page=3 diye ilerlersiniz.
• search — metin araması, search=hosting gibi.
• categories / tags — kategori veya etiket kimliğine göre filtre.
• _fields — yalnızca istediğiniz alanları döndürerek yükü küçültür, örneğin _fields=id,title,link.
• _embed — bağlantılı kaynakları (yazar, öne çıkan görsel) tek istekte gömer.

Yanıtın başlık (header) kısmı da değerlidir: X-WP-Total toplam kayıt sayısını, X-WP-TotalPages toplam sayfa sayısını verir. Sonsuz kaydırma veya sayfalama arayüzü kurarken bu iki başlık işinizi çok kolaylaştırır.

Yazı ve Sayfa Verisini Çekmek#

Herkese açık (yayımlanmış) yazıları okumak için kimlik doğrulaması gerekmez; GET isteği yeterlidir. Belirli bir yazıyı kimliğiyle çekelim:

curl "https://siteniz.com/wp-json/wp/v2/posts/128?_fields=id,title,content,date"

Dönen JSON kabaca şu yapıdadır:

{
  "id": 128,
  "date": "2026-07-10T09:30:00",
  "title": { "rendered": "WordPress Hosting Secimi" },
  "content": { "rendered": "<p>Icerik metni...</p>" }
}

Burada dikkat edilecek nokta, title ve content alanlarının doğrudan metin değil, rendered (işlenmiş) alt alanını taşıyan nesneler olmasıdır. Bunun nedeni, WordPress'in içeriği kısa kodlar (shortcode) ve filtrelerden geçirip son HTML'i üretmesidir. Ön yüzde bu HTML'i basarken güvenilmez kullanıcı katkısı varsa mutlaka temizlemeyi (sanitize) ihmal etmeyin.

JavaScript tarafında modern bir istemcide veri çekmek son derece sadedir:

# Basit bir fetch akisi (sozde-kod)
istek: GET /wp-json/wp/v2/posts?per_page=6&_embed
basari: kartlari ekrana ciz
hata: kullaniciya nazik bir mesaj goster

Gerçek bir fetch çağrısı ise şöyle görünür. Aşağıdaki örnek, öne çıkan görseli de _embed ile tek istekte getirir:

curl "https://siteniz.com/wp-json/wp/v2/posts?per_page=6&_embed&_fields=id,title,link,_links,_embedded"

Yeni bir yazı oluşturmak ya da güncellemek istediğinizde artık salt-okuma bölgesinden çıkıp kimlik doğrulaması gereken bölgeye geçersiniz. Bir sonraki başlık tam da bunu ele alıyor.

Application Password ile Kimlik Doğrulama#

Yazı oluşturmak, taslak görmek veya ayar değiştirmek gibi işlemler yetki ister. WordPress 5.6'dan beri çekirdekte gelen Application Passwords (Uygulama Parolaları), bu iş için en pratik yöntemdir. Mantığı şudur: hesabınızın asıl parolasını hiçbir yere yazmadan, yalnızca API için geçerli, istediğiniz an iptal edebileceğiniz ayrı bir parola üretirsiniz. Böylece bir uygulamanın erişimi sızarsa tüm hesabı değil, yalnızca o uygulama parolasını iptal edersiniz.

Uygulama parolası oluşturmak için WordPress yönetim paneline girin, Kullanıcılar > Profil sayfasına inin ve "Application Passwords" bölümüne bir ad (örneğin mobil-uygulama) yazıp oluşturun. Ekranda abcd EFGH ijkl MNOP qrst UVWX biçiminde boşluklu bir dizge belirir; bu değeri bir kez gösterilir, güvenli bir yerde saklayın.

Bu parola HTTP Basic Auth ile gönderilir. curl ile bir taslak yazı oluşturalım:

curl -X POST "https://siteniz.com/wp-json/wp/v2/posts" \
  -u "kullaniciadi:abcdEFGHijklMNOPqrstUVWX" \
  -H "Content-Type: application/json" \
  -d '{"title":"API ile olusturuldu","status":"draft","content":"Merhaba dunya"}'

Önemli bir uyarı: Basic Auth, kullanıcı adı ve parolayı yalnızca temel bir kodlamayla taşır; şifrelemez. Bu yüzden mutlaka HTTPS üzerinden çalışın, aksi halde parola ağ üzerinde açık gider. Sitenizde geçerli bir sertifika yoksa ücretsiz Let's Encrypt ya da hazır bir SSL çözümüyle HTTPS'i zorunlu kılın. Aşağıdaki tablo yaygın kimlik doğrulama yöntemlerini karşılaştırır.

Kısa ömürlü tarayıcı içi istekler için WordPress zaten wp_localize_script ile bir nonce üretir ve çerez tabanlı oturumu kullanır; harici bir tek sayfa uygulaması (SPA) için ise Application Passwords ya da bir JWT eklentisi daha uygundur.

Kendi Uç Noktanızı Kaydetmek#

Çekirdeğin sunduğu uç noktalar çoğu işi görür, ama bazen kendi verinizi kendi kurallarınızla sunmak istersiniz: bir hesaplama sonucu, özel bir tablodan çekilen kayıtlar veya birden çok kaynağı birleştiren tek bir yanıt. Bunun için register_rest_route fonksiyonu kullanılır ve kaydı rest_api_init kancasına bağlarsınız. Kodu tema yerine küçük bir eklenti dosyasında tutmanızı öneririm; tema değişince kaybolmaz. Eklenti mantığını WordPress eklenti önerileri yazısında da ele alıyoruz.

# functions.php yerine mu-plugins altinda bir dosya tercih edin
# wp-content/mu-plugins/ozel-api.php

Aşağıdaki örnek, sirket/v1 ad alanında /durum adında basit bir uç nokta tanımlar:

# Rota ozeti (sozde-tanim)
namespace = sirket/v1
route     = /durum
method    = GET
callback  = sirket_durum_getir
permission = herkese_acik

Gerçek PHP kodu şöyle olur:

add_action('rest_api_init', function () {
  register_rest_route('sirket/v1', '/durum', array(
    'methods'  => 'GET',
    'callback' => 'sirket_durum_getir',
    'permission_callback' => '__return_true',
  ));
});

function sirket_durum_getir($request) {
  $veri = array(
    'servis'  => 'acik',
    'surum'   => '1.0',
    'zaman'   => current_time('c'),
  );
  return new WP_REST_Response($veri, 200);
}

Bu uç noktaya curl https://siteniz.com/wp-json/sirket/v1/durum diyerek erişirsiniz. Üç noktaya özellikle dikkat edin. Birincisi permission_callback: yetki denetimi burada yapılır ve asla boş bırakılmamalıdır. Herkese açık olsun istiyorsanız bile bilinçli olarak __return_true yazın; yetki isteyen bir uç noktada ise current_user_can('edit_posts') gibi bir denetim koyun. İkincisi, dışarıdan gelen parametreleri args ile şema tanımlayıp doğrulayın (sanitize_callback, validate_callback). Üçüncüsü, yanıtı WP_REST_Response ile döndürmek doğru HTTP durum kodunu ve başlıkları ayarlamanızı sağlar.

Parametre alan bir örnek için, gelen sayi değerini doğrulayan bir tanım:

register_rest_route('sirket/v1', '/kare/(?P<sayi>\d+)', array(
  'methods'  => 'GET',
  'callback' => function ($req) {
    $n = (int) $req['sayi'];
    return array('sonuc' => $n * $n);
  },
  'permission_callback' => '__return_true',
));

Headless ve Mobil Uygulama Senaryoları#

REST API'nin en cazip kullanımı headless mimaridir: WordPress arka planda içerik yönetim sistemi olarak durur, ziyaretçinin gördüğü ön yüz ise ayrı bir teknolojiyle (React, Next.js, Vue, Astro ya da yerel bir mobil uygulama) yazılır. Bu modelde tasarım özgürlüğü artar, ön yüz statik olarak dağıtılabildiği için hız yükselir ve aynı içerik hem web hem mobil hem de üçüncü bir ekran için tek kaynaktan servis edilir.

Tipik bir headless akışı şöyle işler. Ön yüz uygulaması derleme (build) anında ya da ziyaret anında wp-json/wp/v2/posts uç noktasından içeriği çeker, kendi bileşenleriyle çizer. İçerik editörü panelde yazısını yayımladığında, bir webhook ön yüzün yeniden derlenmesini tetikler. Kaba mimari şöyle özetlenebilir:

kaynak:
  wordpress: icerik yonetimi + wp-json
on_yuz:
  cerceve: React / Next.js
  veri: build aninda wp-json'dan cekilir
dagitim:
  statik_html: CDN uzerinden servis
  yenileme: webhook ile tetiklenen build

Mobil uygulama senaryosunda ise uygulama, cihazdan doğrudan API'ye bağlanır; yazıları listeler, arama yapar, oturum açan kullanıcı için Application Password veya JWT ile yorum gönderme gibi işlemleri gerçekleştirir. Burada iki pratik tavsiye önemlidir: _fields ile yalnızca gereken alanları isteyip mobil veri tüketimini düşürün ve yanıtları istemci tarafında makul bir süre önbelleğe alın.

Headless mimaride WordPress'i çalıştıran sunucu artık son kullanıcıya HTML basmaz, yalnızca API'ye hizmet verir; bu yüzden çoğu zaman paylaşımlı bir WordPress hosting paketi rahatça yeter. Trafiğiniz büyüdükçe ya da özel PHP sürümü, ayrı önbellek katmanı, kendi Nginx kuralları gibi tam kontrole ihtiyaç duyduğunuzda bir sanal sunucu veya VDS çözümüne geçmek mantıklıdır. Ön yüzü statik dağıttığınız senaryoda bile API katmanını bir CDN veya WAF arkasına almak isteyebilirsiniz.

Güvenlik, Rate Limit ve Performans#

REST API kolaylık sağladığı kadar, kötü yönetilirse yeni bir saldırı yüzeyi de açar. İlk kural: yazma (POST/PUT/DELETE) işlemi yapan her uç noktada gerçek bir yetki denetimi olmalı. permission_callback içine güvenmeyin diye değil, mutlaka koyun diye söylüyoruz; boş bırakılmış bir callback herkese kapı açar. Application Password kullanıyorsanız yalnızca HTTPS üzerinden taşıyın ve her uygulamaya ayrı parola verin ki birini iptal etmek diğerlerini etkilemesin.

İkinci konu, bilgi sızıntısını sınırlamaktır. Varsayılan wp/v2/users uç noktası, kimlik doğrulaması olmadan bile yazar kullanıcı adlarını listeleyebilir; bu, kaba kuvvet (brute-force) saldırıları için isim listesi demektir. Kullanıcı numaralandırmasını (user enumeration) engellemek istiyorsanız bu uç noktayı yetkiyle sınırlayabilirsiniz:

add_filter('rest_endpoints', function ($endpoints) {
  if (isset($endpoints['/wp/v2/users'])) {
    unset($endpoints['/wp/v2/users']);
  }
  if (isset($endpoints['/wp/v2/users/(?P<id>[\\d]+)'])) {
    unset($endpoints['/wp/v2/users/(?P<id>[\\d]+)']);
  }
  return $endpoints;
});

Üçüncüsü, rate limit (hız sınırı). WordPress çekirdeği kendiliğinden istek sayısı sınırlaması yapmaz. API'nizi kötüye kullanımdan korumak için web sunucusu katmanında sınır koymak en sağlıklısıdır. Nginx kullanıyorsanız wp-json yoluna özel bir sınır tanımlayabilirsiniz:

# http bloğunda bir bölge tanımla
limit_req_zone $binary_remote_addr zone=wpapi:10m rate=30r/m;

server {
    location /wp-json/ {
        limit_req zone=wpapi burst=10 nodelay;
        try_files $uri $uri/ /index.php?$args;
    }
}

Bu yapı, tek bir IP'nin dakikada 30 isteğe kadar (kısa patlamalarda 10 fazladan) API'ye ulaşmasına izin verir, üstünü reddeder. Sunucu tarafında bu tür kuralları kendiniz yönetmek istemiyorsanız yönetilen bir sunucu yönetimi hizmeti ya da uygulama katmanı korumasını üstlenen bir web uygulama güvenlik duvarı devreye alabilirsiniz. Otomatik istismar denemelerine ve trafik taşkınlarına karşı DDoS koruma katmanı da API açık olan sitelerde ciddi fark yaratır.

Performans tarafında birkaç alışkanlık işleri hafifletir: _fields ile yükü küçültün, sık okunan GET yanıtlarını bir ters vekil (reverse proxy) ya da nesne önbelleğiyle önbelleğe alın, sayfalamayı per_page ve page ile disiplinli kullanın. Düzenli yedekleme almayı da unutmayın; API üzerinden toplu içerik değişikliği yapan bir betik hata yaparsa geri dönebileceğiniz bir kopya altın değerindedir.

Sıkça Sorulan Sorular#

WordPress REST API varsayılan olarak açık mı?#

Evet. WordPress 4.7 ve üzeri tüm kurulumlarda REST API çekirdeğe gömülü gelir ve varsayılan olarak etkindir. Herkese açık okuma uç noktalarına (yayımlanmış yazılar, sayfalar) ekstra bir ayar yapmadan erişebilirsiniz. Yazma ve gizli veri isteyen işlemler ise kimlik doğrulaması gerektirir. API'yi tamamen kapatmak yerine, hassas uç noktaları yetkiyle sınırlamak genellikle daha doğru bir yaklaşımdır.

wp-json adresim açılmıyor, ne yapmalıyım?#

En sık neden kalıcı bağlantı (permalink) ayarlarıdır. WordPress panelinde Ayarlar > Kalıcı Bağlantılar sayfasına girip herhangi bir değişiklik yapmadan kaydetmek çoğu zaman .htaccess veya yönlendirme kurallarını yeniler ve sorunu çözer. Bunun dışında bir güvenlik eklentisinin veya sunucu kuralının /wp-json/ yolunu engelliyor olması, yahut yönlendirme kurallarının hatalı olması gerekebilir. Sunucu hatalarını incelemek için hosting panelindeki hata kayıtlarına bakmak yön verir.

REST API ile XML-RPC arasındaki fark nedir?#

İkisi de WordPress'e dışarıdan program aracılığıyla bağlanmayı sağlar, ama REST API modern, JSON tabanlı ve HTTP metotlarını doğal kullanan bir yapıdır; XML-RPC ise daha eski, XML tabanlı ve tarihsel olarak kaba kuvvet saldırılarında sıkça hedef alınan bir arabirimdir. Yeni geliştirmeler için REST API tercih edilir. Kullanmadığınız takdirde XML-RPC'yi kapatmak, saldırı yüzeyini küçültmek adına yaygın bir güvenlik önlemidir.

API üzerinden gelen kimlik doğrulama güvenli mi?#

Güvenlik büyük ölçüde iki şeye bağlıdır: taşımanın şifreli olması ve yetki denetiminin doğru kurulması. Application Passwords yöntemi, asıl hesap parolanızı ifşa etmeden ayrı ve iptal edilebilir bir parola verdiği için pratik ve güvenlidir; ancak Basic Auth ile taşındığından mutlaka HTTPS üzerinde çalışmalıdır. Kendi yazdığınız uç noktalarda permission_callback ile gerçek bir yetki kontrolü yapmak, gelen parametreleri doğrulamak ve temizlemek de en az bağlantının şifreli olması kadar önemlidir.

Kendi eklentim için özel uç nokta yazmalı mıyım?#

Çekirdeğin sunduğu wp/v2 uç noktaları yazı, sayfa, kategori ve kullanıcı gibi standart veriyi zaten karşılar; bu ihtiyaçlar için tekrar bir şey yazmanıza gerek yoktur. Özel uç noktayı, standart yapıya sığmayan bir veriyi (kendi tablonuzdaki kayıtlar, birden çok kaynağı birleştiren bir yanıt ya da özel bir işlem) sunmanız gerektiğinde register_rest_route ile yazarsınız. Bu kodu tema yerine küçük bir eklentide veya mu-plugins klasöründe tutmak, tema değişikliklerinde kaybolmasını önler.

REST API sitemi yavaşlatır mı?#

API'nin kendisi normal koşullarda ölçülebilir bir yavaşlığa yol açmaz; asıl yük, sık ve verimsiz isteklerden gelir. Her istekte gereksiz alanları da çekmek, sayfalamayı büyük tutmak veya önbelleksiz çalışmak sunucuyu yorar. _fields ile yalnızca gereken alanları istemek, per_page değerini makul tutmak, sık okunan yanıtları önbelleğe almak ve web sunucusunda hız sınırı koymak performansı belirgin biçimde korur. Trafik yüksekse API katmanını güçlü bir barındırma planına taşımak da fark yaratır.

Kapanış#

WordPress REST API, siteyi bir "web sayfası"ndan bir "içerik platformu"na dönüştüren kapıdır. wp-json uç noktalarını gezmeyi, yazı ve sayfa verisini JSON olarak çekmeyi, Application Password ile güvenli kimlik doğrulamayı ve register_rest_route ile kendi uç noktanızı yazmayı öğrendiğinizde; headless bir ön yüzden mobil uygulamaya, otomasyon betiklerinden çoklu-kanal içerik dağıtımına kadar geniş bir alan açılır. Anahtar cümle şudur: kolaylığın bedeli, disiplinli güvenliktir. Yetki denetimini, HTTPS'i ve hız sınırını baştan doğru kurun.

Sağlam bir REST API deneyimi, sağlam bir altyapıyla başlar. Yeni bir proje kuruyorsanız hızlı ve WordPress'e ayarlı bir WordPress hosting paketiyle başlayabilir, tam kontrol istediğinizde bir sanal sunucu veya VDS çözümüne geçebilirsiniz. API açık bir siteyi kötüye kullanımdan korumak için WAF ve DDoS koruma katmanlarını, güvenli taşıma için SSL sertifikasını, olası hatalara karşı düzenli yedekleme hizmetini değerlendirin. WordPress kurulumunu henüz tamamlamadıysanız WordPress kurulumu rehberimizle başlayın; ihtiyacınıza en uygun altyapı için Clou.TR hosting ve sunucu planlarını incelemeniz yeterli.