Problem Space
I have recently been working on an API scoped policy within API Management, the policy ideally should not be impacted by any policies defined higher up in the hierarchy.
For reference, this means that any policies defined at the Product, Workspace, or Global level will not be inherited at the API scope for the given API Definition. See diagram below:
Ideally this means that my API traffic will start at my non-hierarchical policy definition, conduct any policy processing prior to being sent off to the backend, and then sent back to the calling outbound system.
Example Policy definition with the removal of
<base />which indicates inheritance:<policies> <inbound> ... </inbound> <backend> ... </backend> <outbound> ... </outbound> <on-error> ... </on-error> </policies>
In practice this is not what happened.
The API that I had defined should have successfully returned with a Status Code of 200 and a Json Payload. However, what I actually received was a successful API run with a return of Status Code 200 but no Json Payload.
Further investigation into this highlighted that the API request was never making it out to the Backend.
This being the case, a reviewal of the higher scoped policies showed that there was indeed a policy that is core to the APIM reverse proxy behaviour, and I had excluded this due to my lack of inheritance.
Offending Policy that was excluded due to my lack of inheritance
<backend> <forward-request /> </backend>
For reference, the forward-request policy forwards the incoming request to the backend service specified in the request context. And more importantly the policy is included in the Global Backend Policy by default.
Conclusion
Two things came from this,
- I fixed my problem by applying the forward-request policy in my API policy definition.
- More importantly, Always review hierarchical policies when removing inheritance as there may be behaviour that you will require, even if you didn’t place it there.