X

PaaS Partner Community

The Se7en Deadly Sins of API Design by Luis Weir

Juergen Kress
PaaS & Middleware Partner Adoption
image

During Oracle Code One 2018 (formerly Java One) I was lucky enough to deliver a funny yet insightful presentation titled "The Seven Deadly Sins of API Design" focused on API design anti-patterns and how to overcome them.

The presentation was partly inspired by Daniel Bryant presentation titled 7 Deadly Sins of Microservices but really focused on API design and API-led architectures, not so much on Microservices (though the too are related so some coverage was inevitable). But my main motivation was really around the fact that we're all sinners when it comes to making mistakes. When I first started designing REST APIs (or before that SOAP/WSDL based services), I myself made so many mistakes. However the main thing is to learn from them. And not just from our own mistakes, but that of others. So my presentation is about this, shortlisting the seven most common pitfalls on API design and architectures and then using the deadly sins as a vehicle to tell a story on how to "deliver us from evil".

The 7 deadly sins, also known as capital sins, represent corrupt and/or perverse versions of love. In this case, corrupt or perverse APIs. Following a description of each deadly sin including a description of what anti-pattern I went for on each:

  1. Lust: unrestrained desire for something. In this sin I talk about why sometimes we focus so much in the implementation aspects of an API, but specially on what tools to us, and not so much on the usability of the API itself which also means getting feedback from the audience of the API to ensure the interface is fit for purpose and intuitive enough -something I refer to as API-design first.
  2. Gluttony: the over-indulge specially by over eating. I use this sin to articulate the fact that many API implementations end-up with several layers of middleware (e.g. mainly load balancers and multiple API Gateways) before an actual service endpoint is actually reached. This is bad for many reasons (e.g. added complexity, additional costs, etc) and my conclusion is that we should not just add layers on top of layers for no strong reason. In some scenarios it might be inevitable but as rule of thumb we should question any additional layer added on top of the service. For example, I think one API Gateway should be enough and is justified, adding another one? umnn...
  3. Greed: intense and selfish desire for something. In here I talk about how many times a frontend results in poor user experience consequence of chatty APIs that require several API calls in order to construct e.g. a single UI page. Instead, I talk about how to prevent this sin by implementing different patterns such as web-hooks and/or API composition (e.g. with GraphQL). Read the complete article here.

 

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

clip_image003 Blog clip_image005 Twitter clip_image004 LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.