Reading/Mobile needs from MediaWiki API
This page documents mobile web and app needs from MediaWiki APIs, mostly the action API.
- T96956: AbuseFilter should not let users specify arbitrary error codes which are then emitted over the API
- T95378: Add support to PageImages for finding a freely licensed page image
- T95072: API blocked error should give details - blocker, target (IP, range, user), expiry, reason, etc.
- T88083: Mobile apps users should not be shown captchas when creating accounts
- T30085: Allow user login with email address in addition to username
- T87824: Create specialised content API for mobile apps
- T32788: Allow triggering of user password reset email via the API
- T87336: PageImages shouldn't return images that are not in the lead section
- T76103: Createaccount API should support username validation without having to try to create an account
- T74387: "createaccount" action failure should return the name of the extension that caused it to fail.
- T98146 - Create an API to get the lead image for an article
- T98147 - Create an API to get and set cropping information for the lead image of an article
- T98067 - move text cleanup and 1-2 sentence logic from the "Link preview" mobile feature into TextExtracts
Migrate api.php requests to use improved
- mobile-tech: "image cropping in Gather"
- Pending investigation: JSON serialization bugs (empty objects as arrays)
- Meeting minutes from meeting about mobile-specific content service
- FIXMEs in MobileFrontend
- API versioning policy for the REST API
- please review
If existing MediaWiki web APIs aren't ideal for mobile, they're probably not ideal for other clients, so improve them. versioning issues?
Underlying APIs should be reusable between desktop and apps.
If you're aggregating api.php requests or need caching, build in RESTbase like https://github.com/wikimedia/mediawiki-services-mobileapps
If you want to store information about a page, e.g. best lead image and its dimensions, you have a choice:
- using RESTBase, which is currently focusing on storing information about pages and revisions, or
- store in the wiki DB as page props or new tables
The longer term strategy in this space is evolving currently, so please let us know about your short and long-term needs.