It lacks some features, and the product is not that flexible for developers. It's less flexible and rigid. It's not easy to make changes or customize it. One disadvantage is that for customization, it uses liquid templates. However, not everyone is familiar with liquid templates, so if you want to do some customized logging or other tasks, you may need to struggle a lot. Other solutions like IBM API Connect or Apigee use JavaScript, which is more developer-friendly. That's what I found.
Sr. Enterprise Architect at a tech services company with 501-1,000 employees
Real User
2022-11-14T19:51:40Z
Nov 14, 2022
I think Red Hat is improving this issue because they are very technical. One problem that we had, again had a specific case of contractual obligations to have commercial support for all technologies that we were using, and specifically what was happening in that version of the solution that we were running. What was suggested by Red Hat was a crucial part of the configuration, but when we started to ask about the supportability of this configuration, Red Hat said only some parts of the configuration would be supported. So we decided not to go with it. As much as we tried to implement 3scale API Management the incompatibility of the version did not allow us to proceed. The software could support it, but the configuration unit was not updated yet to give this kind of flexibility with support and because of this at the end of the day, we had to scrub the product.
What I'd like to improve in 3scale API Management is its route-limiting feature. Currently, I don't know how to do that effectively on the solution, but in Kong, I know how to do it, so I would love to see route-limiting being easily done on 3scale API Management. It would also be good if there was some authentication that you could do from 3scale API Management because Kong offers that functionality out of the box. What I'd love to see in the next release of 3scale API Management is the ability to integrate more plug-ins easily onto the platform, so you'll be able to extend it, and even do customs management. If Red Hat could offer that extension where it allows the internal organization where 3scale API Management is deployed on-premise to integrate its tools on top of 3scale API Management and provide an API for that, that will make the solution very powerful.
Digital Project Manager at a tech services company with 11-50 employees
Real User
2022-07-13T09:44:17Z
Jul 13, 2022
3scale API Management only supports restful APIs and doesn't support SOAP. In the next release, 3scale API Management should include more healthcare interoperability.
We tried to use the portal, but we decided that it wasn't enough. The content management system (CMS) is not easy to use if you want to customize things, and it's hard to get someone who has the knowledge to work with the CMS. The CMS is not good because it's hard to see what's about to be released. Also, you can't test the whole thing at one stage, rather you have to update different fragments of the content, and there's no way to look at the whole picture before you release it. You can end up limbo with some of the content in development, so we decided to build our own portal. Also, the use of Liquid scripts is not that nice. It does its job, but it hasn't been well documented and it has cost us quite a lot of hours just to understand how to do things. When you do understand how to do them, it's quite easy, but it hasn't been well documented.
Principal Architect at a tech services company with 11-50 employees
Real User
2020-05-27T16:23:37Z
May 27, 2020
It would be helpful to improve the customization features so that the customer can do it based on their own needs. Some of the portal features are in need of improvement. The API onboarding process is quite primitive. It may not fit for an enterprise who is trying to manage their API users and the approval process. The development portal needs to better address this functionality. API management functionality should be improved so that the partner can better group it, and use it.
We haven't been working so long, so we are just starting to use it. I believe the CMS part of it has room for improvement though. That is where you write a couple of things if you want to publish your API. It's based on liquid scripting, which doesn't seem like the obvious ones to script with. I would also like to see it work with open API specification 3.
TechOps Engineer - Middleware & Containers specialist at EBRC -European Business Reliance Centre
Real User
2019-01-03T09:49:00Z
Jan 3, 2019
Setting up OIDC authentication would be another use case for this product. That would require at least three components : * Red Hat 3scale API Management (manager plus gateway) * Red Hat Single Sign-On * Customer IdP. Thanks to Openshift Container Platform integration program and features, an all in one product merge is going to be available shortly.
API (application programming interface) management is the process of managing different API functions, such as designing, releasing, documenting, analyzing, and monitoring APIs in a safe environment.
The deployment process could be easier.
The tool can improve API management and UI.
It lacks some features, and the product is not that flexible for developers. It's less flexible and rigid. It's not easy to make changes or customize it. One disadvantage is that for customization, it uses liquid templates. However, not everyone is familiar with liquid templates, so if you want to do some customized logging or other tasks, you may need to struggle a lot. Other solutions like IBM API Connect or Apigee use JavaScript, which is more developer-friendly. That's what I found.
I think Red Hat is improving this issue because they are very technical. One problem that we had, again had a specific case of contractual obligations to have commercial support for all technologies that we were using, and specifically what was happening in that version of the solution that we were running. What was suggested by Red Hat was a crucial part of the configuration, but when we started to ask about the supportability of this configuration, Red Hat said only some parts of the configuration would be supported. So we decided not to go with it. As much as we tried to implement 3scale API Management the incompatibility of the version did not allow us to proceed. The software could support it, but the configuration unit was not updated yet to give this kind of flexibility with support and because of this at the end of the day, we had to scrub the product.
What I'd like to improve in 3scale API Management is its route-limiting feature. Currently, I don't know how to do that effectively on the solution, but in Kong, I know how to do it, so I would love to see route-limiting being easily done on 3scale API Management. It would also be good if there was some authentication that you could do from 3scale API Management because Kong offers that functionality out of the box. What I'd love to see in the next release of 3scale API Management is the ability to integrate more plug-ins easily onto the platform, so you'll be able to extend it, and even do customs management. If Red Hat could offer that extension where it allows the internal organization where 3scale API Management is deployed on-premise to integrate its tools on top of 3scale API Management and provide an API for that, that will make the solution very powerful.
3scale API Management only supports restful APIs and doesn't support SOAP. In the next release, 3scale API Management should include more healthcare interoperability.
We tried to use the portal, but we decided that it wasn't enough. The content management system (CMS) is not easy to use if you want to customize things, and it's hard to get someone who has the knowledge to work with the CMS. The CMS is not good because it's hard to see what's about to be released. Also, you can't test the whole thing at one stage, rather you have to update different fragments of the content, and there's no way to look at the whole picture before you release it. You can end up limbo with some of the content in development, so we decided to build our own portal. Also, the use of Liquid scripts is not that nice. It does its job, but it hasn't been well documented and it has cost us quite a lot of hours just to understand how to do things. When you do understand how to do them, it's quite easy, but it hasn't been well documented.
It would be helpful to improve the customization features so that the customer can do it based on their own needs. Some of the portal features are in need of improvement. The API onboarding process is quite primitive. It may not fit for an enterprise who is trying to manage their API users and the approval process. The development portal needs to better address this functionality. API management functionality should be improved so that the partner can better group it, and use it.
We haven't been working so long, so we are just starting to use it. I believe the CMS part of it has room for improvement though. That is where you write a couple of things if you want to publish your API. It's based on liquid scripting, which doesn't seem like the obvious ones to script with. I would also like to see it work with open API specification 3.
Setting up OIDC authentication would be another use case for this product. That would require at least three components : * Red Hat 3scale API Management (manager plus gateway) * Red Hat Single Sign-On * Customer IdP. Thanks to Openshift Container Platform integration program and features, an all in one product merge is going to be available shortly.