From eric.wittmann at redhat.com Wed Jan 7 16:24:09 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 07 Jan 2015 16:24:09 -0500 Subject: [Apiman-user] Released: 1.0.0.Final of API Management Message-ID: <54ADA3F9.6050003@redhat.com> The apiman team is happy to announce that version 1.0.0.Final has been released! Now that we've got the initial public release done, we're hoping to get a couple of releases done per month from now on. Information, tutorials, documentation, downloads etc can all be found here: http://www.apiman.io/ Lots of work to do, but it's a good start! -Eric From eric.wittmann at redhat.com Thu Jan 8 10:18:14 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 08 Jan 2015 10:18:14 -0500 Subject: [Apiman-user] Released: 1.0.1.Final Message-ID: <54AE9FB6.1040906@redhat.com> What? You mean there's a 1.0.1.Final version out already?! Well it turns out that we released 1.0.0.Final back in December, but we didn't really announce it for fear of it getting lost in the holiday shuffle. So we've actually had some time to work on bug fixes and new features for 1.0.1.Final. And now it's out, so you can enjoy the new stuff. Have a look at the roadmap for the full list of what's new: http://www.apiman.io/latest/roadmap.html But I would say that the biggest change is that you can now optionally mark a Service as "public", which means clients can invoke it without first creating a Service Contract! This adds a dramatically simplified use-case to what apiman supports. http://www.apiman.io/latest/user-guide.html#_services -Eric From eric.wittmann at redhat.com Mon Jan 19 08:46:50 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 19 Jan 2015 08:46:50 -0500 Subject: [Apiman-user] APIMan - questions / use-case In-Reply-To: References: Message-ID: <54BD0ACA.6020508@redhat.com> Hi Anton - thanks for the note. :) I checked the mailing list subscriber list and you are there, so perhaps it worked. I'm CC'ing the mailing list on this reply. As a matter of fact, custom policies is a very important feature of apiman. That said, version 1.0.1.Final (the current latest) does not support an *easy* way to create a custom policy. It is possible to do it, but you need to add your custom classes to the classpath of the API Gateway. The good news is that the next major version of apiman (1.1.0.Final) will include a plugin feature that will allow you to easily contribute plugins (which contain custom policies). I don't have a release date yet for when we will move from 1.0.x to 1.1.x. However, because you have shown interest in the feature, what I can do is move the feature from 1.1.x to 1.0.x. So it will be released in the next minor release of apiman (1.0.2.x). Sorry if that was confusing. The bottom line is that I will backport the plugin feature from 1.1 to 1.0 so that it will be available in the next release (1.0.2.Final). I will also make sure to thoroughly document it in the Developer Guide before doing the release. Until all of that happens, you can have a look at *how* to create an apiman plugin by going here: https://github.com/apiman/apiman-plugins/tree/master/test-policy An apiman plugin is a WAR with a little bit of extra sauce. Specifically it needs a file here: META-INF/apiman/plugin.json Example: https://github.com/apiman/apiman-plugins/blob/master/test-policy/src/main/apiman/plugin.json Additionally in order for your custom policy (or policies) to be discovered you need one or more file in: META-INF/apiman/policyDefs/ Example: https://github.com/apiman/apiman-plugins/blob/master/test-policy/src/main/apiman/policyDefs/test-policyDef.json -Eric On 1/19/2015 3:04 AM, Anton Hughes wrote: > Hi Eric > > Firstly, thank you for your excellent work on APIMan, and Overlord. Two > really exciting projects. Its really great to see how these have developed. > > Secondly - I tried to subscribe to the mailing list, but I never > received a confirmation, so excusing me for writing to you directly. > > And thirdly - a question! > > *Custom Policy Types* > Is it possible to create a custom policy type? > > Our use case is, the more our business partner calls a method, the more > of a discount they get. To elaborate, when they call the > 'buySubscription()' method from > > * 1 - 20x they get 0% discount > * 21 - 40x they get 3% discount > * 41 - 60x they get a 6% discount etc > > > (note to self - could be good to use Drools decision tables for this). > > Then, when they call 'cancelSubscription()' we need to reduce the count > and re-calculate. > *Do you have documentation - or can you point us in the right direction > to learn about developing a custom policy type?* > * > * > Thanks Eric! > * > * > * > * > > > > > > > -- > * > > ** > > * > * > > Anton Hughes > > Co-founder > > ah at magick.nu > > www.magick.nu > > > > > > * > > > * > > ** > > * From eric.wittmann at redhat.com Thu Jan 22 07:06:02 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 22 Jan 2015 07:06:02 -0500 Subject: [Apiman-user] APIMan question In-Reply-To: <6E8E80FD-C8C3-4FF8-BAD0-AF538975B926@mcwhirter.org> References: <6E8E80FD-C8C3-4FF8-BAD0-AF538975B926@mcwhirter.org> Message-ID: <54C0E7AA.6070902@redhat.com> Hi Bob, thanks for the question. I have CC'd the apiman mailing list in case the answer is interesting to others. Hopefully I understand the question, which is around aggregation of various disparate APIs into a single application specific API. I think that apiman does something similar to what you are suggesting, in that all API endpoints end up going through the API Gateway rather than directly to the various disparate services. In other words, if a single application may consume N different services provided through apiman, *all* of those services are ultimately consumed through the root API Gateway endpoint (e.g. http://gatewayhost.com/api-gateway/*). That isn't quite the same as creating an application-specific API, but is perhaps functionally equivalent. At the moment we do not have any specific plans to implement API aggregation in apiman, but if there were community interest in it then we would certainly consider adding it to the roadmap. :) -Eric On 1/21/2015 1:44 PM, Bob McWhirter wrote: > Heya Eric? > > So I?m looking into Microservices, and one thing that always pops up is an "API Gateway? which might consume N services and expose them as a single service. > > The use-case being that while a fat application (desktop, web, etc) might talk to 15 different services, something on a constrained network (such as Mobile) would rather have an application-specific API that handles aggregating some subset of those 15 services into a single service, reducing round-trips. > > Is this a use-case planned for by APIMan? Or would APIMan be placed in front of an API Aggregator? > > Thanks! > > -Bob McWhirter > From jorgemoralespou at gmail.com Thu Jan 22 09:56:55 2015 From: jorgemoralespou at gmail.com (Jorge Morales Pou) Date: Thu, 22 Jan 2015 15:56:55 +0100 Subject: [Apiman-user] APIMan question In-Reply-To: <54C0E7AA.6070902@redhat.com> References: <6E8E80FD-C8C3-4FF8-BAD0-AF538975B926@mcwhirter.org> <54C0E7AA.6070902@redhat.com> Message-ID: Hi Bob, This is usually solved at the application layer with a BUS doing this API composition. Then APIMan would expose that API instead of the multiple internal APIs. If apiman was combined with Fuse or camel, this could be done, but I do not think that would be an easy feature. Usually is best to place that logic into a BUS layer, and then expose that service as well as an aggregated service, this way you could expose all the single services and the aggregated one. Cheers, 2015-01-22 13:06 GMT+01:00 Eric Wittmann : > Hi Bob, thanks for the question. I have CC'd the apiman mailing list in > case the answer is interesting to others. > > Hopefully I understand the question, which is around aggregation of > various disparate APIs into a single application specific API. I think > that apiman does something similar to what you are suggesting, in that > all API endpoints end up going through the API Gateway rather than > directly to the various disparate services. > > In other words, if a single application may consume N different services > provided through apiman, *all* of those services are ultimately consumed > through the root API Gateway endpoint (e.g. > http://gatewayhost.com/api-gateway/*). > > That isn't quite the same as creating an application-specific API, but > is perhaps functionally equivalent. > > At the moment we do not have any specific plans to implement API > aggregation in apiman, but if there were community interest in it then > we would certainly consider adding it to the roadmap. :) > > -Eric > > > On 1/21/2015 1:44 PM, Bob McWhirter wrote: > > Heya Eric? > > > > So I?m looking into Microservices, and one thing that always pops up is > an "API Gateway? which might consume N services and expose them as a single > service. > > > > The use-case being that while a fat application (desktop, web, etc) > might talk to 15 different services, something on a constrained network > (such as Mobile) would rather have an application-specific API that handles > aggregating some subset of those 15 services into a single service, > reducing round-trips. > > > > Is this a use-case planned for by APIMan? Or would APIMan be placed in > front of an API Aggregator? > > > > Thanks! > > > > -Bob McWhirter > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150122/a8417dad/attachment-0001.html From eric.wittmann at redhat.com Thu Jan 22 10:07:17 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 22 Jan 2015 10:07:17 -0500 Subject: [Apiman-user] APIMan question In-Reply-To: References: <6E8E80FD-C8C3-4FF8-BAD0-AF538975B926@mcwhirter.org> <54C0E7AA.6070902@redhat.com> Message-ID: <54C11225.7000403@redhat.com> I would also add that we are trying to be very careful about apiman's feature set. There is a risk of overlapping with other projects to the detriment of both. For example, service composition and request transformations are areas we want to stay away from as much as possible. There are better solutions out there for such problems. But obviously features will be evaluated as needed. :) -Eric On 1/22/2015 9:56 AM, Jorge Morales Pou wrote: > Hi Bob, > This is usually solved at the application layer with a BUS doing this > API composition. Then APIMan would expose that API instead of the > multiple internal APIs. If apiman was combined with Fuse or camel, this > could be done, but I do not think that would be an easy feature. > Usually is best to place that logic into a BUS layer, and then expose > that service as well as an aggregated service, this way you could expose > all the single services and the aggregated one. > > Cheers, > > > 2015-01-22 13:06 GMT+01:00 Eric Wittmann >: > > Hi Bob, thanks for the question. I have CC'd the apiman mailing list in > case the answer is interesting to others. > > Hopefully I understand the question, which is around aggregation of > various disparate APIs into a single application specific API. I think > that apiman does something similar to what you are suggesting, in that > all API endpoints end up going through the API Gateway rather than > directly to the various disparate services. > > In other words, if a single application may consume N different services > provided through apiman, *all* of those services are ultimately consumed > through the root API Gateway endpoint (e.g. > http://gatewayhost.com/api-gateway/*). > > That isn't quite the same as creating an application-specific API, but > is perhaps functionally equivalent. > > At the moment we do not have any specific plans to implement API > aggregation in apiman, but if there were community interest in it then > we would certainly consider adding it to the roadmap. :) > > -Eric > > > On 1/21/2015 1:44 PM, Bob McWhirter wrote: > > Heya Eric? > > > > So I?m looking into Microservices, and one thing that always pops > up is an "API Gateway? which might consume N services and expose > them as a single service. > > > > The use-case being that while a fat application (desktop, web, > etc) might talk to 15 different services, something on a constrained > network (such as Mobile) would rather have an application-specific > API that handles aggregating some subset of those 15 services into a > single service, reducing round-trips. > > > > Is this a use-case planned for by APIMan? Or would APIMan be > placed in front of an API Aggregator? > > > > Thanks! > > > > -Bob McWhirter > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > From eric.wittmann at redhat.com Fri Jan 30 13:40:40 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 30 Jan 2015 13:40:40 -0500 Subject: [Apiman-user] Announcement: apiman version 1.0.2.Final released Message-ID: <54CBD028.5030806@redhat.com> We're happy to say that version 1.0.2.Final of apiman went out the door yesterday. For a full list of what's new/fixed go here: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12314121&version=12326491 The most interesting new feature is probably the plugin framework. Plugins can now be created that contribute new policies, allowing users to easily provide custom or enhanced functionality. Documentation for creating plugins can be found here: http://www.apiman.io/latest/developer-guide.html#_plugins Or if you prefer videos: http://www.apiman.io/latest/tutorials.html Maybe you like examples? https://github.com/apiman/apiman-plugins We got ya covered. -Eric