Kickstart on API Management with JBoss Apiman 1.0

The JBoss apiman project hit its first public milestone release (1.0.0.Final) recently, making it the perfect time to go out and have a look at it! Now that the first public release is out the door, we’re planning on iterating quickly on new features and bug fixes.  You should expect to see apiman community releases at least monthly.

Getting Started with apiman
So how can you get started with apiman?  I’m thrilled you asked!  There are already a number of articles and videos discussing apiman functionality and concepts.  So let’s start with some links:

• All things apiman
• Installation, User, and Developer guides
• Tutorials and walkthroughs (short videos - good place to learn about apiman)
• “An Impatient New User’s Intro to apiman”
• API Management On WildFly 8.1 with apiman

The 1.0 release of apiman can be easily run as a standalone server, running on WildFly 8 out of the box.  However, the runtime component (policy engine) can also be embedded into other projects. This is useful if you want to add API Management functionality to your existing API platform.

There’s Already a 1.0.1?
We didn't waste any time resting on our 1.0.0.Final laurels!  We got right back to work after the first release and added a bunch of new stuff (and fixed a few bugs, for good measure).  Early in January we came with 1.0.1.Final, which adds a bunch of stuff, including:

• Public Services (services that can be invoked without a Service Contract)
• Support for multiple API Gateways (although a single gateway usually makes the most sense)
• Retiring of Services and Applications (removed from the API Gateway)
• New Policy:  Ignore Resources (use regular expressions to prevent access to specific parts of your API)
• Version cloning (no longer a need to re-create all your configuration when making a new version of a Service, App, or Plan)
• First stab at a highly scalable vert.x based API Gateway

(read more)

What are Public Services?
One of the new features that some users will find really helpful is the concept of a “Public” Service.  A public service is one that can be invoked without a Service Contract.  In fact, if you only use public services in apiman then there isn’t any reason to create Applications!  This can be very useful if you are only looking to add policies to your services, but not interested in tracking which applications are invoking it.
(read more)

Why is Version Cloning Important?
An important feature of apiman is the ability to have multiple versions of Plans, Services, and Apps.  But whenever a new version of one of these entities is created, it is often necessary to tweak only a small part of the configuration.  For example, if a new version of a Service is released into production, then a new version of it may need to be created in apiman.  But all of the policies and plan probably still apply to the new version - only the Service Implementation endpoint details may have changed.  Now you can clone all of this information whenever you create a new version, saving you the hassle of re-entering all of that config.  Just clone what you had and change what you need.
(read more)

Why Have a vert.x Gateway?
For many users, having the API Gateway running in WildFly 8 is no problem.  We can handle a lot of load using WildFly, and scaling it up to moderate usage levels isn’t too hard.  However, asynchronous systems are designed to scale out to very heavy load, so we designed our runtime Policy Engine to have an asynchronous API to take advantage of these types of systems.  The latest version introduces an asynchronous API Gateway based on the very nice vert.x platform.
We’ll be doing a lot more work on this in the future, but for now it’s a great start and very exciting! We’re hoping that this solution will eventually be used in very large deployments (once we work out some of the details).