Layer7 API Management

We're using the on-prem Developer Portal version 3.5.

We have 30+ endpoints that need to be applied to all new applications. Applying these one by one is slow and cumbersome so we've looked at the API groups feature. This looked good until we came across a show stopping problem: once an API group is applied to an application, new APIs can no longer be applied to that group (or removed for that matter). That means newly developed APIs cannot be added to this group and we're back in the business of adding APIs one by one. 

Has anyone encountered this before? Is there a workaround we could apply?

Hi 

Yes, it's by design. Maybe we should open an idea ticket for that.

Regards,

Mark

It's definitely unmanageable for us in it's current state so an idea ticket would be good. Alternatively, we'd be OK to create new API groups but we'd need a mechanism to bulk apply those groups to all applications. Is there a mechanism to do that?

If the main idea is to have a way of programmatically adding and removing APIs to and from applications, we're exploring a solution that would use the "Applications" API in our newest portal to do this. It won't use API Groups to do this, but should still meet the core requirement. Stay tuned!

Hello All,

Locking of the API Groups which are in use, is by design. Because of the below;

1. As a developer on the Portal, I add "Bank Payments APIs" Group to my "Bank Payment" app, and then publish my app to iTunes.

2. As a user, I download the Bank Payment app and start using it to do my banking with iTunes

3. As an API Owner on the Portal, I decide my API is no longer belongs in the Bank Payments APIs group, so I edit the group to remove the API

4. All instances of the Bank Payment app are now broken...

Instead, you should be able to deprecate and introduce a new version of the API Group, as you do for any API.

HTH.

Regards,

Vaseem

Hi Vaseem,

Yes, I understand that particular case, but what if I add an API to that group? I don't break the app.

Thanks, Matt

Matt has the use case right here. We're trying to manage the deployment of new APIs that should be made available to existing applications.  

Hello Matt / Jeremy,

Probably, you can create a new API Group and add all the newly created APIs in that, and assign it to the Applications.

As the product doesn't let you modify the API Groups (be it, adding new or deleting existing) once they are assigned to Applications, you can probably think of notifying the Application Owners (stakeholders) about the newly built APIs (Groups) and assign the group of APIs to them, so that they can use it with the same old apiKey.

If you do not want to have multiple API Groups, you will have to deprecate the existing groups (then delete them) to create a new Group with new APIs included. I was told this would be the best approach in use-cases as yours.

Thanks,

Vaseem

Hi Vaseem,

We appreciate your followup. I think it's fair to say that we're aware of the current product capabilities and workarounds. However, what's really needed here is an API to allow automated addition/deletion of APIs to an application. I am following up on this with the product team.

Thanks, Matt

JeremySkelton18000554 - Good news! Our latest CR (version 3.5 - CR5. Click here for release notes) supports the use case if the API Group is not associated with an application. However, another CR is coming soon that will allow you to add APIs to an API Group that is associated with an application. 

Thank you for your feedback! 

hohda01 CR5 release notes already says that "You can now add APIs to existing API groups when the existing API group is associated with entities". Is that not true?

Cheers,

Adarsh