Posts tagged with apiman

I’m delighted to announce that I have released Apiman 3.1.2.Final.

One particularly useful change I’d like to highlight is that the Vert.x Gateway’s API, when secured by Keycloak, now accepts a list of additionally accepted issuers using allowed-issuers, which is useful for users with more complex auth setups.

I’m delighted to announce that I have released Apiman 3.1.0.Final.

Aside from numerous bug fixes and a few interesting new features, this includes a security fix for CVE-2023-28640.

Due to an issue with the release pipeline, we ended up having to cut a 3.1.1.Final release also, but it’s identical to 3.1.0.Final.

I’m delighted to announce that I have released Apiman 3.0.0.Final.

This is one of the most significant releases in Apiman’s history, with a considerable number of new features and behind-the-scenes improvements.

There is also a new Docker Compose distribution that makes Apiman easier than ever to try out; please give it a go and let us know your thoughts.

Oh, and I’ve created a completely new Jekyll-based website for Apiman that will help me better automate releases — I hope you like it!

Happy Holidays, Apiman fans!

I’ve released Apiman 2.2.0.Final to upgrade Keycloak to 15.1.1 and WildFly to 23.0.2.Final. This is primarily because of another significant security vulnerability that has been disclosed in those platforms.

Hi, Apiman fans!

I hope you’re all well, and Season’s Greetings to those of you who celebrate Christmas 🎄.

I’d like to remind Apiman users to consider updating to Apiman 2.1.5 promptly, as it contains fixes for the now well-known log4j2 bugs.

I’m very pleased to say that we’ve released Apiman 2.1.0.Final 👏. We’ve splatted a huge number of bugs and made a lot of improvements to stability, performance, and security.

Please consult the migration guide here if you are planning to upgrade from an earlier version if Apiman (especially if you’re using Elasticsearch).

I’m happy to announce that Apiman 1.5.1.Final is out.

It contains an important new policy feature: the ability to modify policy failures before they are returned to users (even if they are thrown by another policy).

This means that policies such as CORS can add their headers, irrespective of whether the request was successful or not (e.g. due to rate limiting).

One common request we hear is how to create custom URL patterns for the Apiman Gateway.

For example, this means allowing changing the (Public API) default:

To a custom alternative. As a simple example we’re going to hard-code an organisation in. We’ll assume that we’ve established a convention to always publish our APIs to a particular org. That will change the pattern to:

Apiman 1.4.3.Final is out. It contains a couple of bug-fixes. Most notably, a bug in the Vert.x Gateway that prevented plugins specified in static config (conf.json) from being loaded properly.

I’m delighted to announce that Apiman 1.4 has been released (actually, 1.4.1.Final as of this blog post ^[1]).

The most important change in this release is that we’ve upgraded support for Elasticsearch from 1.x to 5.x. It may also support Elasticsearch 2.x, but this isn’t officially supported (let us know your experiences).

Apiman 1.3.5.Final is out and ready for you all to try.

This just contains some UI reversions, as we still have some tough-to-fix gremlins. We’ll bring the updates back once we’re able to fix the issues.

It contains all the same fixes and features as 1.3.4.Final.

Apiman 1.3.4.Final is out and ready for you all to try.

You may be wondering where 1.3.2.Final and 1.3.3.Final are; early community testing found some regressions, so we skipped formally announcing those.

I’m delighted to announce that Apiman 1.3.1.Final is out, with several notable new features and improvements ^[1].

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 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:

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!

As some of you have undoubtedly already heard, Red Hat recently announced the acquisition of 3scale, a commercial vendor of API Management software.

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 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!

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.

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!

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.