2021-09-23 10-29-55
João Carreiro
mvp_badge
MVP
Screen on Service Center to present the entire list of all APIs in the environment
101
Views
3
Comments
New
Data & Integrations

I would like to have a sort of a screen in the Service Center where all this information would be centralized and displayed, and where it would be possible to list all APIs and to navigate to the API edit screen from there.

It is not the first time where I am in a project where it is used a middleware for APIs management inside the organization. And a problem that always happens when, for some reason, the middleware changes its DNS, so from xyz.whatever to azurexyz.whatever, is that to make the changes in all the currently used APIs I need to go espace by espace (or module by module) in Service Center, assuming that I don't need to go into SS to see where all APIs are located and I don't miss any of them and change one by one.

I know it is possible to have this kind of list looking into the system entities, but I believe this should be part of the product because it seems to be commonly necessary.

This would also help, in cases like the example, I described above, to make sure that we don't forget any API where the URL basis needed to be changed.

Cant you get those on runtime Integration reports, that's lists all APIs if invoked  in one place.

Agree ! having a catalog of available API's (rest , soap and service actions) will allow development teams to move faster. In some environments with lots of teams , it's hard to understand what API's are available to use (the api catalog). Most the times customers end up creating (and maintaining) some sort of list of Apis - excel file , confluence page,etc.  Having the platform to generate this catalog will save this time to the development team so that they are focused in solving the real problem - Delivering applications

2021-09-23 10-29-55
João Carreiro
mvp_badge
MVP

@Ashis Rout that would not serve the purpose, there can be several APIs that are never, or quite never, used. So the reports do not solve my problem. This is more a perspective from the Factory Management view.

@Rui Madaleno, thanks for your input on this. And I agree with what you wrote, there are too many people doing it in their way, the main goal is to deliver, deliver and deliver, and not to worry about this kind of things.