I'm tagging Page content service, though I'm not sure that is correct. But its hard to figure out what software is responsible for what parts of the rest api.

The extract at https://es.wikipedia.org/api/rest_v1/page/summary/Anexo%3ADivisi%C3%B3n_pol%C3%ADtica_de_Am%C3%A9rica is empty

The issue is this line:
https://gerrit.wikimedia.org/g/mediawiki/services/mobileapps/+/1d43564574963a56842798e594f971b79e220855/lib/summary.js#12
https://gerrit.wikimedia.org/g/mediawiki/services/mobileapps/+/1d43564574963a56842798e594f971b79e220855/lib/summary.js#55

I think summaries should likely be enabled of all namespaces. This would be useful on mediawiki.org for example. It should be up to the client to decide whether to use them or not.

Git history leads back to T187091: Summary: stop responding with 204s by @phuedx and @Mholloway

I think it's actually further back than that. Page previews was never intended for non-main namespaces, so it was never implemented and the concern was that certain namespaces would not work well e.g. consider a JSON or Wikisource book namespace.

At this point, I think it makes sense to expand this to several namespaces that community have expressed a desire to use e.g. Skin and Extension on mw.org and MediaWiki namespace as is suggested here.

In T301153#7691504, @Jdlrobson wrote:

I think it makes sense to expand this to several namespaces that community have expressed a desire to use e.g. Skin and Extension on mw.org and MediaWiki namespace as is suggested here.

I agree.

It's been noted elsewhere that extending Page Previews could be made easier/more MediaWiki-like. I think that this could be a good opportunity to fix this. However, this would dramatically increase the scope of this task and so should probably be done before or soon after this change – otherwise we'll find ourselves with too many Page Previews summary generators to port!

The short version is:

1. We port the summary generation code to PHP
2. We allow extensions to register their own summary generation code via MediaWiki's extension attributes
3. We expose the above via MediaWiki's RESTful API framework