When you start out creating a Multi-Protocol Gateway (MPGW) or a XML Firewall (XMLFW) to handle REST based API calls you soon realize that you will end up with a ton of Rules and quite complex Matching Actions and you also probably will have a hard time sorting them correctly (not to mention trying to match Response rules and Error rules to the mess).
Well, DataPower was never really intended for REST/CRUD operations but relied on SOAP/XML as POST or GET only so there is bound to be some "mess" in there implementing CRUD operations...
You will also probably note that you are reusing a lot of Actions/Code between all the rules. You have the option of "Reusable Rules" using the Call Processing Rule to alleviate this but IMHO this becomes quite messy, especially if you have many rules and it can also become difficult to update as you don't know what Rule is called where.
Instead, I normally take one of two options which I call, "Reusable Service" or "Switch Action" (and, yes, I've made up those names myself so you won't find it in the DataPower documentation)...
The "Reusable Service" is something I have implemented for many customers and I normally use a XML Firewall in Loopback for it (but a MPGW will work too). You can have many different functions in there, e.g. logging, transformation, validation, etc. and then you have a "simpler" URL-Open() call to this service in each rule. You can lock down the XMLFW to only listen to 127.0.0.1 and thus make it isolated. This will still force you to add the call to each and every Rule but maybe you can add the URL-Open() to an existing GWS or shared script to make it a little bit less arduous...
The other (better?) approach which I have used for "REST" based gateways is to code a "Switch Action". You then set fewer rules (or maybe even just one) but I try to have one rule per HTTP Method and then in the first Action I add a GWS which (can log via "Reusable Service") looks at the URI (normally) and/or Header and run a Switch() to load a specific GWS module. Each GWS Module is named according to the Switch() so it is easy to keep track and the "Switch modules" can call other shared modules in turn making your code cleaner (and smaller). The advantage of this is of course fewer rules and more efficient code but you loses some oversight (graphically) but as you have the modules separated matching your previous Rules you can get a grasp just by looking at the GWS files included. If you add one GWS directory per Service/Method/Rule you'll have an even easier task over viewing (or adding) code.
local:///GWS/MyMPGWRestGW/index.js <-- This is your main script
In a DataPower firmware released sometime soon I hope (there is an open demo already) we will get a new service called "API Gateway" which might be usable in these kinds of scenarios. I don't have much information that I can share but if you grab the demo (a Docker setup) you can access the DataPower running it and see the new API Gateway service in action: https://github.com/ibm-apiconnect/apigateway-experimental
With that in mind there might be better tools for us soon to create these kinds of scenarios... NB! Note the MIGHT as we can't know what will actually be released or if we can use it as a Service or if it will be dedicated for API Connect only!