Mediawiki-api-announce

mediawiki-api-announce@lists.wikimedia.org

143 discussions

BREAKING CHANGE: Passing too many values for a multi-valued parameter waring is becoming an error
by Brad Jorsch (Anomie) 23 May '18

23 May '18

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

1 0

BREAKING CHANGE: Whitespace-only values to multi-valued parameters will no longer be considered empty sets
by Brad Jorsch (Anomie) 23 Jan '18

23 Jan '18

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

1 0

New warning due to removal of nonfunctional tgprop=name from action=query&list=tags
by Brad Jorsch (Anomie) 17 Jan '18

17 Jan '18

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

1 0

Minor BREAKING CHANGE in handling of pltitles, tltemplates, clcategories, and imimages parameters with invalid titles
by Brad Jorsch (Anomie) 12 Oct '17

12 Oct '17

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

1 0

DEPRECATION: prop=revisions diff and parse parameters
by Brad Jorsch (Anomie) 19 Jun '17

19 Jun '17

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

1 0

BREAKING CHANGE: Interpretation of rvstartid and rvendid parameters to prop=revisions
by Brad Jorsch (Anomie) 08 May '17

08 May '17

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

1 0

[ANNOUNCEMENT] REST API page metadata endpoints deprecation
by Petr Pchelko 03 May '17

03 May '17

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

2 1

[ANNOUNCEMENT] REST API /page/mobile-text endpoint deprecation
by Marko Obrovac 03 May '17

03 May '17

Hello, The mobile-text endpoint~[1] was introduced in the REST API as an experiment in the early days of the Mobile-Content-Service~[2] to provide page content optimised for use in very lightweight mobile clients. The route was an experiment towards a new-generation lite app, initially targeted for low-powered, older Android devices. The idea was to use native Android UI components to show the page contents instead of in a WebView; alas, it was quickly surpassed by a new set of mobile-sections endpoints~[3]. The route is not maintained, there are no plans to use it within the WMF and according to our metrics the endpoint is not used by the community. Therefore, as part of the effort to consolidate the useful endpoints and focus on new features, we have decided to deprecate the route and remove it on May, 1st 2017. If you’re using the endpoint, please use the alternative mobile-sections endpoints~[3,4,5] instead. Should you have any questions or concerns, please reply to this e-mail or contact the Wikimedia Services Team~[6]. Cheers, Marko Obrovac, PhD Senior Services Engineer Wikimedia Foundation [1] https://en.wikipedia.org/api/rest_v1/#!/Mobile/get_page_mobile_text_title [2] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/RESTBase_services_for_ap… [3] https://en.wikipedia.org/api/rest_v1/#!/Mobile/get_page_mobile_sections_tit… [4] https://en.wikipedia.org/api/rest_v1/#!/Mobile/get_page_mobile_sections_lea… [5] https://en.wikipedia.org/api/rest_v1/#!/Mobile/get_page_mobile_sections_rem… [6] https://www.mediawiki.org/wiki/Wikimedia_Services

1 1

Re: [Mediawiki-api-announce] [Wikitech-l] Deprecation notice for citoid.wikimedia.org domain
by Marko Obrovac 02 May '17

02 May '17

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

1 0

Wikimedia REST API hits v1.0
by Gabriel Wicke 07 Apr '17

07 Apr '17

It is official: The Wikimedia REST API <https://www.mediawiki.org/wiki/REST_API>, your scalable and fresh source of Wikimedia content and data in machine-readable formats, is now ready for full production use. The 1.0 release means that you can now fully rely on the stability guarantees set out in the API versioning policy <https://www.mediawiki.org/wiki/API_versioning>. Read more about the stability levels, use cases, as well as technical background on how the REST API integrates with our caching layers in our blog post: https://blog.wikimedia.org/2017/04/06/wikimedia-rest-api/ We are looking forward to your feedback at https://www.mediawiki.org/wiki/Talk:REST_API, or here on-list. This release was made possible by the hard work of many. First of all, the Services team <https://www.mediawiki.org/wiki/Wikimedia_Services> (Marko Obrovac, Petr Pchelko and Eric Evans), created the general API proxy and storage functionality, and curated the API documentation <https://en.wikipedia.org/api/rest_v1/>. The actual end points are co-designed with, and largely backed, by services developed by the following WMF teams: Editing (Parsing <https://www.mediawiki.org/wiki/Parsing> and citoid <https://www.mediawiki.org/wiki/Citoid>), Reading <https://www.mediawiki.org/wiki/Reading> (Infrastructure <https://www.mediawiki.org/wiki/Wikimedia_Reading_Infrastructure_team> and Web <https://www.mediawiki.org/wiki/Reading/Web>), and Analytics <https://www.mediawiki.org/wiki/Analytics>. Volunteer Moritz Schubotz and the MathJax <https://www.mathjax.org/> community contributed the math end points, and the PDF end point is powered by the open source electron-render-service <https://github.com/msokk/electron-render-service> project. Finally, the WMF techops team <https://www.mediawiki.org/wiki/Wikimedia_Technical_Operations> runs the excellent caching infrastructure that makes this API scale so well, and have helped with many aspects from hardware procurement to firewalling. Thank you all for your hard work! We are looking forward to continuing to work with you all on making this API an even better platform for building user experiences, services, and tools. Cheers, Gabriel and the Services team -- Gabriel Wicke Principal Engineer, Wikimedia Foundation

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Mediawiki-api-announce