I'd like to get some guidance from the community on how to deal with internal clients. In our organization, we have a number of legacy, internal, APIs that I'd like to get provisioned under API management. My motivation for this is to establish a portfolio of managed services and to gain visibility of consumption. However, I have a couple of questions:
- Does it make sense to register API clients for every consumer when APIs are internal? I see pros/cons to doing this. The primary advantage is that I can tell who is calling. However, the disadvantage is that I have a proliferation of API Keys to manage. Does anyone deal with internal clients differently than external?
- How granular do you go with issuing API Keys? I'm looking for guidance in situations where logical clients have multiple components that participate in consumption. For example, I might have a web application that consumes services which may have a separately deployed component that also consumes. I was leaning towards issuing one key per "logical" client. I just wanted to check my thinking.
- Is there any guidance on partitioning gateways - For example - one gateway for internal use, one gateway for external use.
- What patterns exist for establishing trust relationships between gateways and backend services? I'm interested in prohibiting direct access to services, but I can see arguments for allowing access (e.g. - testing, monitoring). What have you done if you could share?
Appreciate any feedback.