Change Details

The MobileApps service is about to be ready for initial deployment. To that end, we need to hook it up in #RESTBase : - create the Swagger spec - add the back-end service config Several app service entry points will request the latest data for a title, without passing in a revision ID. This means that we'll need to check for the latest revision in the RB revision table before requesting mobile app content from storage and the service. The current plan is also to store lead and remainder sections, both wrapped in JSON. It might be desirable for the app service to return both in one JSON blob. The app will generally request the parts separately, but there is also the possibility of requesting both parts at once. In RESTBase, we can implement this by storing the service response as a single JSON blob. For lead / remainder requests, we can simply return the lead/remainder sub-objects, which are already parsed in RESTBase. Zero header support in Varnish (T102524) would be desirable, but likely won't be a hard blocker for the service roll-out. The main effect of this on the app is showing a 'you are browsing for free' banner, which might be okay to be missing in the beta channel.

The MobileApps service is about to be ready for initial deployment. To that end, we need to hook it up in #RESTBase : - create the Swagger spec - add the back-end service config Several app service entry points will request the latest data for a title, without passing in a revision ID. This means that we'll need to check for the latest revision in the RB revision table before requesting mobile app content from storage and the service. The current plan is also to store lead and remainder sections, both wrapped in JSON (see T102270). It might be desirable for the app service to return both in one JSON blob. The app will generally request the parts separately, but there is also the possibility of requesting both parts at once. In RESTBase, we can implement this by storing the service response as a single JSON blob. For lead / remainder requests, we can simply return the lead/remainder sub-objects, which are already parsed in RESTBase. Zero header support in Varnish (T102524) would be desirable, but likely won't be a hard blocker for the service roll-out. The main effect of this on the app is showing a 'you are browsing for free' banner, which might be okay to be missing in the beta channel.

The MobileApps service is about to be ready for initial deployment. To that end, we need to hook it up in #RESTBase : - create the Swagger spec - add the back-end service config Several app service entry points will request the latest data for a title, without passing in a revision ID. This means that we'll need to check for the latest revision in the RB revision table before requesting mobile app content from storage and the service. The current plan is also to store lead and remainder sections, both wrapped in JSON (see T102270). It might be desirable for the app service to return both in one JSON blob. The app will generally request the parts separately, but there is also the possibility of requesting both parts at once. In RESTBase, we can implement this by storing the service response as a single JSON blob. For lead / remainder requests, we can simply return the lead/remainder sub-objects, which are already parsed in RESTBase. Zero header support in Varnish (T102524) would be desirable, but likely won't be a hard blocker for the service roll-out. The main effect of this on the app is showing a 'you are browsing for free' banner, which might be okay to be missing in the beta channel.