IBM API Connect Reviews

It provides a few features such as security and discoveries.

What we look for most is security. API Connect can provide that. On top of that we use it to replace the old version. The current WSR was for discovery, the web service.

Additional features probably will be easier to develop. Right now the UI is using quadruples. On the policy, they are using SSLT, but I would like them to convert that SSLT to use scripting language instead.

We just started. We are converting from the old infrastructure to the new API Connect. We started maybe a year ago, but we'll see the results maybe in six months.

I think the scalability is pretty good. The API Connect divides by different zones, different domains. So how we can scale depends on organizations. If it is big, we make it big and if it is small, we make it small. It's pretty easy to use.

We used the support quite a bit, because we have to transfer the old WSR into API Connect without rewriting everything. With that transfer or migration, it takes a lot of work, so we talk with technical support. They are pretty knowledgeable, but we still have to go through many iterations, many cycles to get all the technical information out.

Beforehand there was the older generation of API Connect. API Connect came out maybe two years ago, before that was WSR combined with data power. They are going to retire WSR. WSR is also for my VN. That became AP Connect so we had to move.

I wasn't involved in the initial setup process.

I would think customer service and trust are important when deciding which vendor to choose. IBM, Oracle, and Microsoft were on our evaluation list. We've been with IBM for many years now, so we'll stay with IBM. We work very closely with IBM on their product and they're very good support, so when we run into issues, they are there to help.

I think IBM is very innovative and maybe that will give them an edge into their industry.

I think the most valuable feature is the fact that it sort of combines IBM DataPower being a security gateway with some of the features that are in IIB and IBM App Connect, to kind of build a complete integration. Also, IBM API Connect being the API gateway is extremely valuable both for internal and external consumers of APIs. Off the top of my mind, those are the big points that I would add.

For full transparency, at this point, we brought the solution in and we've used it for a couple of internal hackathons, but we haven't actually used it for any production work yet. Like any bank, it's really forcing a transformation in the sense of the whole industry related to cloud and related to connections to the outside. We're really trying to figure out, internally, how we want to define that.

Some of the other growing pains we've had is, how do we operationalize the technology in the sense of ownership internally; to say, which different groups should actually own which component and how we control the security across that. Personally, my side of the house, which is being responsible for delivering solutions on behalf of the businesses, I'm ready and anxious to get going on it. I'm very excited about the possibilities that the technology brings.

I think that some features that would be kind of cool are around the whole idea of a subscriber being able to subscribe to a plan. Not only should that plan include the number of calls per month or per week or whatever but also, I want to subscribe to a plan with an SLA, which gets into response time of an API call. If the response time in the plan that you subscribe is like 200 milliseconds with a 99.9% guaranteed delivery, then I should be able to subscribe to that plan and then be able to go into it and actually see how close I am to adhering to that.

Internally, this makes for some very interesting conversations right around going from application to application, issuing a connection and they're saying, "Hey, well, we're going to make this many calls a month and this is what we need the response time to be." You could literally say, "Well, we're hitting the SLA." Or, "We're not hitting the SLA." Externally, I think you have the same sort of commitments and when you're negotiating contracts, especially on the larger business partner connection, with the business-to-business connection conversation as well.

Given the fact that it's not operationalized, I cannot really comment too well on the stability because we haven't really had to worry about the stability yet. I'm not really in a place to know. I've heard rumors that there are occasionally some issues related to how it maintains connections with its other pair, but I don't know enough to know.

Based on the architecture, from what I've heard, it's quite scalable. It's just, bring in more nodes and away you go. My understanding is it’s very scalable.

Personally, I have not used technical support.

We did not previously use a different solution. Let's face it: This is a relatively new space and we’re a bank. Of course, we knew that the solution was going on.

I was not involved in the initial setup.

I do believe that there was an RFP process that we went through as part of the selection for this tool. I do not know which other vendors were on the short list.
Usually, our vendor selection process is quite rigid around that. Everything comes into play. Of course, there's cost but then there's, how well it's going to be supported. What does the product roadmap look like? How well does it conform to our internal technology standards? How well will it play within our environment? There's a lot of stuff there.

I think if you're working with IBM and you're looking at possibly using Bluemix now or in the future, the other thing is, if you're using IIB or you're looking at Salesforce, there are a lot of synergies related to these platforms and this tool set, so it sort of makes sense to head down this road.

Personally, if you're a small startup, you might need to evaluate the entire landscape a little bit differently, but if you're a large enterprise and you already have a pretty big relationship with IBM, I think that it makes a lot of sense.

My rating reflects the fact that it's not operationalized at this point, and that's not entirely the product’s fault. I see a lot of potential, but there are still some things that need to be there.

As far as API Connect, I think it offers us more flexibility with our application and potentially would allow third parties to come in and develop for us. It also enables us to streamline our microservices journey.

The main thing is that it just makes app development a lot easier.

Stability.

It was a fairly new product so there was, so it took a year or so to really stabilize. But now I'm happy with the performance.

No problems.

It wasn't me that did it personally, but I would say good. We have a good relationship with IBM.

We were using a different solution, but we knew that this was the future, so we knew we needed to switch.

Fairly straightforward.

Yeah, I can't recall the name, but we are an IBM facility, so we just figured it made more sense for us to go with this package.

When selecting a vendor, trust is important, as well as that they deliver. Just someone you can be comfortable with.

I rated it an 8/10 because it's not fully mature yet.

It provides a good, simplified user interface to design and secure your APIs.

First of all, it gels well with the other IBM products that we have. It resolves some of those integration problems that we earlier used to have. It provides OAuth2 authentication, which is like what we use in our APIs. So, these are the two main benefits of this product, as compared to what we were using earlier.

A lot of the features require improvement, such as better integration with the other suites of the product and a more secured way to put it on the cloud. Another useful feature needed is to make API development more easier and simpler for development, especially on the management of other artifacts, like the client IDs and other stuff.

I would rate the stability a seven to eight out of ten; it's still evolving. There are features which are missing, that are there in the other similar product from another vendor. Overall, it's good.

The scalability is good, it's at par.

We have used a lot of the technical support! We work with IBM on a lot of custom enhancements, that suits our needs. They are really proactive in regards to listening to the customers. So, they also provide a few fix packs to us sometimes.

We have a relationship with IBM. They approached us with this product and as I mentioned earlier, it integrates pretty well with our other IBM products that we use in-house. So that made us to go toward this product.

IBM are the market leaders, when it comes to integration technology. So, their proven ability and experience is why we chose this vendor.

Experience is the number one criteria while selecting a vendor. The second factor is the brand and the relationship, of course, it matters.

We do have other vendors that we use. However, the majority of our integration is on IBM.

It's good. They have really good use cases. So, it's worth investing time in these products, and if it suits your needs, then you can really go for it. It does support a wide variety of use cases.

We've yet to realize real value in the solution. The goals that we were trying to achieve from it were to implement microservices and a lot of the features and functionality that were part of the documentation, but we haven't achieved success with it yet.

The benefits would be that we'd have a great platform for our microservices and API management. But since we haven't had a lot of success with it yet, it's been frustrating.

I would like greater stability and greater ability to actually administer the product without needing to go to technical support. It's very proprietary and support has secret passwords that they use to get into certain functions.

IBM has limited the capability for executing typical admin commands and only provide a small list of proprietary commands. Without a secret command line password, clients are limited to what they can view and administer – even in a read-only mode.

Stability is not good.

Scalability is good.

I would rate technical support fair, at best.

We weren't using a different solution. This is a new approach. We do have alternatives that we are using, including other IBM products. But we did this one more from a sales relationship, technical sales team pitch.

When selecting a vendor, reliability and experience are most important; the fact that we had experience with them. We have a lot of IBM products and we had a lot of good relationships.

I was involved in the initial setup and it was somewhat complex; medium complexity.

We didn’t look at other vendors.

Certainly look at other options that are out there and absolutely go with the latest and greatest version of the product, because there have been a lot of issues and it's going through growing pains. It's not completely mature.

I like how it runs within DataPower, and adds the extra OAuth security. It gives me a common place to do security for all my API services.

The biggest benefit is the availability provided to the people that will use my services. They can go to a portal and look for services to identify which ones they'll use.

We use it for existing IIB services. We call on multiple back ends from the same service where the record layouts are different. It's difficult to describe and use them in the product.

Actually, we're in production for demo purposes, so I really can't speak to this. So far, we've had no issues.

We have used technical support and we have a good response.

The decision to switch was made before I had left IBM and went to this company four months ago.

When selecting vendor, support and longevity are the most important criteria.

I was involved in portions of the initial setup. It was complex from the standpoint that there were a lot of components, but it wasn't difficult.

Make sure to understand its purpose and what it's used for and not used for.

• GUI-based accelerated API development
• Segregation of ownership and control for different stakeholders
• Self-service Developer Portal: a highly customizable portal based on Drupal CMS
• Security support for oAuth, basic authentication and keys
• Analytics
• High-performance solution when used with DataPower IDG. DataPower IDG can support 8K TPS per appliance
• Easy-to-implement, configurable API security and analytics
• LoopBack projects allow API creation using a datasource

This product has been designed very well and addresses many advanced use cases of API development in a collaborative environment, which are not yet available in other existing products, for example, Layer 7.

• Self-servicing portal allows users to explore APIs, create and manage keys. and manage subscriptions.
• Advance infrastructure load balancer/cluster management features
• GUI-based accelerated API development and deployments

• Production traffic monitoring features can be better.
• A few advanced API managementfeatures such as monetization and portal syndication are not yet available in the product, but are included in the product road map for the near future.
• API hosting needs a separate product (for example, DataPower) or Micro Gateway (a node js component). However, in a few cases, this can be seen as a better overall solution.
• Frequent product design changes were observed during the early stages of this product evolution; however, currently this product is very stable.
• A few minor quality issues were observed during the early stages of this product evolution; however, currently this product is very stable.

I have used it for 1+ years.

Current versions are stable. However, a few minor issues were observed during the early stages of product evolution.

No scalability issues were found.

Technical support is 9/10:

• Highly responsive
• Quarterly enhancement/bug fix releases
• Detailed product documentation

We previously used Apigee. We switched due to version upgrade cost issues and a need for performance improvement.

Initial setup is very well documented and straightforward. However, please refer to API Management experts for the most-optimized solutions.

It's available in SaaS and on-premise versions. This product comes in three offerings: Essentials, Professional & Enterprise.

As per the required API Management components, pricing and licensing might vary on a case-by-case basis.

Enables a cost-effective solution when implemented properly.

Before choosing this product, we also evaluated CA Layer 7, Akana, and Mashery.

API Connect is an easy-to-learn, very advanced, reliable, business-to-business API management product. However, understand your requirements clearly and use expert help for the most optimized yet secure solution.

The API Connect product comes with API management, developer portal, offline API development toolkit and a node js component called Micro Gateway. Licensing can differ for these components.

From an API development features perspective, API Connect and API Management might appear significantly different. However, inherently both products exhibit a very easy, refined and mature API implementation process. I would personally recommend to everyone to use API Connect over API management.

V3 is way better then v2, and v4 has further improvements. We have the ability to secure, control, transform, catalogue and optimize access to our APIs for external and internal partners and developers.

The APIs are exposed to B2B partners in a secured, and better way. Internal re-usability of APIs are encouraged by cataloguing all the APIs.

It lacks the ability for billing and metering the API usage to invoicing in v3, however, v4 does have this. Automation of deployments is needed.

We've used it over a year, v3 was purchased in Q2, 2014.

Manual steps for deployment is needed.

No issues encountered.

No issue with scalability as the run timefor API Management is proven and time tested i.e. Datapower which all fortune 1000 companies use.

The IBM customer rep was very helpful in the POC phase, and helped us escalate custom/new features which we requested.

Ir's excellent.

No other product was used, and the service was just exposed by Datapower.

Initial setup was straightforward as 50% of the solution was already in place. IBM API runs on IBM Datapower so the setup was only needed for IBM API Management itself.

We did it in house using the same set of Datapower developers supported API Management.

We also looked at WS02 which was way too complex and needed almost 14-15 VMs to run. As we had Datapower, it was a natural choice for us.

If the customer is already using IBM Datapower then it is a no brainer that IBM API Management will complement their existing investment.

The most important feature is, for sure, the security gateway. But if we think commercially, the possibility for easily creating and exposing service plans and charging is also valuable.

We are planning the usage possibilities of API management inside our company, and outside, as well. Plenty of our web services are spread throughout various enterprise infrastructures and we want to control them in a better way with this tool. Of course, the valuable part outside the company is possibility for tracking and exposing telco services, as well as a commercialization aspect, through a developer community.

We have no suggestions so far.

After six months testing the platforms we now have a preparation period for commercial usage. The platform is technically ready for use. We are using a Data Power XG45 v6.0.0.4 as the gateway layer alongside API Management.

No issues encountered.

No issues encountered.

No issues encountered.

We have no such information so far.

We know that our implementer had some problems while implementing the platform but the main vendors technical support (IBM) responded very quickly and professionally.

No, we didn't. This is our first tool with this functionality.

Initial setup is very simple. Later implementation is a little bit complex (disagreement of reference in documentation, different recommended OS versions for additional parts of the environment etc.)

The implementation team did it with the support of a main vendor team. They have high level of expertise.

No we didn't. Maybe ESB (Enterprise Service Bus which we already use) is one of the solutions for exposing different kind of web or other services for sharing usage data but we realized that API management will be more useful for our wider purposes.

It's a good solution with a simple user interface. It has many different possibilities as a business solution.

The seamless conversion between rest and soap and service catalog.

I am a consultant so I can explain how this product has improved my customer's organization: it has made it very simple to expose new services securely with a specific general policy in DataPower and also keeping track of their use (amount of calls, etc.).

Integration with Exchange Server. Also if it could be easier to configure or direct the DataPower policies that would help. I'd like to see a combo box to choose which processing rule to apply.

I've used it for a few months.

Only issue is with connecting it to Exchange Server.

No issues with stability.

No issues with scalability.

I did not require the customer service.

I did not require technical support.

It was an addition and not a substitution to anything.

It was straightforward.

Seems good so far, as it saves a lot of time. It used to take a long time to expose services, whereas now it's just a few clicks.

It's pretty simple, there's no need for any special advice actually.