We are currently working with a headless approach and I'm trying to estimate pros & cons of having more selectors in addition to 'model' at the cq:Page component. After digging through the request log and basically discovering what @Jörg_Hoh also mentioned here: https://cqdump.wordpress.com/2019/01/07/how-does-sling-resolve-an-aem-page-to-the-correct-resource-t... some special magic included within the cq:Page component redirects requests with special selector 'model' to the page-content where the sling-model-exporter ist registered.
It is easily possible to register sling-model-exporters to component-nodes if they have a proper sling:resourceType set but would it make sense to have this option on the page level too? Any dispatcher or security related issues maybe?
/content/somepage.customselector.json doesn't ?
If I understand you correctly, you would just start registering customer exporters as selectors selectors to the cq/Page resourcetype.
Technically I don't see a problem with that, but just be aware, that I can execute this exporter on pages where it shouldn't work. That means you need to write some code to ensure that this exporter is just executed on the right "type" of page, and not on any page. If you register that SME directly to the correct resource type, Sling does that for you.
sling models work for page as well, if you do like /content/weretails/en.model.json
But if you looking for something custom, then it should be validated in terms of performance and error handling.
I tried to created similar just for fun - https://aemlab.blogspot.com/2019/07/get-json-response-of-aem-page.html