Newbie Qn: Advantages of DevPortal over Admin

[adderidder]

The admin console includes the option for deploying an API proxy. For simple, internal-user proxies, is this sufficient or should we deploy a devportal?

We can store the code version in github. We know the APIs published. What other features are in devportal that are not in the admin UI? Can someone suggest documentation where I can gather a more complete list?
Thank you in advance, Adam D.

[sidd-harth]

Admin(Edge) UI and DevPortal are two different planets 🙂

• Edge UI is used by the API Developer/Engineers to create and deploy APIs.
• DevPortal is used by the APPLICATION Developers to create APPs(Mobile/Web..etc).

It is recommended to expose any API to a DevPortal even if it is for internal developer consumption.

• Any developer invoking the API needs to know/understand how an API works, the request, error codes, response headers, response content, and keys(client id, secret) to invoke the API.
• All these features and many others can be provided through a DevPortal.

We create APIs and expose them to DevPortal so that other App Developers explore the APIs and create Apps.

https://apigee.com/about/cp/dev-portal

[adderidder]

Thanks for the info and the link, Siddharth. I downloaded the ebook to get more info.

[karlscheirer]

Good answer @Siddharth Barahalikar! The portal is really a convenience, it allows for self-service registration and getting API access, as well as documentation. It's not required though - you can create developers and assign them API keys directly in Apigee Edge if you want, it's just harder to manage if you have a lot of users and APIs.

[adderidder]

Thanks Karl. We have a pre-developed API that they are eager to deploy and just needed to know if it was mandatory to have the dev portal in order to do that.

[christophweber · Accepted solution]

I'd like to illustrate what Siddharth and Karl said with a negative example:
At a recent API conference I shared lunch with developers from a very large, well known enterprise. They have by now built 100s of APIs across quite a few internal departments, and no developer portal.

Hence their daily workflow in the absence of a central developer portal is:

• Any developer invoking the API needs to know/understand how an API works, the request, error codes, response headers, response content, and keys(client id, secret) to invoke the API.
• All these features and many others can be provided by someone who knows how the API works.
• The challenge is finding out that an appropriate API exists and where it is, tracking down someone who knows enough to get you started, and then hoping you got all the info you need.

Would you want to work there, or be one of their data customers? In other words, why be stuck in the old world of data silos, albeit with modern, managed APIs? Go all the way and expose and document the data and services and APIs around them to reap the full benefits of what you have built.

[adderidder]

Thank you for tie-breaking the answers, Christoph. I had a yes and a no. I just needed a maybe to get my 'full-house' 🙂

The details you have are just what I needed to answer the customer, who want to migrate an existing API to Apigee in as little time as possible. I will tell them that it's possible, but it is on them to judge whether the extra time spent troubleshooting would or would not exceed the time needed to just deploy the devportal.
Happily, we all agree to deploy the devportals later. But, like so many projects, they just want to start by completing the job, then figuring out how to do it later.