Blog Posts subscribe
I’m delighted to announce that Apiman 1.3.1.Final is out, with several notable new features and improvements .
Last week we released apiman 1.3.0.Final. It’s been rather a long while coming, but hopefully you’ll be pleased with the improvements.
This release has some important new features, a substantial number of bug-fixes, and marks the official release of the Apiman Vert.x Gateway.
Importantly, this release has a lot of background work which has prepared the the ground for the upcoming initial community integration with 3scale, as outlined in previous blogs.
In this blog, we’ll outline a few simple tweaks you can make to improve the performance of the Apiman Gateway when running on servlet platforms (WildFly, EAP, Tomcat, etc).
Most of the focus will be on WildFly and EAP, but others will be more broadly applicable.
Naturally, these are very rough pointers and should merely be hints for areas that could prove fruitful. There’s no one-size-fits all approach to tuning, so always profile and keep tweaking to find the best settings for your workloads.
It’s been almost two months since Red Hat announced it was acquiring 3scale Technologies and turning the 3scale API Management solution into a Red Hat supported product. In that time, we’ve been trying to figure out some stuff for the apiman community. Here some of the things we wanted to suss out:
- How the apiman development team can best focus its efforts, now that 3scale will be the basis for Red Hat’s API Management technology.
- How to best support the existing apiman community going forward, given the restrictions on continued development of the apiman API Management solution.
- How can existing apiman users transition to a Red Hat supported API Management solution.
It doesn’t sound like much, but it actually really is. We’ve made some preliminary decisions, and because we want to be as transparent and upfront as possible, read on to find out what they are!
Because the apiman project is sponsored primarily by Red Hat, you may be wondering how this impacts the project and its open source community. In today’s blog post, I’ll do my best to answer that question as honestly and transparently as I can.
Greetings, earthlings! On Friday of last week we released the absolute best version of apiman ever! This release has a fair number of bugs fixed, as well as a few new things. Read on for the details!
In a world where APIs are quickly becoming the standard, most of us understand the importance of following best practices for API security. We authenticate, authorize and throttle requests. We encrypt the data that we share with other applications (hopefully!). But we often neglect one of the most essential components of the API layer: data storage.
In plenty of enterprises, networks are either locked down or have very limited access to the Internet; often for security, privacy or other practical reasons.
We’ve carefully designed apiman to be fully featured and easily configured when no Internet access is available; providing a great deal of flexibility and eschewing any "off-site only" functionality.
So, if you’re looking for API management in a locked-down network or Internet-free environment, read on!
In this post, we’ll examine apiman user roles. In the apiman data model, all data elements exist in the context of the organization. The same holds true for user memberships as users can be members of multiple organizations. Permissions in apiman are role based. The actions that a user is able to perform are dependent on the roles to which the user is assigned when a user is added as a member of an organization.
Greetings, earthlings! Yesterday we released the best version of apiman yet, and I’m not just saying that because the version number (1.2.3.Final) is awesome. This release has a bunch of bug fixes in it, as well as a few targeted new features. Read on for more details!
One of the less enjoyable aspects of apiman is the manual addition of an API that you wish to manage. And if you have a bunch of APIs you want to manage, you can either use the apiman REST interface to script the creation of them, or else you’re stuck manually entering them into the UI.
However, if you take advantage of the new API Catalog feature, things might get a lot easier!
One of the strongest features of apiman, in general, is its excellent extensibility. Not only is it easy to add new policies, for example, but many of its core components are also pluggable. This includes, for example, the registry used by the API Gateway to store configuration information published to it by the manager. This blog post will detail a new JDBC based implementation of that registry, explaining how you can store that information in a Database instead of in Elasticsearch (the default setting).
In a recent blog post I explained why APIs used to be completely frozen once they were published, and how we have loosened that restriction for Public APIs. Similarly, we did not allow Client Apps to be changed and then re-registered. This was never a good decision, since the Client App does not have anything “connected” to it (the way that an API may). So we should never have restricted the registration of a Client App!
An early design decision we made in apiman was to not allow APIs to be re-published to the Gateway. The reasoning was that Client Apps may have established Contracts with the API, and thus have agreed to specific terms and conditions (whether implicit or explicit). Therefore, we shouldn’t allow the API provider to modify those terms and re-publish the API, as it may violate the agreement.
However, we later added the concept of a Public API, which allows any client to invoke it without first creating a Contract. It is clear that API providers should be able to re-publish a Public API (presumably after changing the API’s configuration).
Apiman is not only preconfigured with a rich set of policies that you can use, right out of the box, but, from its earliest releases, apiman has also included a mechanism that you can use to define your own custom policies through plugins. This article describes the improvements introduced in apiman release 1.2.x that enable you to better manage your custom policy plugins.
The Question you Dread
If you use a computer at home or at work, you’ll eventually find yourself in a situation where you lose some important data and, while you are trying to recover it, someone asks you a question that is simultaneously annoying and terrifying:
“Did you make a backup?”
Happily, the 1.2 release of apiman includes a new feature that enables you to export and import your apiman data and provides you with an easy means to create apiman data backups. In this post, we’ll take a look at the new export/import feature, and how you can use it for a variety of tasks to protect your data, make your life easier, and enable you to avoid annoying and terrifying questions.
Recently we released version 1.2 of apiman and part of that release includes an effort to rename some concepts to make them more clear (or to better align them with industry standard terminology). Read on below the fold to find out what changed!
The last thing you want after carefully setting up your system with apiman is for someone to be able to call around the gateway and hit your APIs directly. The typical solution for this is to lock down your network so that the only publicly accessible part is the apiman gateway, whilst APIs are hidden in the private part of the network, which apiman can access, but not someone in the outside world. However, in some situations fine-grained network controls may not be available, such as the cloud; or, you may wish to have an additional layer of security to be reassured that no funny business is going on (such as imposters).
The class of solutions to this problem generally falls under the banner of mutual authentication. One such mutual auth offering apiman supports is Mutually Authenticated TLS.
One great advantage of API Management is centralising auth concerns, thereby avoiding burdensome reimplementation issues and streamlining your security processes. The good news is that you can easily configure apiman to handle many common auth use-cases, such as OAuth2 with our popular Keycloak OAuth2 policy which I’ll outline in this blogpost.
For those unfamiliar with CORS, it’s a way of precisely defining who and how a remote origin may invoke an API’s resources. Generally, due to the same-origin policy, a web browser will only allow the invocation of resources that reside on the same origin as the requesting page. This mitigates a range of malicious script attacks by preventing interaction with remote resources.
However, if we want our resource to be callable by some (or all) other origins, then we need to define a CORS policy which let’s user agent know what’s allowed.
It’s been ages since apiman had a new release! Well the reason for that is we’ve been pushing to get the first version of 1.2.x out the door. I’m here to tell you - that day has finally arrived.
We’re happy to announce apiman 1.2.1.Final. Our goal is now to go back to our previous, more frequent, release schedule.
Let’s spend a little bit of time learning more about one of the newer ways you can run apiman: as a set of micro-services.
Running apiman in this way has several advantages, including (but not limited to):
- Fast startup time
- Fully decoupled
- Easily debuggable from an IDE
- Quick to test different configurations
- Independently scale (esp. via fabric8/openshift/kubernetes)
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 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.
Quite a bit, actually. :)
I want to talk about how Authorization currently works in apiman, because it’s a little bit 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!
This is the second in a series of articles exploring API management with JBoss apiman. The first article was a general introduction to apiman for impatient users where in only 10 minutes we installed apiman, created users and organizations, and APIs, policies, contracts, and client apps. In this article, we’ll take the first step toward customizing apiman by creating new plugins to implement API policies.
Software application development models are evolutionary things. New technologies are always being created and require new approaches. It’s frequently the case today, that a service oriented architecture (SOA) model is used and that the end product is a software service that can be used by applications. The explosion in growth of mobile devices has only accelerated this trend. Every new mobile phone sold is another platform onto which applications are deployed. These applications are often built from services provided from multiple sources. The applications often consume these services through their APIs.
OK, that’s all interesting, but why does this matter?