Wikibase/API

Other versions API1, API2, API3, API4.

Wikibase API for the repo part, that is the part running on the central database with its database. There is a separate API for the clients, or in Wikidata lingo the attached wiki sites. There can be browsers connected to both the repo and the clients.

Requests to the repo API that changes content should use token, be aware of rights, use POST or GET requests according to mode (use POST to avoid problem with non-behaving proxies), and be aware of and handle errors from the API.

Modules
There are some parameters that is always available...

Plural forms are used in those cases where a parameter can take several values.


 * id|ids : Identifies a specific item or items.
 * site|sites ∩ title|titles : Identifies a single item or multiple items. Both sites and titles can't have multiple values at the same time.
 * language : The language is used as a filter mechanism to filter labels and descriptions in get actions or to identify a specific language for set actions.
 * format : Should always be set to json (or jsonfm for debygging)

Normally the return value either has a success key with a boolean cast as an integer or an error key with an object of two, optionally three, keys code, info and "*". The last one is additional information. Information about the action is either passed on the top level or under item if its one single item or items if its several. If it is several items each is found under a key with its own item id.

Note that empty objects are returned as arrays and not as objects.

wbgetitemid
getItemId( site, title )
 * Example : http://localhost/repo/api.php?action=wbgetitemid&title=Wikimedia&site=nn&format=jsonfm
 * Returns the found structure on a short form

{ 	"item": { "id": "44" }, 	"success": 1 }

wblinksite
linkSite( ( id XOR ( site, title ) ), linksite, linktitle, link, *badge, *summary) link is one of update|add|set|remove. { 	"success": 1, "item": { "id": 47 } }
 * Example : http://localhost/repo/api.php?action=wblinksite&site=no&title=Foo&linksite=no&linktitle=Mickepedia&format=jsonfm&link=set
 * Returns the identifier for the found site after update

{ 	"success": 1, "item": { "id": 47 } }
 * Example : http://localhost/repo/api.php?action=wblinksite&id=47&linksite=no&linktitle=Foo&format=jsonfm&link=set
 * Returns the identifier for the found site after update

Note that adding multiple links to a single external page will result in a database error and a previously stored erroneous structure on the page wil keep on triggering the database error. { 	"error": { "code": "internal_api_error_DBQueryError", "info": "Exception Caught: A database error has occurred. ...", "*": "\n\n#0 \/home\/john\/Workspace\/core\/includes\/db\/Database.php(904): DatabaseBase->reportQueryError('Duplicate entry...'" 	} }

wbsetlanguageattribute
setLanguageAttribute(id XOR (site, title), (label OR description), attribute, *summary) attribute is one of update|add|set.
 * "update" throws an error if no value exists
 * "add" will throw an error if the value already exists
 * "set" always works
 * Example : http://localhost/repo/api.php?action=wbsetlanguageattribute&id=52&language=sv&label=Neverland&format=jsonfm&item=set
 * Returns the identifier for the changed item

{ 	"success": 1, "item": { "id": 52 } }

{ 	"success": 1, "item": { "id": 52 } }
 * Example : http://localhost/repo/api.php?action=wbsetlanguageattribute&id=52&language=sv&description=Place%20where%20Alice%20lived%20for%20a%20short%20time&format=jsonfm&item=set

wbdeletelanguageattribute
Skeleton file, lacks the actual deletion and also isn't fully tested. deleteLanguageAttribute(id XOR (site, title), attribute, *summary)

wbgetsitelinks
getSiteLinks( ( id XOR ( site, title ) )
 * Example : http://localhost/repo/api.php?action=wbgetsitelinks&id=46&format=jsonfm
 * Returns the found structure

{ 	"item": { "id": 46, "sitelinks": { "sv": "Mediawiki", "no": "Mediawiki" } 	}, 	"success": 1 }


 * Example : http://localhost/repo/api.php?action=wbgetsitelinks&site=no&title=Mediawiki&format=jsonfm
 * Returns the found structure

{ 	"item": { "id": "46", "sitelinks": { "sv": "Mediawiki", "no": "Mediawiki" } 	}, 	"success": 1 }

Note that it seems like some structures can't be found, and it seems like this correlates with previous errors from the database about conflicting ids.

wbgetitems
getItems( ( ids XOR ( sites, titles )) ), *language)
 * Example : http://localhost/repo/api.php?action=wbgetitems&ids=46&format=jsonfm
 * Returns the found structure

{ 	"items": { "46": { 			"id": 46, "sitelinks": [ ], 			"descriptions": [ ], 			"labels": { "de": "de-value", "en": "en-value" } 		} 	}, 	"success": 1 }


 * Example : http://localhost/repo/api.php?action=wbgetitems&sites=nn&titles=Mediawiki&format=jsonfm

Note that naming deviates slightly from the proposed one getItems( ( ListOfIds XOR ( ListOfSites, ListOfTitles )) ), *language)

wbsetitem
getItems( data )
 * Example : http://localhost/repo/api.php?action=wbsetitem&data={}&format=jsonfm
 * Builds a structure like this (it returns the created structure)

{ 	"item": { "id": 49, // this is item that is automatically added "sitelinks": [ // note that there is an array here as it is an empty object ], 		"descriptions": [ // note that there is an array here as it is an empty object ], 		"labels": [ // note that there is an array here as it is an empty object ] 	}, 	"success": 1 }

{ 	"item": { "id": 50, // this is item that is automatically added "sitelinks": [ // note that there is an array here as it is an empty object ], 		"descriptions": [ // note that there is an array here as it is an empty object ], 		"labels": { "de": "de-value", "en": "en-value" } 	}, 	"success": 1 }
 * Example : http://localhost/repo/api.php?action=wbsetitem&data={%22label%22:{%22de%22:{%22language%22:%22de%22,%22value%22:%22de-value%22},%22en%22:{%22language%22:%22en%22,%22value%22:%22en-value%22}}}&format=jsonfm

wbsetalias
setAliases(id XOR (site, title), (add OR remove) XOR set, *summary) ''This call is somewhat confusing and is at present implemented as  where site and title double as linksite and linktitle. This is probably wrong. It should be local calls, somewhat a type of local redirect. This is not implemented for the moment.''
 * Example : http://localhost/repo/api.php?action=wbsetalias&id=44&language=en&site=nn&title=Wikimedia&summary=World%20domination%20will%20be%20mine%20soon!&format=jsonfm

wbsearchbyname (partly)
This call is only partly implemented as it is not clear how the search should be done. searchByName(language, fragment, *hints)

Token
All call to content changing API functions should be developed for (and prepared to) use the token. That includes Wikidata items and other associated pages. For the moment only one token is in use. Such tokens must be acquired before any operations that needs them are accessed or the operation will fail.

If the API is in debug mode, that is by setting apiInDebug to true, the use of tokens will be disabled. It is reenabled by setting apiDebugWithTokens to true. A production environment ''should' not disable use of tokens.

Tokens are in ver. 0.1 acquired by a request to wbsetitem with gettoken in the URL
 * example : http://localhost/repo/api.php?action=wbsetitem&gettoken&format=jsonfm

After the reply comes back the token named setitemtoken is the one that is used for all later requests. { 	"wbsetitem": { "setitemtoken": "a462a54d500848fa53a808fc26478dd4+\\" } }

The current implementation is implemented as a API only solution, and the mw.user.tokens list is not populated with additional elements. See also subsection tokens in default modules.

Note that as default the API will require POST requests.

Rights
All call to content changing API functions should be developed for (and prepared to) use rights. That includes errors due to insufficient access rights. That imply that it could be necessary to be logged in before content can be changed. The basic access rights write rights is in addition to the permissions.

If the API is in debug mode, that is by setting apiInDebug to true, the use of rights will be disabled. It is reenabled by setting apiDebugWithRights to true. A production environment should not disable use of rights.

Rights are named as "module-operation" and added to a group wbeditor. This could be reorganized into other groups or be divided as more fine grained rights or reorganized in other ways. The module name is shortened to make them more manageable.

$wgGroupPermissions['wbeditor']['item-add']         = true; $wgGroupPermissions['wbeditor']['item-update']      = true; $wgGroupPermissions['wbeditor']['item-set']         = true; $wgGroupPermissions['wbeditor']['item-delete']      = true; $wgGroupPermissions['wbeditor']['alias-add']        = true; $wgGroupPermissions['wbeditor']['alias-update']     = true; $wgGroupPermissions['wbeditor']['alias-set']        = true; $wgGroupPermissions['wbeditor']['alias-delete']     = true; $wgGroupPermissions['wbeditor']['site-link-add']    = true; $wgGroupPermissions['wbeditor']['site-link-update'] = true; $wgGroupPermissions['wbeditor']['site-link-set']    = true; $wgGroupPermissions['wbeditor']['site-link-delete'] = true; $wgGroupPermissions['wbeditor']['lang-attr-add']    = true; $wgGroupPermissions['wbeditor']['lang-attr-update'] = true; $wgGroupPermissions['wbeditor']['lang-attr-set']    = true; $wgGroupPermissions['wbeditor']['lang-attr-delete'] = true;

In the current setup there are no read rights and there are also no default write rights for anonymous users. It seems likely that a setup for Wikipedia will assign add, update and set rights to anonymous users.

Note that with the default setup it is necessary to log in to the site, either through the usual web interface for the site or through global login (SUL).

Mode
All call to content changing API functions should be developed for (and prepared to) use the POST mode. During development it is possible to allow use of GET to make it simpler to piece together working requests. Javascript code for the browser should always use POST requests. By enabled the setting apiInDebug, that is to set it to true, the enforced use of POST is turned off.

If the API is in debug mode, that is by setting apiInDebug to true, all GET requests will be accepted. The rejection of GET requests are reenabled by setting apiDebugWithPost to true. A production environment could allow use of GET requests, but note that GET requests could create problems with caching.

Normalization
Values for several attributes (probably more of them) can be normalized. That includes language attributes, that is labels and descriptions, and when they are found to change when they are set, the value attempted to be set is reported as the from value and the actual new value is reported as the to value in an object normalized.


 * Example : http://localhost/repo/api.php?action=wbsetlanguageattribute&id=52&language=sv&label=Neverland&format=jsonfm&item=set
 * Returns the identifier for the changed item

{ 	"success": 1, "item": { "id": 52 } }

Errors
If the error condition is prepared and expected, and a format is defined, the error messages will have a standardized form.


 * example : http://localhost/repo/api.php?action=blah&format=jsonfm

The servedby is given unconditionally for error messages, but could be missing for some less than fatal errors. In some cases error messages can be appended to a success and be called warning(s).

All error messages from the Wikibase modules should be internationalized (i18n) and localized (l10n), but note that error messages from the base API system will usually not be localized. The user language for the logged in user (usually the same as in the web interface) will be the default for error messages. This can be overridden by putting uselang in the URL.

Do not depend on the info string for testing, use the code as this will remain independent of localization.

An internationalized error message that isn't localized as it should will have additional angle brackets.


 * example : http://localhost/repo/api.php?action=wbgetitemid&title=ThisPageDoesNotExist&site=fi&format=jsonfm

With correctly localized error message the angle brackets will go away and the info string will print out in clear text. Assuming the user is logged in and use English language it will print as something like the following.

Switching to Norwegian in the Special:Preferences or by appending  it will change the text of the info string to a localized variant, while the code string remains constant.

A lot of error messages are not properly localized.

Success
If a success is achieved it will have the following form when the  is set ([//labs.wikimedia.org/w/api.php?action=wbgetitem&format=jsonfm labs], localhost)

The interpretation of the value for success can be dependent on the actual parameters in the call, but usually it is a boolean that is type casted to an integer. Its meaning is that every previous tests evaluated to true.

There might be additional values in the structure after a successful call.