Change Details

== Intro/History/Motivation The web team would like to use the mobile-sections-* endpoints or similar in the future. The current implementation is lacking some features the web team would like to see, in order to adopt the endpoints for their use. @Jdlrobson has proposed a set of patches which would move some content out of the section text HTML portions and make them their own JSON properties or even a new endpoint (for the References sections). These changes would break compatibility with existing Android app clients, mainly because some content would be missing. Since we don't control when app clients get updated, we might have to keep old version alive for some time. == Proposed changes {{TODO: List concrete examples on what will be different}} == Goals of this discussion * In this task we would like to decide what a next major version of mobile-sections-* endpoint responses would look like, and how it differs from the existing version. * Let's see if we can even come up with better names for the mobile-sections-* endpoints. * Decide what version number we want (current version is 0.8.0). Should we jump to 2.0? I would like to also open this up to Android, iOS app devs, and any other potential users of the API, so we can come up with an API that can be used by many.

== Intro/History/Motivation The web team would like to use the mobile-sections-* endpoints or similar in the future. The current implementation is lacking some features the web team would like to see, in order to adopt the endpoints for their use. @Jdlrobson has proposed a set of patches which would move some content out of the section text HTML portions and make them their own JSON properties or even a new endpoint (for the References sections). These changes would break compatibility with existing Android app clients, mainly because some content would be missing. Since we don't control when app clients get updated, we might have to keep old version alive for some time. == Proposed changes (see subtasks) * Expose page issues in MCS endpoints * Infobox, hatnote and Lead paragraph should be first class citizens on "lead"… * Do not duplicate sections property on lead and remaining == Goals of this discussion * In this task we would like to decide what a next major version of mobile-sections-* endpoint responses would look like, and how it differs from the existing version. * Let's see if we can even come up with better names for the mobile-sections-* endpoints. * Decide what version number we want (current version is 0.8.0). Should we jump to 2.0? I would like to also open this up to Android, iOS app devs, and any other potential users of the API, so we can come up with an API that can be used by many.

== Intro/History/Motivation The web team would like to use the mobile-sections-* endpoints or similar in the future. The current implementation is lacking some features the web team would like to see, in order to adopt the endpoints for their use. @Jdlrobson has proposed a set of patches which would move some content out of the section text HTML portions and make them their own JSON properties or even a new endpoint (for the References sections). These changes would break compatibility with existing Android app clients, mainly because some content would be missing. Since we don't control when app clients get updated, we might have to keep old version alive for some time. == Proposed changes (see subtasks) {{TODO: List concrete examples on what will be different}}* Expose page issues in MCS endpoints * Infobox, hatnote and Lead paragraph should be first class citizens on "lead"… * Do not duplicate sections property on lead and remaining == Goals of this discussion * In this task we would like to decide what a next major version of mobile-sections-* endpoint responses would look like, and how it differs from the existing version. * Let's see if we can even come up with better names for the mobile-sections-* endpoints. * Decide what version number we want (current version is 0.8.0). Should we jump to 2.0? I would like to also open this up to Android, iOS app devs, and any other potential users of the API, so we can come up with an API that can be used by many.