SOA Tech Magazine

Recently I've noticed some good discussions in the API community around what API Product Management actually is and what it entails. Of the content I've come across I can highlight  What is API Product Management by Bruno Pedro and Erik Wilde and  What API Product Managers Need by Deepa Goyal and Kin Lane.  Given that in Oracle Hospitality I am responsible for leading an entire API and Integration Product Management organisation which manages / oversees over 3k API capabilities and over 2k postman collections publicly available, naturally this topic is of huge interest to me and perhaps needless to say I have my own opinionated views on it which is why I decided to write this blog. As Erik said in his opening statement " A lot of people are talking a bout API Product Management but I still think a lot of people are not actually practicing API product management ", I think this is true in many different ways being one of the main reasons the fact that not everyone is

When it comes to push technology, there are LOTs of options out there. And I do mean lots. The market is hot as you can clearly see in the following picture from my Event driven API Strategies presentation at Nordic API 2019 submit. However what technology and/or approach to adopt really depends of course on the use case in question and the targeted business benefits for both API producers and consumers. For example we at Oracle Hospitality recently announced a  GraphQL Subscriptions   / WebSocket based Streaming API for business event push. Details of the announcement here . Overall our Streaming API is being extremely well received and there is a huge amount of excitement in our vendor and customer communities alike about it. This is great to see of course given the amount of time and effort that was put into delivering this strategy. That being said, There has has been a few questions as to why we didn't opt for the more traditional Webhook approach.  This article by James N

This morning whilst going through my emails, noticed in my inbox an email titled T he 2020 State of the API Report Is Here . As an API author, practitioner and product owner, this immediately caught my attention and naturally went straight into reading the content of the email. And well, what I read did not disappoint. The report is the result of interviewing more than 13.5k industry professionals who are in one way or another dealing with APIs. Kudos to  Postman  and the  API Evangelist  for this remarkable contribution (and all of the effort am sure went into putting this together). Here is the link to the report: https://www.postman.com/state-of-api/ Following my own thoughts / remarks whilst literally going through the report section by section. I am sharing it in case anyone may finds it interesting. I just want to reiterate that these are my own thoughts so you may or may not agree, and that's ok! Key Findings Broadly agree with all key findings, however there was one conclus

Application interfaces are as old as the origins of distributed computing and can be traced back to the late 1960's when the first request-response style protocols were conceived.  For example,  according to this research, it wasn't until the late 1980's when the first popular release of RPC (described below) was introduced by SUN Microsystems (later acquired by Oracle), that internet-based interface protocols gained wide popularity and adoption. This is perhaps why the term Application Programming Interface (API)  even today can often result in ambiguity depending on who you ask and in what context. This is probably because of the fact that historically the term API has been used to (and to a degree continues to) describe all sorts of interfaces well beyond just web APIs (e.g. REST). This article therefore attempts to demystify (to an extend) the origins of modern web-based APIs. This is done by listing and describing in chronological order (as illustrated below) the