In T313265#8653252, we discovered a potential blocker for switching over mobile-html from RESTBase to the REST API.

Right now, apps "render" non-wikitext content models like "javascript" improperly since the RESTBase-Parsoid combo treats non-wikitext content models as wikitext and generates some output for those content models. The output may not necessarily be what is desired, but at least for some content models (like JS and CSS), the output may be mostly correct which is why this may not have noticed in the iOS and Android apps so far (combined with the fact that most folks will probably not look at these other content-models in the apps).

But, the REST API has a harder fail when requested to render non-wikitext content models. It returns a HTTP 400 (see T324711). So, this means when the mobile-html services switch from RESTBase to the REST API, all requests for these non-wikitext pages will now fail or render some error message in the iOS and Android apps.

So, before switchover, some adaptation solution would need to be devised to deal with this. There could also be an argument to be made for the REST API to provide an endpoint that transparently falls back to non-Parsoid rendering for these content-models (new endpoint or query param to an existing endpoint or a http header or whatever seems appropriate). Alternatively, mobile-html will need to handle this. OR, the apps will need to handle this (if they don't intend to handle non-wikitext content models, by displaying an appropriate error message).

This task is likely a blocker to switchver