AnsweredAssumed Answered

Patterns for Internal API Consumption

Question asked by acalbazana on Dec 12, 2018
Latest reply on Dec 18, 2018 by Sascha Preibisch



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:


  1. 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? 
  2. 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.
  3. Is there any guidance on partitioning gateways - For example - one gateway for internal use, one gateway for external use.
  4. 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.