API MANAGEMENT TOOLS: A WORLD OF NAILS AND SCREWS — API IMPLEMENTATION PART 2

The world has screws as well as nails.

  1. Receive a request
  2. Call downstream API x
  3. Call downstream API y
  4. Combine the results into a common format
  5. Return the result
  • For calling the downstream APIs, you may have an option of a circuit breaker policy — you may not.
  • The transformation to a common format may be simple, or it may be complex — it may perform poorly and impact other APIs being handled by the API management tool.
  • The “language” to implement the transformations or orchestration logic may be custom to your API management tool and therefore fewer developers can write it competently.
  • The logic to handle error conditions may need to be expressed as additional policies — these will require tests and probably mock APIs.
  • Should I add policies to log the parts of the API flow or should I simply rely on the logging which would be naturally generated from calling the downstream APIs?
  • Is there some information I need to mask or redact because of insufficient authorisation? How easy is it to express that in policies? How do I report on it for auditing?

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
digitalML

digitalML

Large enterprises use our ignite Platform for digital recombination, APIs & Services at scale, Rapid IT Modernization, and Business & IT alignment