API talk:Main page

Subpages

 * General Archive

Unless you comment is related to the whole API, please post it on one of the API subpages.

Please add your suggestions and ideas to Bugzilla with component field set to "API".

Protected pages
Hi. I have another request... would it be possible to add  or something similar to retrieve the list of protected articles? I could not find any other way (other than downloading ) for doing so. Thanks! Paolo Liberatore 12:46, 3 October 2006 (UTC)
 * I am not sure the list of protected articles is available from the database. If it is, I can certainly expose it. --Yurik 16:24, 3 October 2006 (UTC)
 * That would be great! Thank you. Paolo Liberatore 16:16, 10 October 2006 (UTC)
 * As an alternative that could be possibly be simpler to implement, the entire record of an article from the page table could be retrived via . Paolo Liberatore 17:52, 6 November 2006 (UTC)
 * I just noticed there is a page_restrictions field in the page table. I will have to find out what it might contain (the Page table is not being very descriptive, and afterwards add that to prop=info. Filtering by that field is problematic because its a tiny blob (i don't think mysql can handle blob indexing, but i might be wrong). --Yurik 22:31, 6 November 2006 (UTC)
 * Here is my reading of the source code. The point where page_restrictions is interpreted is . There,   reads this field, parses it and stores the result in the   array. This array is then used by   to return an arrary containing the groups that are allowed to perform a given action. As far as I can see, this array is such that   is an array that contains the groups that are allowed to perform the edit action, etc. Except that, if this array is empty, no restriction (other than default ones) apply.
 * In the database dump, the page_restrictions field appears to be either empty or something like  or just  . The explanation of the table says that this is a comma-separated list, but the comments in Title.php mention that is an old format (I think that the value 'sysop' is actually in this format; no page in wikien current has a comma in the page_restrictions field). Paolo Liberatore 15:52, 11 November 2006 (UTC)

Diffs
Are there any plans to provide raw diffs between revisions? This would be particularly helpful for vandalism fighting bots who check text changes for specific keywords and other patterns. The advantage would be that diffs require much less bandwidth and therefore increase bot response time. What do you think? Sebmol 15:24, 21 November 2006 (UTC)

Count
Would it be possible to add an option which woud simply return the number of articles which satisfied the supplied conditions? This would be especially helpful counting large categories, like en:Category:Living people. HTH HAND —Phil | Talk 15:59, 29 November 2006 (UTC)
 * I second that emotion. Zocky 23:26, 9 December 2006 (UTC)
 * Unfortunately this is harder than it looks - issuing a count(*) against database if the client asks for list=allpages would grind db to a halt :). Same goes for list of all revisions, user contribution counters (we even had to introduce an extra db field to keep that number instead of counting), etc. So no plans for now, unless some other alternative is given. --Yurik 09:41, 8 July 2007 (UTC)

version/image info
I think it would be useful to get information about the sofware version (i.e. core version, extensions, hooks/functions installed) and images (i.e. checksum would useful to see if an image has changed). -Sanbeg 21:08, 7 December 2006 (UTC)
 * Some of it is available through the siteinfo request. More will be done later. --Yurik 01:59, 22 May 2007 (UTC)

Select category members by timestamp
Hello, is it possible to retrieve cm with a parameter that lists only starting from a certain timestamp? This should be possible, since a timestamp is stored in the categorylinks database table. Is this the correct place to ask, or should I file a bug in bugzilla? Bryan 12:18, 24 December 2006 (UTC)


 * Similarly get all templated embedding pages by timestamp would be useful for monitoring when a template gets used because it contains structured data that can be reflected on other websites.82.6.99.21 15:14, 9 February 2007 (UTC)


 * Not sure what you mean. Please file a feature req in bugzilla with the sample request/response. --Yurik 09:43, 8 July 2007 (UTC)

mw-plusminus data
MediaWiki recently add mw-plusminus tags to Special:Recentchanges and Special:Watchlist, which display the number of characters added/removed by the edit. I was wondering if it may be possible for api.php to both retrieve this info and somehow append the data to query requests that involve page histories, recentchanges, etc. I would most like to see this available in usercontribs queries, as that data is currently not retrievable through any other medium (save for pulling up each edit one at a time and compaing the added/removed chars). Thanks. AmiDaniel 23:55, 26 February 2007 (UTC)
 * Done for rc & wl. --Yurik 20:09, 8 July 2007 (UTC)

Query Limits
Hi all, another suggestion from me. On the API it is stated that the query limit of 500 items is waived for bot-flagged accounts to the MediaWiki max query of 5000. Would it be possible to extend this same waiver to logged-in admin accounts? I have multiple instances in some of my more recent scripts that query, quite literally, thousands of items (backlinks, contribs, etc.) that are primarily only used by myself and other administrators on enwiki. While having to break these queries up into units of 500 causes a rather dramatic performance decrease on the user's end, I can't imagine it's particularly friendly on the servers either (or rather, submitting two or three requests of 5000 each would likely be less harmful to the servers than twenty or thirty requests of 500 each). Generally, admins are considered similarly well-trusted not to abuse such abilities, and they are also small in numbers on all projects. Also, the MediaWiki software itself allows similar queries of upto 5000, and I most presume that loading this data from MediaWiki is far more burdenous on the servers than submitting the same query through API. This clearly more a political matter than a technical one, but I'd like to know if there are any objections to implementing such a change. Thanks. AmiDaniel 05:05, 1 March 2007 (UTC)

partial content
it is great to be able to retrieve wikipedias content by an API, but nobody is really going to need the whole page.

would it be possible to pass a variable which adds only the lead paragraph (everything before the TOC) to the XML, not the whole content ? This would be ideal for an implementation into another context, then adding a "View Full Article" link underneath.

any chance of this becoming a possibility ?--83.189.27.110 00:49, 19 March 2007 (UTC)


 * I'd also consider useful to be able to retrieve a single section from the article, so that one could first load the article lead and the TOC, and then see only some of the section(s). This would be a great improvement of efficiency especially for people on slow links (e.g., mobile) and for "community" pages, such as en:Wikipedia:Administrator's noticeboard, some of which tend to be very long. Tizio 15:19, 20 March 2007 (UTC)

returning the beginning/end of a document
Is there any possibility of an API function that returns the first x bytes at the beginning or end of a document? An increasing amount of metadata is stored at the beginning or end of wikipedia articles, talk pages, etc. And tools like "popups" that preview pages don't need to transmit the whole document to preview part of it. I am thinking of client, server, and bandwidth efficiency. Outriggr 01:43, 20 April 2007 (UTC)

Current status ?
Hi,

I have started developping a tool in Java to deal with some maintenance tasks, especially for the disambiguation pages. For the moment, I have planned to do two parts :
 * Much like CorHomo, a way to find and fix all articles linking to a given disambiguation page.
 * A way to find and fix all links to disambiguation pages in a given article.

To finish my tool, I need a few things done in the API :
 * Retrieving the list of links from an article.
 * Submitting a new version of an article.

Do you have any idea when these features will be available in the API ?

How can I help ? (I am rather a beginner in PHP, I have just developped a MediaWiki extension, here, but I can learn).

--NicoV 13:24, 23 April 2007 (UTC)


 * For your "Retrieving the list of links from an article" problem, check the query.php what=links query. It's already been implemented, just not brought over into api.php. As for submitting a new version of an article, I'm afraid there is no ETA on this, and I'm honestly not sure how Yurik is going to about doing this. For now, I'd recommend you do it as it's been done for years--submitting an edit page with "POST". It's not the greatest solution, but it works. If you'd like to help, please write to w:User_talk:Yurik; I'm sure your help is needed! AmiDaniel 18:10, 23 April 2007 (UTC)


 * Thanks for the answer. I was hoping to use a unique API, but no problem in using query.php for the links. For submitting a new version, do you know where I can find an example of submitting an edit page ? --NicoV 20:33, 23 April 2007 (UTC)


 * Unfortunately, dealing with forms and especially MediaWiki forms (as submitting all forms requires fetching userdata from cookies typically) in Java is not particularly easy. For a basic example in submitting a form in Java, see this IBM example. For most of the stuff I've developed, instead of trying to construct my own HttpClient and handle cookies myself, I've simply hooked into the DOM of a web browser and let it take care of the nitty gritty of sending the POST's and GET's. You can see an example of this method using IE's DOM here. I've not found a good way to get the latter to work with Java as Java does not have very good ActiveX/COM support, though it can sort of be done by launching a separate browser instance. I'm afraid I can't really help much more, unfortunately, as it's a problem that's not been well-solved by anyone. It's easy to build MediaWiki crawler's, but not so easy to build bots that actually interact with MediaWiki. AmiDaniel 21:20, 23 April 2007 (UTC)


 * A en-wiki user has written something for page editing in java: en:User:MER-C/Wiki.java. HTH. Tizio 13:10, 26 April 2007 (UTC)


 * I have used parts of the java class you linked, and it's working :) Thanks --NicoV 07:57, 22 May 2007 (UTC)

Ok, thanks. I will take a closer look at the examples. --NicoV 05:38, 27 April 2007 (UTC)


 * Some have been done (links, etc). See the main page. --Yurik 11:48, 14 May 2007 (UTC)


 * Thanks, I will try to use it when it's available on the French Wikipedia --NicoV 20:28, 14 May 2007 (UTC)

Hi, I've also started a Java API (see my blog entry: Java API for MediaWiki query API, I'd like to here opinions about the design and usability of the library. Thanks Axelclk 17:57, 22 June 2007 (UTC)

Real current status
Could somebody please tell the current status of the api regarding fetching a list of links from a site via api.php?query&titles=Albert%20Einstein&prop=links ?

This works just fine with the latest mediawiki on wikipedia but on my mediawiki v1.10 it dont work at all. error reported: unknown_prop. I investigated some time and recognized that there is no includes/api/ApiQueryLinks.php in 1.10. The import of the module also is commented out in ApiQuery.php, like this:

private $mQueryListModules = array (     'info' => 'ApiQueryInfo',      'revisions' => 'ApiQueryRevisions'   }   // 'links' => 'ApiQueryLinks'   // ...some other modules as well

So, what's going on? On it is stated that the link fetch feature is available with MW 1.9. I am confused...
 * So am I :) From what I remember, it has been working for a long time. There is a new release coming out shortly, that will include all the proper changes. As for now, I would suggest simply copying the entire API directory from the current SVN - API would not mess up anything, so if worst comes to worst, it will simply not work :) --Yurik 21:37, 13 July 2007 (UTC)


 * Unfortunatly, this didn't work for me. I checked out the latest trunk/phase3/api. After moving it into includes, nothing works at all :( The PHP engine stated: Fatal error: Call to undefined function wfScript in /srv/www/vhosts/wikit/htdocs/mediawiki-1.10.0/includes/api/ApiFormatBase.php on line 88 . So, I thought to try to get just the class ApiQueryLinks to work with the 1.10.0 api-code and included the class in ApiQuery. After that I tried to call the api. But it seems like the ApiQueryGeneratorBase-class cant be found anywhere. Hopefully the api will work again with one of stable releases to come... --Bell 09:09, 16 July 2007 (UTC)

Tokens
I, personally, don't understand why state-changing actions currently require tokens. Shouldn't the lg* parameters be enough to determine whether the client is allowed to perform a certain action? If so, why do you need tokens?

On a side note, I intend to start writing a PHP-based bot using this API, and will try to include every feature the API offers. Since both this talk page and its parent page have been quiet for two weeks, I was wondering if new API features are still posted here. If that is the case, I'll monitor this page and add new features to my (still to be coded) bot when they appear. I'll keep you informed on my progress. --Catrope 17:20, 9 May 2007 (UTC)


 * The motivation for tokens at Manual:Edit token is that they are used to prevent session hijacking. Tizio 19:02, 15 May 2007 (UTC)
 * Ah, I understand now. Didn't think it through as deeply as you did. --Catrope 20:19, 22 May 2007 (UTC)
 * Would it be possible to at least grab editing tokens by API, and require session data, cookie tokens, etc. to get them? The same can be done with index.php (if not mixed up in a lot of other HTML). Gracenotes 17:04, 4 June 2007 (UTC)

Login not working ?
Hi, is there a problem with the "login" action? Whenever I try (in the last hour), I get the following message:  -- NicoV 20:57, 21 May 2007 (UTC)


 * Yes, unfortunately I had to disable login action until a more secure solution is implemented. The current implementation allowed countless login attempts, allowing crackers to break weak passwords by brute force. Disabling it was the only solution. Any help with fixing login module would be greatly appreciated and bring it back faster. --Yurik 01:58, 22 May 2007 (UTC)


 * Would it be possible while disabling it to return an understandable message, like result=Illegal or an other value like result=LoginDisabled ? Currently, when asking XML result, the result is not XML. My tool wasn't prepared for this :). That way, when I get this answer, I would be able to validate the login using an other method (by going through the Special:Login page).
 * Concerning help, I am not very good at PHP, so I doubt I can help you much. I suppose simple tricks like delaying the answer of the login action wouldn't be sufficient. --NicoV 07:17, 22 May 2007 (UTC)


 * The format is obviously not handled properly - even if everything else fails, proper format should be used. Please file as a bug. Thanks for the logindisabled suggestion - I might implement something along those lines later. Now, if only someone could help with the login php code :) Its not hard, just annoying :( --Yurik 21:07, 22 May 2007 (UTC)

I just sent a patch of to Yurik that fixes these security vulnerabilities (the big one that Yurik mentioned at least) and re-enables the login, so this will hopefully make it in the repo by tomorrow and will be synced up on Wikimedia's servers within the week. Sorry for the inconvenience. AmiDaniel 10:36, 23 May 2007 (UTC)


 * That's great news, but in the mean time, the Special:Login page has just been modified with a capcha (at least on the French wikipedia). So the method I was using to edit pages is not working any more :( Is there a way to edit pages with a tool ? --NicoV 15:30, 23 May 2007 (UTC)

Limits
Limits on some queries (like logevents) is lower than allowed via common MW interface. - VasilievVV 15:34, 29 May 2007 (UTC)
 * RC (list=recentchanges) also has this problem. api.php limits it to 500, but I can get up to 5000 using the regular interface. --Catrope 15:37, 29 May 2007 (UTC)


 * This has recently been changed to allow the limit of 5000 and 50 to fast and slow queries, respectively, to sysops as well as bots. We're hesitant enabling higher limits to non-sysops and non-bots, however, until we can do some serious efficiency testing with the interface. AmiDaniel 08:35, 1 June 2007 (UTC)
 * Why is it necessary to make different limits for bots and normal users? They have equal limits in UI (5000). So I think it would be better to set 5000 limit to all queries, that doesn't read page content - VasilievVV 08:38, 2 June 2007 (UTC)

Bad title error
Compare the result of the following two queries: http://www.mediawiki.org/w/api.php?action=query&prop=info&titles=API|Dog&format=jsonfm http://www.mediawiki.org/w/api.php?action=query&prop=info&titles=API||Dog&format=jsonfm In the latter query, the second title is empty (and thus invalid), which causes the API (to rightfully) throw an error. The downside is that it destroys my entire query (the original query that caused my error here contained 500 titles, of which one was empty). This is pretty unfriendly behavior, but fixing this raises the issue of having to return an error and a query result in one response (which is currently impossible).

Alternatively, I can make sure there are no empty titles in my query (which fixed my problem), but are empty titles the only ones that trigger the "invalid query" error? If not, could someone provide a list of exactly what causes api.php to return "invalid query"?

Thanks in advance --Catrope 15:32, 5 June 2007 (UTC)

Searching content?
There's a comment from 2006 in the General Archive above that says:
 * Search
 * list of articles that contain string query

Is this being implemented in the API? -- SatyrTN 21:55, 7 June 2007 (UTC)
 * A feature like this would be essential for search-and-replace bots. --Catrope 07:40, 8 June 2007 (UTC)
 * So would that be a "yes"? :) -- SatyrTN 14:02, 13 June 2007 (UTC)
 * I have no idea if it's going to be implemented or not, I'm not in charge of developing the API. I was just saying that it's very useful, and should be implemented.--Catrope 15:29, 13 June 2007 (UTC)
 * I agree that it would be an excellent feature to have. My biggest concern at the present though is the ability to unit test the API: we are in dire need to have good testing framework before we move forward. --Yurik 01:11, 14 June 2007 (UTC)
 * What sort of framework, exactly, are you thinking of? There is a lot of bot code around that might be a starting point. CBM 02:51, 14 June 2007 (UTC)

Page watched ?
With the API, is there a way to know if a page is watched by the user ?

That would be useful for me: I have written a tool to help fixing links to disambiguation pages, and currently when the tool submits a new version of a page, the page is always unwatched. I can probably deal with this, but that would mean reading a lot more from Wikipedia, because the "wpWatchthis" checkbox is far from the begining of the page. --NicoV 21:12, 8 June 2007 (UTC)
 * You don't need the checkbox, the buttons right on top of the page are enough. There will be a "watch" button if the page isn't watched, and an "unwatch" button if it is. Of course when editing pages is implemented in the API, you'll no longer need all of this. --Catrope 08:47, 11 June 2007 (UTC)
 * Yes, thanks. The only drawback seems the waste of bandwidth (the watch button is almost at the end of the HTML file, while the checkbox is earlier, and a lot earlier on the French wikipedia because a lot of automatic stuff is added in between). I have already tested with the checkbox, but it doesn't work how I'd like it to for users having a preference of automatically watching pages they are editing. I will try the Watch button. --NicoV 21:39, 12 June 2007 (UTC)
 * Hmm, maybe request the watchlist (through the API) at the beginning of your program, then check every page title against that list? --Catrope 12:57, 13 June 2007 (UTC)
 * Thanks again, but I have decided to use the "watch"/"unwatch" button, until (I hope) there's a way of getting this info when retrieving page data through the API. --NicoV 17:40, 14 June 2007 (UTC)
 * You really don't need to. With two requests to the API (one to log in and one to get your watchlist through action=query&list=watchlist) you can store your watchlist in an array. When editing a page, simply check if it's in the array. --Catrope 19:42, 14 June 2007 (UTC)

DEFAULTSORT key
I know very little about programming and computers, but this API thing sounds like it could be used to get useful data such as a list of biographical articles without DEFAULTSORT keys. Am I right to think that a query could be run that could detect all articles with w:Template:WPBiography on their talk pages, but which didn't have the DEFAULTSORT magic word somewhere in the article, and furthermore that the categories (cl) function with "Parameters: clprop=sortkey (optional)" could detect existing pipe-sorting in the categories and output that data as well? Or am I misunderstanding the purpose and limits of API? Carcharoth 10:16, 18 June 2007 (UTC)
 * It's possible, but:
 * The API can list articles with a certain template in them or all articles in a certain category, but it can't search through them. You'll have to write a script that does that.
 * That script could distinguish DEFAULTSORT, pipe-sorted and non-sorted articles, but it can't automatically correct them to use the DEFAULTSORT magic. You'll have to do that by hand.
 * I'll write that script some time this week (as the DEFAULTSORT issue is present on BattlestarWiki as well), so keep an eye on this page to see when it's there. --Catrope 15:06, 18 June 2007 (UTC)

Feature request : list=random
Let the API generate a list of random pages as the list. Parameters: Would be useful for tools that look for pages/images matching criteria that are not easily obtained otherwise, e.g., pages with no (trivial) categories. --Magnus Manske 23:51, 23 June 2007 (UTC)
 * Namespace(s)
 * Redirect filter
 * Limit

Future edit API
I think that when the edit functionality is to be implemented, it should be defined as POST, and not GET. → Aza Toth 23:43, 24 June 2007 (UTC)
 * I think it shouldn't deny either kind of request as both have their uses. It's the names and values contained in the requests that should determine the functionality, not the kind of request. --Nad 04:13, 25 June 2007 (UTC)
 * nah, there's a reason for GET and POST to be different HTTP-verbs. one to get information from the server, one to change information on the server. btw, login should never work with GET, you don't want your password in the server logs. -- D 12:02, 25 June 2007 (UTC)
 * GET and POST are allowed for all API requests, and there is no easy way to change that for just one action. IMO, users who are stupid enough to send a GET request with their password or other sensitive stuff should bear the consequences. BTW, action=edit users will be forced to use POST in most cases, since the query string supplied with GET is limited to 255 characters, while most articles are substantially longer. In fact, the longest Wikipedia article comes close to being 450KB in size. --Catrope 18:11, 26 June 2007 (UTC)

API Interface for .NET
I've been putting together an Open Source .NET interface for the MedaiWIKI API, I've looked around the site for where to list it, but haven't found anything that looks like the right place, can anyone point me in the right direction as to where? 65.27.174.205 02:15, 1 July 2007 (UTC)
 * I have made something similar a while back, but haven't published it. Not sure if mediawiki would want to keep this, but you could always add it to sourceforge. --Yurik 03:42, 2 July 2007 (UTC)
 * Yeah not a big deal, currently have it on google hosting maybe i'll move it. Thanks 65.27.174.205 21:43, 2 July 2007 (UTC)
 * On http://sourceforge.net/projects/jwbf/ you can find a API Interface for Java, what are you thinking about a list of projects which supply connectors to MediaWiki API ?
 * Will create a page for them, thanks for the link. Please sign your posts with --~ . --Yurik 18:49, 8 July 2007 (UTC)