The more we complicate the topology of the API workflow, the more complex the debugging activity around it will be. Now imagine this scenario:
The user calls
https://api.cloudmakers.xyz/api/v1/users
.v1
in the URI determines that the backend URI,https://cm-api-v1.azurewebsites.net
, has to be called.APIM performs some activities (due to the policies) and calls the backend service.
After that, it calls another service to compose the response and returns it to the client.
Now, suppose that the client has an error code and we need to determine where it occurred:
Has it happened on the V1 side?
Has it happened in the Utility service?
Has it happened on the APIM side (due to policy execution errors)?
The first instrument we can use to diagnose what happened is the API inspector of APIM, a feature that traces calls in order to troubleshoot the pipeline.
If we can replicate the error conditions (hopefully), then we can call the APIM endpoint, specifiying an additional header...