On 02/06/2013 04:49 AM, Denny Vrandečić wrote:
There will be (actually, there is already) a web API
offering the kind of
data required, and for client wikis not running on WMF infrastructure this
will eventually be the way to access the data.
For WMF clients, like the Wikipedias, our decision was not to use HTTP web
requests, but to internally get the data directly from the respective DB.
This was deemed the deciding factor wrt performance: internal DB queries vs
HTTP requests.
Local HTTP requests have pretty low overhead (1-2ms), but api.php
suffers from high start-up costs (35-40ms). This is more an issue with
api.php and the PHP execution model than with HTTP though, and might be
improved in the future.
It should be possible to hide optimization details like local DB access
vs. an actual HTTP request behind the same interface. A URL-based query
interface can support local handlers for specific URL prefixes. Decoding
a URL is pretty cheap, and the logic for mapping it onto local DB
queries likely already exists to support the web API. The URL-based
interface would allow users to learn a single, simple JSON interface and
use it to access multiple (possibly whitelisted) data sources.
Wikidata-using Lua modules would be reusable in another wiki independent
of local vs. remote access or software version.
Alternatively, a specialized Lua Wikidata API could be mapped to the web
API behind the scenes to support both local and remote access to
Wikidata. Care would be needed in the design of the interface to make
this possible, and little existing code could be reused. New Wikidata
features would only become available to clients after upgrading their
Lua bindings.
I believe that we should try to keep the our public APIs small and
versatile, both for the benefit of users and developers. Maybe there is
a reason why URLs are too simple as an interface for Wikidata, but I am
not so sure about that yet.
Gabriel