Zaman Tabanlı Filtreleme Stratejileri
Zaman aralığını from ve to ile UTC takviminde YYYY-MM-DD biçiminde belirtin. to günü dahildir. Örneğin from=2020-05-01 ve to=2020-05-31 yalnızca tarih biçimini açıklayan bir aralıktır; o dönemde kayıt bulunduğu iddiası değildir. Sonraki pencereyi 2020-06-01 ile başlatmak gün sınırını tekrar kullanmayı önler. API bu filtrelerle saat veya dakika düzeyinde başlangıç ve bitiş seçimi sunmaz. Analiziniz yerel saate dayanıyorsa UTC günlerine nasıl eşlediğinizi not edin.
Tarih filtreleri sonuç kümesini daraltır, sıralamayı değiştirmez. Sonuçlar arşiv belge sırasındadır; kronolojik, ilgililik veya puan sırası değildir. Her dönem için alınan yanıtı ve tam parametreleri saklayın. İyi kurulmuş sayfalama veya birbirini izleyen gün aralıkları, bütün eşleşmelerin alınacağını veya yinelenen kayıt bulunmayacağını kanıtlamaz. Aynı sorgunun ileride aynı kayıtları vermesi de garanti edilmez; tekrarlanabilir yerel analiz için gerçekten alınan girdiyi koruyun.
İlk küçük örnek https://api.redditpostsapi.com/v1/posts?subreddit=photography&min_score=10&limit=3 adresidir. Bu örnek topluluk, puan eşiği ve miktarı açıklar; fotoğraf ekipmanıyla ilgili üç tartışma bulunduğunu göstermez. Ekipmanla ilgili kayıtları metin mevcutsa okuyarak yerel olarak ayırın. Eksik veya alakasız satırlar için dışlama nedenini yazın. min_score bir içerik kalitesi, ürün önerisi veya topluluğun ortak görüşü ölçüsü değildir.
Veri Yapısı ve Etkileşim Analizi
Yanıtlar düz kayıtlardır; sunucu birleştirilmiş konuşma ağaçları üretmez. parent_id veya link_id alanları varsa yerel ilişkilendirme yapılabilir, ancak bunlar sorgu filtreleri değildir. Eksik üst kayıtlar nedeniyle tam bağlam oluşmayabilir. Alıntıları olmayan ilişkilere göre tamamlamayın. Varsa tarih alanlarını kontrol edip yerel sıralama yapabilirsiniz; yerel sıralama yalnızca aldığınız alt kümeyi düzenler ve eksik kayıtları tamamlamaz.
Analistler, geri dönüşleri yerel olarak birleştirdiklerinde bile tam bir üst kayıt zincirinin garanti edilmediğini bilmelidir. Sadece ilgili filtreler mevcuttur ve sunucu tarafından ekstra filtreleme yapılmaz. Bu durum, özellikle karmaşık diyalog zincirlerini analiz eden uzmanlar için ek veri işleme adımları gerektirir. Doğru bağlamı kurmak için istemci tarafındaki mantık çok önemlidir.
Kimlik gereksinimleri farklı uç noktalar arasında değişir. Örneğin, belirli bir öğeyi getirmek için ID gereklidirken, gönderi veya yorum listelerinde bu zorunlu değildir. Bu farklılık, verilerin nasıl çekileceği konusunda analistlerin dikkat etmesi gereken bir detaydır. Yanlış parametre kullanımı beklenmeyen sonuçlara veya hata kodlarına yol açabilir ve verimliliği düşürür.
İstek ve Sorgu Sınırları
Her istekte en fazla 100 kayıt ve sorguda en fazla 100 sayfa istenebilir. Yanıtı kaydettikten sonra yerel ilerleme durumunu güncelleyin. eq kesin toplamı, gte alt sınırı, unknown güvenilir toplamın bilinmediğini gösterir; toplam null olabilir. Bunlar sayfa sayısı değil, eşleşen kayıt toplamlarıdır. Kesin toplam dahi bütün sonuçların istemcide kaydedildiğini kanıtlamaz. Gün aralığını bölmek, tam arşiv toplama yöntemi olarak sunulmamalıdır.
Veri çekmek için Authorization: Bearer YOUR_API_KEY veya X-API-Key: YOUR_API_KEY geçerlidir. HTTP 400 için parametreleri, 401 için anahtarı, 402 için bakiyeyi kontrol edin; 429 durumunda bekleyin. Geçersiz istekler kredi düşürmez, kaynak hatası rezervi iade eder, başarılı boş sonuç ücretlidir. İstemci yanıtı kaybetse bile ücretli başarı gerçekleşmiş olabilir; başarılı tekrarın maliyetini fiyatlandırma sayfasıyla bütçelendirin. /v1/status arama sağlığını kontrol etmez.
Anahtarlar ve bakiyeler kiracı özgüdür ve ağ genelinde paylaşılmaz. Bu, farklı oturumların veya hesapların birbirinden bağımsız çalıştığını gösterir. Deneme kredileri ve ödemeler kiracı bazında izlenir. Analistlerin, yüksek hacimli veri çekme işlemlerinde bu sınırlamaları göz önünde bulundurarak istek sıklığını ayarlaması gerekir. Bu sayede hem maliyet hem de verimlilik optimize edilebilir.
