On 02/05/2013 10:53 AM, Brad Jorsch wrote: To me it is not clear why a Wikidata web API would be less controlled than a Wikidata Lua API with direct access to the DB. Slow operations will be slow, no matter how you call them. With a web API you at least get to parallelize and distribute the execution, so that you don't have to wait for a sequence of slow operations. Gabriel

On 02/06/2013 04:49 AM, Denny Vrandečić wrote: 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

* Chris Steipp wrote: (That's usually trivially addressed by, say, including a counter in some request header and refusing to serve requests where the recursion goes beyond some configured limit. And it is usually possible to do this at a very high level, so that should not be a major concern.) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

On 02/06/2013 10:49 AM, Chris Steipp wrote: Initially the use case will be providing access to the Wikidata API, not the MediaWiki API in general. A URL-style API can be opened up to provide access to some end points in the local MediaWiki API in the future if those are indeed safe, but I agree that we should be careful about this. Those local end points could also be handled as local method calls instead of actually performing an HTTP request. Agreed. If we started out restricted to the Wikidata API only, the initial effort to verify safety should be quite manageable though. Additional URL-based APIs would need to be vetted before being whitelisted, but would not require a new Lua API. Gabriel

On 02/06/2013 09:29 AM, Chris Steipp wrote: The supported API URLs can be restricted to straightforward JSON query APIs with a whitelist. If this whitelist initially only contains wikidata, the effect would be the same as using a specialized Wikidata API. Gabriel

On 02/06/2013 11:43 AM, Brad Jorsch wrote: I don't know much Lua, but a function call like this does not seem to be *that* hard to use: -- Would fetch JSON from -- http://wikidata.org/api/query/?param1=foo&param2=bar -- if no local handler is defined and the base URL is in a whitelist jsonObject = JSONRequest("http://wikidata.org/api/query/"ery/", { param1="foo", param2="bar" } ) No manual encoding, and URL encoding can be completely skipped if the prefix happens to match a registered local handler. An optional third parameter can pass in a table to specify the request method and other options. Gabriel

On 02/06/2013 01:30 PM, Brad Jorsch wrote: If a whitelist is enforced, then giving this URL a symbolic name looks like a solvable problem. Alternatively, each configured API end point could be a generic object with a request method: jsonData = JSONAPI.wikidata.request({ param1="foo", param2="bar" }) Right. Can you describe why you would want to pass JSON into a method that requests JSON data from an API? Gabriel