Extension:Wikibase Repository/API4

This is an experimental API ver. 4 for Wikidata, with focus on the API for the Repo. Its only for the Repo-part for now.

Core concepts
The API should be simplified and try to mimic accessors as close as possibly, but due to some inherent problems we want to avoid making a bloat of modules.

There are some similarities we will try to build upon, that was not readily visible in the first versions. Due to this we will reorganize the API around some core concepts


 * There is a generic get items module that reads from some kind of slow but stable back store.
 * There is an optimized get attribute module that reads from some kind of fast but unstable front store. This is optimized for speed and returns single (?) key-value pairs. It could be necessary to handle failed lookups by checking the back store.
 * There is a change attribute module that sets single attribute within the item that is changeable and has a one-to-one relationship with languages. To set an attribute to an empty or non-existing value imply that it will be removed. This module accesses the stable back store.
 * There is a drop attributes module that removes multiple attributes within the item that is changeable and has a one-to-one relationship with languages. There can be given several attributes given at once. This module accesses the stable back store.
 * There is a search by name module that uses the unstable front store.

Typically the slow but stable back store is something like MySQL or PostgreSQL. Subsystems that needs to maintain high data integrity should use this one. The fast but unstable front store is something like Redis, CouchDB or MongoDB. Subsystems that can handle data with low integrity should use this one as it would be very much faster.

It is important to notice that the optimized get attribute module can return invalid key-value pairs. Because of this the code must be able to unwind exceptions due to fails induced by this, even if it would happen very seldom.

Some modules takes two arguments to specify an item, but as this pairing is difficult for a many-to-many relationship in the lookup one of them has to be one, forcing it into a one-to-many relationship in the call. For example will lookup with the combination of site and title only be possible if one of the arrays contain a single value.