Thank you for the feedback. It's clear that we need option (b) but at a reduced scale initially, and later when we want to actually use it for the beta app increase it, then later for production increase it some more. This helps with estimating the task <https://phabricator.wikimedia.org/T91794> for next sprint. Marko, about your other question. I think the service will change some more in the future, and could change quite substantially. It's just not sure when exactly but still while having it marked as experimental. Monte and I are playing with the idea of changing the format and Content type from JSON with embedded HTML to HTML with some metadata embedded as JSON. The embedding could be done multiple ways, probably inside the HTML in a JS script block (<script> tag). (Alternative options could be also CDATA blocks or even multipart.) I'm thinking we could have a small portion of metadata at the beginning of the payload for performance reasons to include whatever is needed to display above the fold: page id, rev id, title, description, lead image url, .... And then we'd have another section of metadata (ToC, gallery, read next, ...) at the end of the payload. The idea for the client would be to instead of sending each section HTML over the JS bridge to just use WebView.loadUrl() <http://developer.android.com/reference/android/webkit/WebView.html#loadUrl(java.lang.String, java.util.Map<java.lang.String, java.lang.String>)> and take advantage of streaming that way. This would significantly reduce the number of requests. This would also reduce the payload since we don't have to encode HTML inside JSON. Well, that's the current idea. We'll see how this would work. I think the service could be easily change to do that. This would be a bigger change on the client side, but should make client code simpler and much more performant, too. Cheers, Bernd On Wed, Mar 11, 2015 at 9:47 AM, Dan Garry &lt;dgarry(a)wikimedia.org&gt; wrote: