API:Implementation Strategy

File/Module Structure

 * api.php is the entry point, located at the root of the mediawiki
 * includes/api will contain all files related to the api, but none of them will be allowed as entry points
 * All api classes are derived from a common abstract class ApiBase. The base class provides common functionality such as parameter parsing, profiling, and error handling.
 * ApiMain is the main class instantiated by api.php. It determines which module to execute based on action=XXX parameter. ApiMain also creates an instance of the ApiResult class (contains the output data array and related helper functions). Lastly, ApiMain instantiates the formatting claSs that will output the data from ApiResult in XML/JSON/PHP or other format to the client.
 * Any module derived from ApiBase will receive a reference to an instance of the ApiMain during instantiation, so that during execution the module may get shared resources such as the result object.

Query Modules

 * ApiQuery behaves similar to ApiMain in that it executes sub-modules. Each sub-module derives from ApiQueryBase (except ApiQuery itself that is a top-level module. During instantiation, sub modules receive a ref to an instance of the ApiQuery.
 * ApiQuery execution plan:
 * Get shared query parameters list/prop/meta to determine needed submodules.
 * Create an ApiPageSet object and populate it from titles/pageids/revids params. The pageset object contains the list of pages or revisions that query modules will work with. Please note that some modules require the pageset to contain only a single page.
 * if requested, a generator module is executed to create another PageSet - Similar to the piping streams in unix - given pages are the input to generator that produces another set of pages for all other modules to work on.

Internal Data Structures

 * Query API has had very successful structure of one global nested array 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, I 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 header can be used to set the return status of the operation. We can define all possible values of the reason_phrase, so for the failed login we may return code=403 and phrase="BadPassword", whereas for any success we would simply return the response without altering the header.
 * Using HTTP code

Pros: Its 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.