The latest from the Apiman Blog

In this, the sixth article in the series on apiman, JBoss' new API Management framework, we’ll examine how apiman enables you to govern access to managed APIs through the use of rate limiting policies.

The runtime core of apiman is the API Gateway and the policies that it applies to incoming requests to APIs. apiman is configured out of the box with a variety of policies that can be used to govern access to APIs managed by the API Gateway based on IP address, user authentication, and usage levels. From its first release, apiman has supported rate limiting policies, where the upper limit for use of an API could be governed by a policy. In its new 1.1.6 release, apiman has expanded this support to include quota based limiting policies.

In this, the fifth article in the series on apiman, JBoss’ new API Management framework, we’ll examine how apiman enables you to provide security for your managed APIs at the policy level, and at the endpoint level for its managed and unmanaged endpoints.

As you may know, apiman has long supported custom policies provided by users. If you aren’t familiar with apiman plugins, you can find more about them by clicking here.

As of version 1.1.5.Final, plugins are now even more useful. You can provide custom implementations of various core apiman system components via plugins. This allows users to customize apiman easily, without any changes to the classpath and without rebuilding the core apiman application.

In this blog post I’ll explain how it works.

This article aims to provide a short guide on how to get API Management capabilities provided by apiman to work with JBoss Fuse, a lightweight, flexible, integration platform that is based on Apache Camel, an implementation of many of the most commonly used enterprise integration patterns (EIP).

A core feature of any good API Management solution is the recording of and reporting on interesting metrics related to API requests. Because apiman acts as a central Gateway for all managed API traffic, it is the perfect location to record information about each and every request. This allows it to report on interesting data it has recorded, related to response times, successful vs. failed requests, total number of requests broken down by time, consumer id, or plan used. As you can imagine, this is extremely valuable information, and it is a bit embarrassing that we haven’t offered this functionality until now!

But that gap is finally filled with version 1.1.4.Final.

I had the pleasure of presenting on apiman at the recent Microservices Architecture Developer Day, with our colleague Kurt delivering a short demo of our software running within Fabric8. It was particularly enjoyable meeting developers who are interested in, or are already using, apiman - so, thank you for your insightful questions both during, and after, the presentation.

Given the packed schedule, there was a limited amount of time to explore apiman plus microservices, and hence this seems like a good opportunity to write a blog post expanding upon the themes I touched upon.

So, if you’re interested in understanding the value API management can have in a microservices architecture; please, read on!

In this, the fourth article in the series on apiman, JBoss' new API Management framework, we’ll examine how apiman enables you to not just manage APIs, but implement a layer of security to the APIs by adding an authentication requirement when client apps access a managed API.

For those of you who might be interested in hacking away at some core apiman code, I thought it might be nice to create a reasonably comprehensive step-by-step guide. For the most part everything is straightforward, but there are a copule of tricks you can use to get up and running fast and to be able to easily iterate on any changes you make.

Read on if this sounds like something you want to do!

One of the weaknesses we’ve had in apiman until now is that API providers didn’t have any way to document how to consume their APIs. Well that has all changed with version 1.1.3.Final. Now you can upload a Swagger spec document for your API. If you do, consumers will be able to browse your API documentation directly in the apiman UI.

I think we can all agree that this is a welcome change and really improves the usability of the system, particularly from the perspective of the client app developer (aka the API consumer).

In this, the third article in our series on apiman, JBoss' new open source API Management framework, we’ll examine apiman’s API Manager REST API. apiman’s Management UI utilizes this API in the implementation for all of its user-visible features, and you can also use the same API to automate tasks with apiman.

If you have tried creating your own custom apiman policy, you may have had a bit of difficulty creating useful JUnit tests for it. Many policies require various apiman runtime components to be available. It can be super annoying trying to use something like mockito to create mock versions of everything your policy needs. Even for simple policies you really just want a quick and effective way to test the implementation within a reasonably "real world" harness.

Well you’ve probably guessed by now that I’m about to show you how it’s done! (OK fine, how it will be done in the next release of apiman - 1.1.3.Final)

Quite a bit, actually. :)

I want to talk about how Authorization currently works in apiman, because it’s a little more loosely coupled than you might expect. Note that at some point in the future we’re going to be renovating how policies are defined and configured in the API Manager UI. But until then, you can refer to this blog post for an overview of how to configure Authorization!