Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Anatomy of API Call Failure

DZone's Guide to

The Anatomy of API Call Failure

Kin Lane provides a detailed diagram about API call failure, along with some questions to ask when trying to increase fault tolerance and resilience.

· Integration Zone ·
Free Resource

SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.

I have been spending time thinking about how we can build fault tolerance and change resiliency into our API SDKs and client code. I want to better understand what is necessary to develop the best possible integrations as possible. While doing my regular monitoring this week, I came across a tweet from @Runscope with a pretty interesting image on this subject crafted by @realm, a mobile platform for sync.

There is a wealth of building blocks here to apply at the client- and SDK-level, helping us achieve more fault tolerance and make our applications, systems, and device integrations more change resilient. I wanted to break them out, providing a bulleted list I could include in my research:

  • Is the API online?
  • Did the server receive the request?
  • Was URL request successful?
  • Did the request timeout?
  • Was there a server error?
  • Was JSON receive successfully?
  • Was JSON malformed?
  • Was there an unexpected response?
  • Were we able to map to JSON successfully?
  • Is the JSON valid?
  • Does local model match server model?

There are some valuable nuggets present in this diagram. It should be crafted into some sort of algorithmic template that developers can apply when developing their API integrations, as well as for API providers when developing the SDK and client solutions they make available to their API communities. I'm taking note so that next time I spend some cycles on my API SDK research I can help solidify my own definition.

This is a very micro look at fault tolerance when it comes to API integration, and I'm continuing to look for other examples of change resiliency at this layer. Is there a plan B for the API call? Is there revenue ceiling considerations? Are there other more non-technical, business, and political considerations that should be baked into the code as well to help us all think more deeply around how we encourage change resiliency across the API community?

Download A Buyer's Guide to Application and Data Integration, your one-stop-shop for research, checklists, and explanations for an application and data integration solution.

Topics:
integration ,api ,api calls ,call failure

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}