Analytics and Stats for APIs by Phil Wilkins

The Oracle API Platform provides the means to examine statistics and slice and dice the numbers by application, gateway, duration and so on resulting in visually appealing graphical representations.  The way the analytics works means you can book mark specific views, so you can return the same report view with the relevant features as often as you like.  However, presently there is no data export option.

The question why would I want to export the information comes down to several possible use cases, all of which relate to cost management.  The API Platform will eventually have all the desired data views, but now something to help address the following:

• money-tization, we can see which consumer has been using the services by how much and then send the data to a companies accounting systems to invoice the users
• Ability to examine demand and workload over time to create a projection of the likely infrastructure – to achieve this the API statistics need to be overlaid with infrastructure and performance details so we can extrapolate API growth against server workload.

To address these kinds of requirements, we have taken advantage of the fact the API Platform has drunk its own Champagne as they say and made many of the analytics querying APIs publicly available.  As with the other API Platform tools, the logic has been written in Groovy, and freely available for use – we’ve covered the code through a Create Common license. 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.

Blog Twitter LinkedIn Facebook Wiki

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

Defining Boundaries for Logical Gateways on the API Platform a multi cloud / multi region context by Phil Wilkins

The Oracle API Platform takes a different licensing model to many platforms, rather than on CPU it works by the use of Logical Gateways and blocks of 25 million successful API calls per month. This means you can have as many actual gateway nodes as you like within a logical group to ensure resilience as you like, essentially how widely you deploy the gateways is more of a maintenance consideration (i.e. more nodes means more gateways to take through a maintenance process from the OS through to the gateway itself).

In our book (here) we described the use of logical gateways (groups of gateway nodes operating together) based on the classic development model, which provides a solid foundation and can leverage the gateway based routing policy very effectively.

But, things get a little trickier if you move into the cloud and elect to distribute the back end services geographically rather than perhaps have a single global instance for the back-end implementation and leverage technologies such as Content Delivery Networks to cache data at the cloud edge and their rapid routing capabilities to offset performance factors. 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.

Blog Twitter LinkedIn Facebook Wiki

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

The Se7en Deadly Sins of API Design by Luis Weir

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.

Blog Twitter LinkedIn Facebook Wiki

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

Podcast: On Microservices Design and Implementation by Bob Rhubart

"Like buying a Ferrari and towing it around with a horse."

That’s how Java Champion and Microservices Patterns (Manning Publications) author Chris Richardson describes the approach some organizations take to implementing microservices. It’s often a matter of faulty motivation.

In helping organizations around the world get started with microservices, the first question Chris asks his clients is, "Why do you want microservices?" The responses are often surprising. "I’ve talked to people who viewed microservices as magic pixie dust. You sprinkle it on things and everything will be better," Chris reports.

Another problem is the mistaken belief that the goal is microservices. "Microservices is a means to an end," Chris says. From a DevOps perspective, "there are two really good metrics," Chris explains. "One of them is deployment frequency, how often you’re deploying into production. The other one is lead time, the time from commit to deploy. To me, those are the two metrics that you should be optimizing. Microservices is the way to get there." Listen to the podcast 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.

Blog Twitter LinkedIn Facebook Wiki

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

API For Developers

Designing APIs

Great coding can’t overcome faulty design. If you want your APIs to earn their keep, start with solid design principles and practices.

• Promote Standards to Create Great APIs
• "Shoot now, ask questions later…" Is Not the Strategy for Great APIs
• When Creating APIs, Focus Your API Gateway on What it Does Best

Developing APIs

Take your APIs from planning to production with expert guidance from coders who have been there.

• How to Build an API Web APIs: A Pillar of Digital Transformation
• Part 1: From Modeling to Deploying an API
• Part 2: From Publishing to Consuming an API

API Management

This is where the rubber meets the road. Proper management will help ensure that your well-designed, expertly coded APIs will deliver.

• Third-Generation API Management: From Proxies to Microgateways
• Registries: Use Cases for API Management and Microservices
• How Microservices Drive the Demand for API Management

Get the API Kit 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.

Blog Twitter LinkedIn Facebook Wiki

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