API:Implementation Strategy/tr

Bu, MediaWiki API makinesinin temelde uygulanmasını açıklar. Kodunuzda istemcilerin kullanması için bir API sağlamak istiyorsanız, sayfasını okuyun.



Dosya/Modül Yapısı

 * , viki kökünde bulunan giriş noktasıdır. API:Anasayfa#Uç nokta bölümüne bakın.
 * , API ile ilgili tüm dosyaları içerecek, ancak hiçbirinin giriş noktası olarak kullanılmasına izin verilmeyecektir.
 * Tüm API sınıfları ortak bir soyut sınıf  üzerinden türetilmiştir. Temel sınıf, parametre ayrıştırma, profil oluşturma ve hata işleme gibi ortak işlevler sağlar.
 * ,  tarafından başlatılan ana sınıftır.   parametresine göre hangi modülün çalıştırılacağını belirler.   ayrıca, çıkışı verisi dizisini ve ilgili yardımcı işlevleri içeren   sınıfının bir örneğini oluşturur. Son olarak, , veriyi   üzerinden XML/JSON/PHP veya başka bir biçimde istemciye çıkaracak biçimlendirme sınıfını başlatır.
 * üzerinden türetilen herhangi bir modül, örnekleme sırasında  bir örneğine bir kaynak alır, böylece modül yürütme sırasında sonuç nesnesi gibi paylaşılan kaynakları alabilir.



Sorgu modülleri

 * , alt modülleri yürüttüğü için  ile benzer davranır. Her bir alt modül,   üzerinden türetilir (üst düzey bir modül olan   kendisi hariç). Örnekleme sırasında, alt modüller ApiQuery örneğine bir kaynak alır.
 * Tüm uzantı sorgu modülleri 3 veya daha fazla harfli önek kullanmalıdır. Çekirdek modüller 2 harfli ön ek kullanır.
 * yürütme planı:
 * Gerekli alt modülleri belirlemek için paylaşılan  sorgu parametrelerini alın.
 * Bir  nesnesi oluşturun ve onu   parametrelerinden doldurun.   nesnesi, sorgu modüllerinin birlikte çalışacağı sayfaların veya revizyonların listesini içerir.
 * İstenirse, başka bir  oluşturmak için bir oluşturucu modülü çalıştırılır. UNIX'teki boru akışlarına benzer. Verilen sayfalar, diğer tüm modüllerin üzerinde çalışması için başka bir sayfa kümesi üreten oluşturucu girdisidir.
 * Sorgu devam ettirme gereksinimleri:
 * SQL sorgusu tamamen sıralanmalıdır. Başka bir deyişle, sorgu,  yan tümcesinde veya   yan tümcelerinde sabitler olarak bazı benzersiz anahtarların tüm sütunlarını kullanıyor olmalıdır.
 * MySQL'de bu bir özel veya, Foo ve Bar sorgulamalarının başlığa göre sıralanması gerektiği, ancak ad alanına göre sıralanmaması gereken (ad alanı 0 sabittir), Foo ve Talk:Foo ad alanına göre sıralanmalı ancak başlığa göre sıralanmamalıdır (başlık sabit "Foo") ve Foo ve Talk:Bar hem ad alanına hem de başlığa göre sıralanmalıdır.
 * SQL sorgusu dosya sıralaması yapmamalıdır.
 * ile verilen değer,  yan tümcesindeki tüm sütunları içermelidir.
 * Devam ederken,  cümlesine tek bir bileşik koşul eklenmelidir. Sorguda   varsa, bu koşul aşağıdaki gibi görünmelidir:

(column_0 > value_0 OR (column_0 = value_0 AND&#xa; (column_1 > value_1 OR (column_1 = value_1 AND&#xa; (column_2 >= value_2)&#xa; ))&#xa;))

Tabii ki,  sütunlarınız   kullanıyorsa "<" için ">" değiştirin. Değerlerde SQL enjeksiyonundan kaçındığınızdan emin olun.



Dahili veri yapıları

 * Sorgu API'si, çok başarılı bir küresel iç içe geçmiş  yapısına sahipti. Çeşitli modüller, son olarak, yazıcılardan biri (çıkış modülleri) tarafından istemci için işlenene kadar, bu dizinin birçok farklı noktasına veri parçaları ekleyecektir. API için, bu diziyi tek tek yaprak düğümleri eklemek üzere yardımcı işlevlere sahip bir sınıf olarak sarmalamanızı öneririz.



Hata/durum raporlama
Şimdilik hata bilgilerini normal sonuç olarak aynı yapılandırılmış çıkışının içine dahil etmeye karar verdik (seçenek #2).

Sonuç olarak, standart HTTP hata kodlarını kullanabiliriz veya her zaman uygun şekilde biçimlendirilmiş bir veri döndürebiliriz:

void header( string reason_phrase [, bool replace [, int http_response_code]] ) , işlemin döndürme durumunu ayarlamak için kullanılabilir. tüm olası değerlerini tanımlayabiliriz, bu nedenle başarısız oturum açma için  ve   döndürebiliriz, oysa herhangi bir başarı için başlığı değiştirmeden basitçe yanıtı döndürürdük.
 * HTTP kodunu kullanma

Artılar: Bu bir standart. İstemci her zaman HTTP hatalarıyla uğraşmak zorundadır, bu nedenle sonuç için HTTP kodunu kullanmak, istemcinin gerçekleştirmesi gereken ayrı bir hata işlemeyi ortadan kaldırır. İstemci birden fazla biçimde veri talep edebileceğinden, geçersiz bir format parametresi yine de düzgün bir şekilde ele alınacaktır, çünkü bu yalnızca başka bir http hata kodu olacaktır.

Eksiler: ...

Bu yöntem her zaman uygun şekilde biçimlendirilmiş bir yanıt nesnesi döndürür, ancak hata durumu/açıklaması bu nesnenin içindeki tek değerler olacaktır. Bu, mevcut Sorgu API'nin durum kodlarını döndürme şekline benzer.
 * Hata bilgilerini uygun bir yanıtın içine ekleyin

Artılar: HTTP hata kodları, veriler (mantıksal hatalar) için değil, yalnızca ağ oluşturma sorunları için kullanılır. Mevcut HTTP hata kodlarına bağlı değiliz.

Eksiler: Veri format parametresi doğru şekilde belirtilmezse, çıkış verilerinin biçimi nedir? Uygulama, bir hatayı bilmesi için nesneyi ayrıştırmalıdır (perf?). Hata kontrol kodunun hem bağlantı hem de veri ayrıştırma seviyelerinde olması gerekir.

