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 Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

On Thu, Feb 5, 2015 at 12:04 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote: In RESTBase we generally use mime type versioning like this: application/json; profile=mediawiki.org/specs/app_page_bundle/1.0.0 This is specced in the Swagger spec & enforced by RESTBase. On version mismatch from stored content, the backend service is called to re-generate or upgrade the content, which is then saved back. It can be passed the stored content to make re-generation more efficient. If needed, clients could also signal the content-type they expect with an accept header. The details of how things would then be upgraded / downgraded would need to be worked out in case you really need this. In general, you can go a long way by only adding properties while remaining backwards-compatible with the old properties. We also distinguish stability per end point: - *experimental *end points can change at any time (effectively private, use at your own risk) - *unstable *end points can change, but we make an effort to avoid breakage and notify users - any change to *stable* end points will increment the major API version (/v1/) following semver The mobile API should probably be marked as experimental, as it is primarily intended as an API for apps we control. Gabriel _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

- Image meta data for all images in the page - License - Description - Includes the URL for the high resolution version used for the lead image Wouldn't that bloat the response size?

On 5 February 2015 at 13:20, Max Semenik <maxsem.wiki(a)gmail.com> wrote: The rationale for including this is because that way the image viewer will work even if you've not tapped on any of the images. This is pretty important functionality that doesn't work offline right now, even if you save the page for offline reading. That said, we may want to punt this until after the MVP as being possibly outside of scope. Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

On Feb 5, 2015, at 1:40 PM, Max Semenik <maxsem.wiki(a)gmail.com> wrote: Saving a page for offline is not that speed sensitive, however, serving this information as part of normal page views would definitely impact overall latency. -- Best regards, Max Semenik ([[User:MaxSem]]) _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l