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.
 * The SQL query must not filesort.
 * The value given to  must include all the columns in the   clause.
 * When continuing, a single compound condition should be added to the  clause. If the query has , this condition should look something like this:

(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;))

Of course, swap ">" for "<" if your  columns are using. Be sure to avoid SQL injection in the values.

Internal data structures

 * Query API has had very successful structure of one global nested  structure passed around. Various modules would add pieces of data to many different points of that array, until, finally, it would get rendered for the client by one of the printers (output modules). For the API, we suggest wrapping this array as a class with helper functions to append individual leaf nodes.

Error/status reporting
For now we decided to include error information inside the same structured output as normal result (option #2).

For the result, we may either use the standard HTTP error codes, or always return a properly formatted data:

void header( string reason_phrase [, bool replace [, int http_response_code]] ) The  can be used to set the return status of the operation. We can define all possible values of the, so for the failed login we may return   and  , whereas for any success we would simply return the response without altering the header.
 * Using HTTP code

Pros: It's a standard. The client always has to deal with HTTP errors, so using HTTP code for result would remove any separate error handling the client would have to perform. Since the client may request data in multiple formats, an invalid format parameter would still be properly handled, as it will simply be another http error code.

Cons: ...

This method would always return a properly formatted response object, but the error status/description will be the only values inside that object. This is similar to the way current Query API returns status codes.
 * Include error information inside a proper response

Pros: HTTP error codes are used only for the networking issues, not for the data (logical errors). We do not tied to the existing HTTP error codes.

Cons: If the data format parameter is not properly specified, what is the format of the output data? Application has to parse the object to know of an error (perf?). Error checking code will have to be on both the connection and data parsing levels.