Access a CA API using Apigee Developer Portal

[#1]

We have a requirement wherein the API will be developed in CA while the developer portal will be in Apigee .If we publish the API in Apigee is it possible to test it in Apigee ?

[dchiesa1]

It's not clear what you mean by

• publish in Apigee
• test it in Apigee

Apigee is the name of a team in Google, and so "test in Apigee" doesn't make much sense. Apigee, the team, produces a set of tools and products including Apigee Edge, the Developer Portal, Sense, a variety of open-source tools, and a few other things.

I'm sorry for being pedantic, but to give you a useful answer we need to be clear on what you mean, and what situation you're imagining. In your mind "test it in Apigee" means something specific. Maybe you could elaborate in 4-5 sentences, on what you mean by these things?

[#3]

Sure Dino .

We have a requirement wherein the the client wants 10 APIs to be developed in CA and 10 APIs in Apigee Edge for their internal departments . They want to have a single enterprise wide catalog for all the APIs (this enterprise wide developer portal will be the Apigee Developer Portal ) .So the APIs developed in CA will be published in the Apigee Developer Portal .My question is can we test the APIs developed in CA from Apigee Edge ?

[deniska]

@Dino-at-Google, correct me if I'm wrong, but in this situation, we have nothing special from API Management POV - API's that developed somewhere and have some runtime, is API for us, we will 'wrap' them to our proxies, add them to catalog, and voila! From developer portal, specifically the interactive documentation (maybe Swagger UI, maybe SmartDocs), which acts as the HTTP client, users can send requests that are handled by Apigee proxies, and these proxies call the backend API's. The APIs can be protected with OAuth or not (anonymous access allowed).

@Pooja Sah you wrote "10 API's developed in CA" - just 10 API's endpoints that run somewhere, and we 'wrap' them to Edge proxy and publish to Dev. Portal \ catalog.

So 10 API's that developed in Apigee - is naturally will be posted to dev.portal.

10 others will be wrapped by Apigee and posted to Apigee dev. portal

[dchiesa1]

Yes, this is quite possible.

I asked questions to make sure I understand Pooja's requirement before giving an answer!

[dchiesa1]

Pooja, it sounds to me that you would like to have a single enterprise-wide catalog of APIs. And some of these APIs may be managed by (proxied by) Apigee Edge, and some may be managed by some other system (CA?) and not managed by Apigee Edge, and some may be completely unmanaged.

The question is, can the Apigee Edge developer portal serve a single enterprise-wide catalog of all of those APIs, regardless if they belong to class 1, 2, or 3. And, if you are using the Apigee Edge Developer portal based on Drupal, the answer to that is YES. (Today there are several options for building portals; one is via Drupal, another is via an Apigee-managed customizable portal, and a third option is a D-I-Y portal).

The Apigee Edge developer portal (based on Drupal) is designed specifically to integrate with Apigee Edge. For example, it allows a subscribing (consuming?) developer to

• examine the API catalog
• examine the documentation associated to each API
• self-provision credentials, or request credentials
• interactively "try out" the APIs via the SmartDocs or Swagger UI
• View analytics information associated to the APIs that are proxied through Apigee Edge
• and more

The self-provisioning of credentials, and viewing of analytics data... these require connecting to the Apigee Edge control plane via the administrative APIs. The other things require connecting to the Drupal backend store, or just displaying a SwaggerUI.

So it is possible to use the Apigee Edge developer portal for "full service" for those APIs that are managed by Apigee Edge, and for partial service for those APIs that are either managed by some other gateway or not managed at all.

You would have to perform some customization to make this happen, and you would probably need to expose the three classes directly to users - in other words the developers visiting the portal would need to know which APIs belonged to which class.

The reason for this is: a developer that provisions credentials in the Apigee edge dev portal should expect those credentials to work with APIs managed by Apigee Edge. That developer must not expect that the credentials will work correctly with the CA-managed APIs or the unmanaged APIs.

Now, you could customize the portal to an extent that a developer could provision credentials for CA from "the Apigee Edge developer portal". But integrating the off-the-shelf Apigee Edge developer portal into the CA gateway would involve custom programming by you. Similarly you could provision credentials for the "unmanaged APIs" - maybe create RSA keypairs. Delivering the keys to the right places would be a job for your customization.

Even if you don't choose to get that fancy with the customization, you will need to do a little customization to just group the APIs into different sets, to make it clear to the developers using the APIs. This may be as simple as applying tags or categories to the various APIs in the catalog.

I hope this is helpful!

[#7]

@ Denis Kalitviansky - Yes I mentioned the number of APIs to make the question clear .

@Dino-at-Google - Thanks for the detailed explanation .Yes you got it right .I was trying to find out if Apigee developer portal can act as a single enterprise-wide catalog .