API / Operation visibility
Make possible to manage the visibility not only at product level but also at API level (and even maybe at operation level)
Is this still being reviewed?
Amir Chatrbahr commented
This would be essential for obsolete API/Operation which are still being used but not preferred to be displayed on the Developer portal .
Is this still under review? We would like to have certain APIs/Products hidden from the API list even to users who have active subscriptions. For example, APIs that we are not offering directly to developers, but which feed our products via APIM.
Woutercx, may we ask you to share the policy define to achieve this scenario, till the time Microsoft is working to have this feature OOB.
Like this... have this situation today... It would be immensely helpful if this feature existed today.
We have the same scenario. We would like to provide a customer a subset of routes from one or more Api's. I don't want to have duplicate routes. I haven't tested yet what happens when I import an updated swagger doc with documentation changes. I'm guessing only the Api I import into gets the updates, not the duplicate routes I currently would have to maintain in other "custom API's" created just to support another product. In my mind there is one Api, and the Product should allow us to mix and match what routes are included in that product.
Hi. This is one of the top suggestions and, at first glance, seems a relatively simple change to implement. It's been here for 2 years yet I don't see it on the Trello board even though it says 'under review'. When will this be prioritised?
I agree with everything written here.
If a product is the one being used by developers that consume my API, allow to control which operations will be exposed by the product.
I solved it by exporting the API with the full set of operations, and importing it under different API name, then in that new API, I delete the operations that I do not want exposed.
But now I have few API's with operations duplication.
Lasse Faarbæk commented
This feature would be great for us, as all the operations we have exists in one swagger file, which is then imported into APIM (and re-imported when we have updates to operations).
We would like to create products based on the sensitivity of the data exposed in our application, and thus the need to create products consisting of specific operations is required.
I think this is an essential feature and one provided by many APIM technologies I've worked with from other vendors. I may need to create products which limit subscribers to only read operations for example.
Adam Weigert commented
Having the ability to scope an operation to a group would be helpful. Use case would be a Support API that has commands that Level1 support teams can use and Level2 support teams can use other operations but they are all the same API. Today I would have to have a Level1 Support API and a Level2 Support API and use products to control which one sees which API.
This feature would let me have one Support API and visibility to the operation would be managed based on the group, defaulting to "Developers" of course. This could also be handy in providing "Developer" API operations and "Guests" API operations, e.g. a heartbeat / service status API could be available to "Guests" so anyone good see that visibility, but deeper interaction on the monitoring API could be provided to those with the Developers group.
I solved this at the backend level by matching the subscription key with the product (at the operation). I created a check so that someone who wants to access an operation that is not part of the product, he will be denied.
I would like to have a way to select the operations that I want to share from a particular Api for a product. Currently if I create a product and select an API all the operations are exposed. So If I need another product with some of the operations from this API, I need to create them all again, Which is a huge rework.
Please some comment if there is a way to achieve this.