The API has traditionally ignored values beyond the allowed limit,
returning a warning for this situation since 2008(!). It's long past time
for this error situation to actually raise an error, as requested in
https://phabricator.wikimedia.org/T41936.
This is happening in https://gerrit.wikimedia.org/r/433742. It should be
deployed to Wikimedia wikis with 1.32.0-wmf.6 or later, see
https://www.mediawiki.org/wiki/MediaWiki_1.32/Roadmap for the schedule.
Logs indicate that few clients on Wikimedia wikis are hitting the warning.
You can check your client by seeing if you're receiving a "Too many values
supplied for parameter" warning, or by using Special:ApiFeatureUsage for
your client's user agent and looking for a "too-many-X" code.
If your client is affected, the solution is to divide the values into
batches of the appropriate size. Generally the limit is 50 values for
clients without the apihighlimits right and 500 for clients with that
right. The limits for any particular parameter are documented in the
auto-generated help and are available in machine-readable format via
action=paraminfo.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
There's an inconsistency in the handling of multi-value parameters where if
you pass a value consisting of only whitespace[1] it will be interpreted as
an empty set rather than as a single value consisting of whitespace. For
example, https://www.mediawiki.org/w/api.php?action=query&titles= correctly
handles the query as specifying no titles, but
https://www.mediawiki.org/w/api.php?action=query&titles=%20 is also treated
as specifying no titles rather than specifying a title consisting of a
space character.
With Gerrit change 405609,[2] the behavior will be changed so that the
latter query will behave more like
https://www.mediawiki.org/w/api.php?action=query&titles=_ in reporting that
the supplied title is invalid. The plan is that this will be deployed to
WMF wikis with 1.31.0-wmf.20 on February 6–8, see
https://www.mediawiki.org/wiki/MediaWiki_1.31/Roadmap for the schedule.
Passing an empty string as the value of a multi-valued parameter will
continue to be treated as a set of zero elements rather than a one-element
set containing the empty string.
Most clients should handle this change without major issue, as the
resulting response is consistent with the response when any other invalid
title is submitted. Clients that want to continue treating whitespace-only
input as no input should begin checking for whitespace-only input before
submitting it to the API.
[1]: Specifically: spaces (U+0020), tabs (U+0009), line feeds (U+000A), and
carriage returns (U+000D).
[2]: https://gerrit.wikimedia.org/r/#/c/405609/
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
The tags query module has a tgprop parameter to specify which properties of
the tag should be returned. One of these properties was 'name', but the
name was always included in the response regardless of whether this
property was included in tgprop.
Since most uses aren't specifying 'name' but we can assume clients are
depending on the name being included (since there's otherwise no way to
identify which tag is which), we've removed the nonfunctional 'name' as a
valid option for tgprop. This will result in a warning that 'name' is not a
valid value for tgprop for those few clients that are specifying 'name'
there.
This change will not affect the functionality of any clients unless the new
warning somehow breaks them. It should be deployed to WMF wikis with
1.31.0-wmf.18 or later. Clients can safely stop specifying 'name' in tgprop
immediately, though, since it doesn't do anything.
For further information, see https://phabricator.wikimedia.org/T185058.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Previously, if none of the values supplied for the pltitles, tltemplates,
clcategories, or imimages parameters to prop=links, prop=templates,
prop=categories, or prop=images were valid titles, the parameter would be
ignored and all links, templates, categories, or images would be returned.
With the merge of Gerrit change 347879,[1] this situation will result in no
links, templates, categories, or images being returned, as none match the
invalid titles supplied.
Note that submitting an empty value for one of these parameters will
continue to ignore the parameter and return all links, templates,
categories, or images, since this seems to be relatively common practice.
[1]: https://gerrit.wikimedia.org/r/#/c/347879/
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
In the action API, there are two ways to parse a page/revision: using
action=parse, or using the rvparse parameter to action=query&prop=revisions.
Similarly, there are two ways to get a diff: using action=compare, or using
parameters such as rvdiffto to action=query&prop=revisions. And then
there's action=expandtemplates versus the rvexpandtemplates parameter to
prop=revisions. This is a somewhat annoying bit of code duplication.
Further, the prop=revisions versions of these features have somewhat
strange behavior. rvparse forces rvlimit=1. rvdiffto and related parameters
will sometimes output "notcached" with no way to directly handle the
situation.
This, the 'rvdifftotext', 'rvdifftotextpst', 'rvdiffto',
'rvexpandtemplates', 'rvgeneratexml', 'rvparse', and 'rvprop=parsetree'
parameters to prop=revisions are all deprecated, as are the similarly named
parameters to prop=deletedrevisions, list=allrevisions, and
list=alldeletedrevisions.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Most of the time, the ordering implied by revision ID number and the
ordering implied by revision timestamp are the same. Differences occur
mainly when revisions are imported from another wiki, however there may be
other situations that can cause this.
The database queries that were formerly used to handle the rvstartid and
rvendid parameters were found to be very inefficient.[1] As of Gerrit
change 349448,[2] these parameters are now equivalent to using the
timestamps of the corresponding revisions for rvstart and rvend.
This change should be deployed to WMF wikis with 1.30.0-wmf.1, see
https://www.mediawiki.org/wiki/MediaWiki_1.30/Roadmap for the schedule.
[1]: https://phabricator.wikimedia.org/T163495#3200490
[2]: https://gerrit.wikimedia.org/r/#/c/349448/
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Hello,
Since the early days of REST API it provides two features that haven’t been widely used neither internally in the WMF nor by the community. Today in a clean-up pass over the API we have decided to deprecate and eventually remove those features to allow some long-needed refactorings and stability improvements of other, more important, endpoints.
The first one is the ability to query metadata about the page via the `/page/title/{title}`~[1] endpoint. The metadata includes properties like the latest revision number of the page, user who have made the last edit, whether the page is a redirect and similar. The backend storage model used to power the feature is quite unique in the system and has a significant maintenance cost without providing a clear benefit to users.
Another feature that’s never found it’s audience is the ability to get listings of revisions, titles and renders stored in RESTBase. These listings suffer from scaling issues and cannot work reliably with the data model we have.
We have, hence, opted to remove these unused and complex endpoints until there is some actual need for this data in the REST API when we can design and implement them better. Here’s the list of endpoints that are now deprecated and will be removed on May, 1st 2017:
• /page/title/
• /page/title/{title}
• /page/title/{title}/
• /page/revision/
• /page/revision/{revision}
In case you are using them please switch to using the MediaWiki Action API. In case you need assistance or have questions, feel free to reply to this e-mail or contact the Wikimedia Services team~[2].
Best regards,
Petr Pchelko
Software Engineer
Wikimedia Foundation
[1] https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_page_title_title
[2] https://www.mediawiki.org/wiki/Wikimedia_Services
Hello,
We have retired the subdomain citoid.wikimedia.org at 17:00 UTC today. As
previously indicated by James, the way to reach Citoid, the citation
service, is now exclusively through the REST API~[1].
Cheers,
Marko Obrovac, PhD
Senior Services Engineer
Wikimedia Foundation
[1] https://en.wikipedia.org/api/rest_v1/#!/Citation/getCitation
On 8 March 2017 at 11:51, James Forrester <jforrester(a)wikimedia.org> wrote:
> Hey all,
>
> The citoid service, which looks up URLs and similar strings and turns them
> into citations, has moved to be accessed via RESTbase as part of
> decommissioning the per-service domain system[0]. The old domain will stop
> working on *1 May 2017* (just under two months from now).
>
> In simple terms, this means that requests to citoid via
> citoid.wikimedia.org/api?… (*e.g.* [1]) now need to go to {wiki
> domain}/api/rest_v1/data/citoid/… (*e.g.* [2]) to work. End-point
> documentation is available in the usual place.[3]
>
> We have already moved the automatic citation feature inside the visual
> editor to use the domain. If you are responsible for a script, gadget, or
> tool which is using the old domain, please switch over before the deadline.
>
> [0] https://phabricator.wikimedia.org/T133001
> [1]
> https://citoid.wikimedia.org/api?format=mediawiki&search=
> http%3A%2F%2Flink.springer.com%2Fchapter%2F10.1007%2F11926078_68
>
> [2]
> https://www.mediawiki.org/api/rest_v1/data/citation/
> mediawiki/http%3A%2F%2Flink.springer.com%2Fchapter%2F10.1007%2F11926078_68
>
> [3] https://en.wikipedia.org/api/rest_v1/#!/Citation/getCitation
>
> Yours,
>
> --
>
> James D. Forrester
> Lead Product Manager, Editing
> Wikimedia Foundation, Inc.
> jforrester at wikimedia.org
> <https://lists.wikimedia.org/mailman/listinfo/wikimedia-l> |
> @jdforrester
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l