[Feature Request] Option to disable/enable transformation for specific routes or requests

[GregorSondermeier]

Hi,

this plugin was just presented in the Strapi Community Call and it looks potentially very useful to solve a problem that my team currently faces:

We're currently migrating from v3 to v4.
I understand that v4's API responses are structured significantly different from v3's API responses and it looks like your transformer plugin brings v4's API responses closer to the format that v3 returned. This could potentially simplify the refactoring that is needed in our applications that consume data from Strapi or at least allow us to do it step by step.

Would it be possible to enable or disable the response transformation executed by your plugin by route (e.g. with a more atomic configuration) or by request (e.g. by providing a certain request header)?

[ComfortablyCoding]

Hello,

Appreciate the interest!

Yes, this should be possible. A request header that indicates that transformation should be skipped sounds fairly easy to implement. At the moment I am considering using Strapi-Transformer-Ignore as the header name. Let me know if you have any recommendations.

Eventually an allow/block list can also be added but that will require more work/thought before implementing.

[GregorSondermeier]

Request header name Strapi-Transformer-Ignore sounds good.

Benefits would be:

• I could install and use the plugin to have API responses close to the v3 format, which reduces initial refactoring
• One by one, I can go through my API requests, add that header and do the refactoring
• Once I'm done, I can uninstall the plugin, or keep it where I need it

Just one more question before settling on this:
Could the prefix configuration property be used for that aswell? Instead of providing a string, it could be a list of strings or a regex that defines which API routes should generally be transformed and which do not. Would provide another level of flexibility.

[ComfortablyCoding]

The prefix property is meant to define the top level endpoint for the api, regardless of any routes. It needs to stay as is.

In terms of the allow list it would be a seperate property in the settings as it's responsible for a different functionality. Most likely named allowList which would take an array of routes that the plugin should transform.

I will need to research and see how feasible it is to allow regex type routes (/pages/*) and such instead of hardcoding the full route path each time.

[GregorSondermeier]

Thanks for the reply, it makes sense and I agree.

[ComfortablyCoding]

Closing in favor of #36 and #37 discussions.