Some of the Mobile Apps Team engineers met to discuss the scope of the MVP
for a mobile apps content service.
Firstly, we enumerated our goals for this content service:
- Minimise number of requests the app has to make to generate a page
- Reduce payload size of requests
- Abstract away from of the API logic contained in the client into the
server instead
- Do some of the transforms that are currently done on the client on the
server instead, where appropriate
We decided that the scope of the service should be feature parity; the
service should be a drop-in replacement for our current API calls. More
concretely, this means it should give us:
- Data from mobileview
- Wikidata description
- Revision ID of page
- Wikibase ID
- Image meta data for all images in the page
- License
- Description
- Includes the URL for the high resolution version used for the lead
image
- Exclude unused HTML
- Navboxes, etc.
- Exclude hidden elements
- CSS: display: none; unless if we display later
- Related articles suggestions from full text search API
Things which we want to add, but are out of scope for the first iteration:
- Arbitrary Wikidata properties
- Disambiguation (already "transcluded", following the chain of
disambiguation pages and returning a JSON array of those links)
- Page issues
- Interwiki links
- Table of contents (as a JSON array)
Open questions:
- Versioning? What if we add or remove a field from the response? We
should version this. Can we do this easily?
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
_______________________________________________
Mobile-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mobile-l
