When requesting https://en.wikivoyage.org/api/rest_v1/page/mobile-sections/Paris a sections property is present on both the lead and remaining objects.
This information is not necessary. Is there a reason we include it?
It would be preferable to have lead section handled in special fashion. Rather than querying for
input.page.sections[0].text it should simply be available on a text attribute on the lead.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Drop sections property, add text property on lead | mediawiki/services/mobileapps | master | +15 -9 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T169242 Develop Page Content Service for Reading Clients | |||
| Duplicate | None | T146944 Mobile-sections replacement | |||
| Resolved | Jdlrobson | T145006 Do not duplicate sections property on lead and remaining |
This comes from the fact that the Android app uses a two step loading process for every page. In the first request (the -lead request) the app also want to know the section titles to build the ToC. That's why the lead response also contains the information needed for that. The -remaining response contains only the text for the remaining sections.
RESTBase stores the full response (lead + remaining) in Cassandra but not the lead and remaining responses. When a request for lead or remaining comes to RB it just pulls out the JSON from the respective property.
If we're making a whole new endpoint, or backwards-compatibility breaking changes otherwise we could consider moving the lead section text up.
Change 309219 had a related patch set uploaded (by Jdlrobson):
Drop sections property, add text property on lead
Change 309219 merged by jenkins-bot:
Drop sections property, add text property on lead