Not quite understanding the idea behind "Add App".

[#1]

I'm new to the Apigee scene, and I'm trying to make sense of the ability for Developers to add App.

From my understanding, if you're creating a somehow open API, I understand why you'd allow developers to create apps.

However, in a context of a business using APIs for a limited set of clients, I would see the process as "You let the user register with a specific domain, then you associate them with an app you already created and permission".

Can you enlighten me and help me understand the parts of the puzzle I'm missing?

Regards

[DChiesa]

Yes, you can design your enablement that way.

There is plenty of flexibility in Apigee Edge to allow this.

One way might be:

• You publish a catalog of available APIs via the developer portal, which is open to all. You invite developers to register, and sign in. Once signedin, the developer can browse the catalog, and request an API key (which means, click the "add app" button) for a particular API Product. Then, the request-for-key is either manually or automatically approved. The developer eventually gets a key. The developer builds an app using that key.

Another way might be:

• You publish a catalog of available APIs via the developer portal, which is accessible only on restricted networks (maybe the corporate network). The devportal allows signin only via SAML, with trusted IdPs. (Maybe the corporate AD, and partner IdPs). Once signed in, a developer can browse the catalog of APIs, view documentation. An administrator manually creates apps + keys and assigns them to developers. The developer can view his keys but cannot request the creation or provisioning of new keys.

Or, one could imagine a blending. Restricted (SAML) signin, but self-service provisioning of keys.

The idea behind self-service is to eliminate friction in the creation of new apps that use the APIs. Rather than a centralized human provisioning agent for keys, self-service allows automated provisioning of keys, with no direct human interaction. It is always possible for a human to review, and revoke keys, but we need not have a human in the workflow to provision new keys, especially if we trust the users in the first place. In the case of an internal devportal, the users are trusted employees, after all.

You can also imagine instituting limits on self-service. For example no developer gets more than 6 active keys. Etc. Why would a dev need more than just one key? suppose the same developer is building multiple versions of an app. The key can be used to identify which version of the app is being run. iOS v20171128? Android beta v20171205 . ? And so on.

helpful?

[#3]

Ok, thanks. I think it fits with how I saw it (even though my reflection didn't go into SAML or stuff like that.)