Gizli JSON API sitesi: uç noktaları nasıl bulabilirsiniz (2026)

Parser, 8 KB'lik JSON yanıtında sitenin kendisine verdiği sekiz alan için 400 KB HTML çekiyor. Elli kat fark, "güzel kod" ile ilgili değil, her gigabayt için ödeme yaptığınız konut proxy'leri için fatura ile ilgili. İçsel API'yi nasıl bulacağımızı, 2026'da bunun tekrarlanmasını neyin engellediğini ve bu fikirden ne zaman vazgeçmeniz gerektiğini inceleyelim.

HTML zaten ayrıştırılıyorsa neden gizli API arayalım?

Modern arayüzlerin neredeyse tamamı - React, Vue, Angular, Next.js - önce sayfanın iskeletini yükler, ardından verileri kendi uç noktalarına ayrı isteklerle çeker. Bu uç noktalar belgelenmemiştir, ancak varlar, temiz JSON yanıtları verirler ve headless tarayıcı olmadan erişilebilirler.

Onlara geçtiğinizde ne elde edersiniz:

Trafik bir düzine düşer. Tipik bir ürün listesinin ayrıştırılmasında HTML sayfası, biçimlendirme, stiller ve izleyicilerle birlikte yaklaşık 400 KB ağırlığındayken, ilgili JSON uç noktası yaklaşık 8 KB'dir ve içinde daha fazla alan vardır: içsel ID'ler, stoklar, ürün varyantları.
Tarayıcıya gerek yok. JavaScript'in render edilmesi ortadan kalkar, bu da bellek, işlemci ve yazı tipleri ile analiz için yapılan onlarca ek isteği ortadan kaldırır.
Veriler zaten yapılandırılmıştır. CSS sınıfı değiştiğinde bozulan herhangi bir seçici yoktur.
Daha az istek - daha az yasaklanma nedeni. Bir katalog sayfasının tarayıcıda çizimi, siteye onlarca başvuru gerektirir; aynı veri miktarı API üzerinden bir istekte bulunarak elde edilir.

Konut proxy'leri için bu doğrudan bir tasarruftur: tarifeler gigabayt başına hesaplanır ve render'dan JSON'a geçiş genellikle faturayı, resimlerin engellenmesi gibi herhangi bir hileden daha fazla sıkıştırır. İlgili bir konu - diğer yöntemlerle parser trafiğini 5 kat azaltma.

Aşama aşama: uç noktayı nasıl bulursunuz

Öncelikle resmi bir API olup olmadığını kontrol edin. Hedef sitenin /developers, /api, /docs sayfalarına göz atın. Kamuya açık belgelenmiş API sürümlendirilir ve depreke uyarısı yapar - özel API sessizce değişir.
DevTools'u açın (F12) ve Ağ sekmesine gidin, kaydın açık olduğundan emin olun.
Fetch/XHR filtresini etkinleştirin. Bu, resimleri, yazı tiplerini ve analizleri keserek yalnızca veri taleplerini bırakır.
Listeyi temizleyin, böylece ilk yükleme gürültüsünü ortadan kaldırın.
Gerekli verileri tetikleyin: listeyi kaydırın, "sonraki sayfa"ya tıklayın, filtre uygulayın, kartı açın. İlgilendiğiniz istek, eylem anında görünecektir.
Verilerinizi içeren yanıtı bulun. En hızlı yol, Ağ panelinde Ctrl+F kullanmaktır: ekranda gördüğünüz benzersiz değeri (ürün kodu, tam fiyat, isim parçası) arayın ve hangi isteğin onu ürettiğine bakın.
İsteği tamamen kopyalayın: satıra sağ tıklayın → Kopyala → cURL olarak Kopyala. Sonra, başlıkları kaybetmemek için curlconverter ile kodu dönüştürün.

İlk olarak bakılması gereken karakteristik yollar: /api/, /v1/, /v2/, /search, /products, /listings, /graphql.

Özel durum: Next.js ile siteler

Burada veriler genellikle ayrı bir isteğe gerek duymadan doğrudan HTML'de bulunur. Eski Pages Router'da bu __NEXT_DATA__ bloğudur. App Router'da (Next.js 13 ve sonrası) hidrate edilme verileri birkaç script düğümünde self.__next_f.push() çağrılarıyla dağıtılmıştır - bu, React Server Components'ın serileştirilmiş yüküdür. Bunu elle çözmek hoş değildir: parçalar birbirine $-önekleriyle atıfta bulunur ve dize ortasında kesilebilir. Python için, HTML'den Flight yükünü ve ham RSC yanıtını ayrıştıran nextflight adlı bir kütüphane vardır ve içinde anahtar isimlerine göre arama yapmayı önerir, bu da parser'ın siteyi yeniden dağıtırken hayatta kalmasını sağlar.

Parametrelerin tersine çevrilmesi: sayfalama ve filtreler

Bulunan uç nokta neredeyse her zaman parametreli olur. Üç şema ile karşılaşabilirsiniz:

Sayfalara göre: ?page=3&per_page=20
Kaydırma ve limit: ?offset=40&limit=20
Kursör: ?after=<token>&limit=20 - sonraki sayfanın token'i önceki yanıtın gövdesinde gelir

Üç kural, saatlerce hata ayıklamayı tasarruf ettirir:

Önceden hesaplanmış sayfa sayısına değil, boş bir pakete odaklanın: özel API'lerde total sayacı çoğu zaman yanıltıcıdır.
Gerçek paket boyutunu kontrol edin. 100 talep ettiniz, 20 geldi - bu, uç noktanın kendi tavanı olduğu anlamına gelir ve sayfa başına aritmetiğiniz artık yanlıştır.
500. sayfaya girmeyin. Derin sayfalama neredeyse her yerde sunucu tarafından kesilir; bunun yerine filtrelerle seçim yapın - kategoriye göre, fiyat aralığına göre, tarihe göre.

Neden cURL tarayıcıdan çalışıyor, ama kodunuz çalışmıyor

Bu en yaygın başarısızlık noktasıdır ve neden genellikle aynıdır: kaybedilen başlık. Kopyalanan cURL, isteğin tüm bağlamını taşırken, kendi yazdığınız istemci bunu yapmaz.

Genellikle zorunlu olanlar:

X- öneki ile özel başlıklar - X-CSRF-Token, X-Requested-With: XMLHttpRequest ve frontend'in kendiliğinden eklediği her türlü X-*-Token. Bunlar olmadan 400-500 aralığında bir yanıt alırsınız.
Referer - kullanıcının eylemiyle oluşturulan bağlamsal başlık. Birçok uç nokta, isteğin "kendi sayfasından geldiğini" kontrol eder.
Authorization: Bearer <JWT> - genellikle 15-60 dakika süren kısa ömürlü bir token. Bunu sabit kodlamak anlamsızdır: yeni bir tane almak gerekir.
Oturum çerezleri - bunları oturum nesnesinde tutun, elle kopyalamayın.
POST için doğru Content-Type: application/json ve application/x-www-form-urlencoded gövdeyi farklı şekilde kodlar ve ilan edilen türle uyuşmazlık, isteği sessizce bozar.

Token'ları nerede bulacağınızı, eğer çerezlerde yoksa: HTML kaynak kodunda <script> içinde (bilinen bir değerle Ctrl+F ile arama yaparak), JavaScript paketlerinde, localStorage veya IndexedDB'de - DevTools'taki Uygulama sekmesinde.

Geç öğrenilen tuzaklar

Özel API, önceden haber vermeden değişir. Sürümlendirme, uyumluluk vaatleri ve destek yoktur: frontend ekibi bir alanı Perşembe akşamı yeniden adlandırır ve parser'ınız boşluk toplar. Koruma, "güvenilir seçici" değil, yapı kontrolüdür: zorunlu alanların yerinde ve doğru türde olduğundan emin olun; boş değerlerin oranını ve geçişteki kayıt sayısını izleyin; bozuk kayıtları atlayın, ancak hata oranı %10'u geçtiğinde alarm verin; ham yanıtları saklayın, böylece karşılaştıracak bir şeyiniz olur.

API bazen sayfadan daha sıkı korunur. Bu düzenli olarak karşılaşılır: HTML rahatça verilirken, /api/ üzerinde, TLS parmak izi ve başlık kombinasyonunu kontrol eden bir anti-bot bulunur. Bu durumda, trafik tasarrufu, başarısız isteklerin oranını artırır ve kazanım kaybolur.

İmzalı istekler. Parametrelerde sign, hash veya _s gibi bir şey görünüyorsa, frontend imzayı JavaScript'te hesaplar. Bunu yeniden üretmek ayrı bir projedir ve genellikle HTML'de kalmak daha ucuzdur.

Sıklık sınırlamaları. Özel uç noktalar akış için tasarlanmamıştır: saniyede 1-2 istek tutun, bağlantı ve okuma için ayrı zaman aşımı ayarlayın (örneğin, 5 ve 30 saniye), yalnızca geçici hataları - 429, 500, 502, 503, 504 - tekrarlayın ve 401 ve 404 ile oynamayın. Jitter ile birlikte üstel gecikme zorunludur, aksi takdirde tüm işçiler aynı anda ikinci tura geçer. Daha fazla bilgi için proxy için zaman aşımı ve yeniden deneme mantığı incelemesine bakın.

Hukuki çerçeve. Kamuya açık kimlik doğrulamasız uç noktalar bir durumdur, ancak bir hesaba giriş yapmak tamamen farklı bir durumdur: kayıt, kullanıcı sözleşmesini kabul etmek anlamına gelir. Kişisel veriler, ne kadar kolay elde ediliyor olursa olsun, GDPR'ye tabidir. Gerçekler - fiyatlar, özellikler, mevcutlık - telif hakkıyla korunmaz, metinler ve görüntüler dışında.

HTML'de kalmanın zamanı ne zaman

Gizli API her zaman kazanç sağlamaz. Aşağıdaki durumlarda sayfa ayrıştırması yapmaya devam edin:

site sunucu taraflıdır ve hiçbir iç API yoktur;
uç nokta imza veya token döngüsü gerektiriyorsa - bunu sürdürmek sayfadan daha pahalıdır;
API, kamuya açık sayfalardan daha kötü bir korumaya sahipse;
tam olarak frontend'in birkaç kaynaktan topladığı nihai sonuca ihtiyacınız varsa;
onlarca siteyi yönetiyorsanız: tek bir HTML hattı, özel tuhaflıkları olan özel API'lerden daha iyi ölçeklenir.

API ayrıştırma için hangi tür proxy alınmalı

JSON'a geçiş, hesaplamayı değiştirir çünkü dar alan kayması olur: trafik azalır, IP kalitesi ve oturum istikrarı talepleri artar.

Yetkilendirme ve anti-botsuz açık uç nokta. Burada yeterli veri merkezi proxy'leri: veri miktarı küçük, konut proxy'leri için ödeme yapmaya gerek yok.
Anti-bot arkasındaki veya oturumla bağlı uç nokta. Yapışkan oturum ile konut proxy'lerine ihtiyacınız var: token, çerez ve IP, zincirin tamamında eşleşmelidir, aksi takdirde sunucu ikinci istekte oturumu sıfırlar. Bu durumda fatura mütevazı kalır - JSON modunda gigabaytlar yavaşça tüketilir.
Mobil uygulamadan veri. Eğer web versiyonu kapalıysa ve uygulama aynı verileri daha basit bir şekilde veriyorsa, uç noktalar trafik yakalama ile bulunur - bu, mobil uygulamanın gizli API'sini mitmproxy ile bulma makalesinde ele alınan ayrı bir prosedürdür.

Kısa

DevTools'ta yirmi dakika, genellikle headless tarayıcı ile geçen günleri değiştirebilir: Fetch/XHR filtresi, görünür değere göre arama, cURL olarak Kopyala - ve elinizde çalışan bir istek var. Sonra detaylar çözülür: tüm başlıkları taşımak, sayfalama şemasını çözmek, yanıt doğrulaması koymak ve uç noktanın sayfadan daha kötü korunup korunmadığını makul bir şekilde değerlendirmek. Özel API'nin çalıştığı yerlerde, hem trafik hacmini hem de istek sayısını azaltır - yani hem proxy maliyetini hem de yasaklanma olasılığını aynı anda düşürür.