On Thu, Aug 21, 2008 at 6:03 PM, Jay R. Ashworth jra@baylink.com wrote:
As soon as I read this, i realize that indeed, you guys are talking about "an implementation of an interface to the API", not the actual thing itself.
An API, by definition, is a declared set of call and response interfaces to a block of core code, with defined parameter domains and ranges.
It's not the interfaces you use to *get* to that, be it HTML, REST, or whosoever...
When we say "API" we mean "bot API", i.e., "a web-based API provided for third parties to read data from (and possibly write data to) the wiki in a programmatic fashion, either anonymously or via a user account". This is in context to the human UI, which is meant to provide the same functions but to humans, not computer programs. This is how the term is often used in web contexts these days.
We do *not* mean a programming API, i.e., a set of classes, methods, and functions that MediaWiki itself and its extensions can call. That's what we often call the "backend". api.php uses the backend, as do the usual index.php and other human access methods.
The issue is that historically, the only access to the backend was through the human UI, or via extensions (but those can always hack things up by running queries directly and so on). Therefore there was a lot of careless mixing of UI and backend code. The existence of the bot API is forcing some of this mixing to be fixed, which incidentally improves things for extensions too. So the API is incidentally related to separation of interface logic from business logic -- but the API itself is supposed to only contain interface logic, for remote bot access.