APIGEE for consuming external APIs

Not applicable

Hi All,

Has someone used APIGEE for consuming external APIs as well apart from publishing the APIs?

Are there any best practices for the same??

Use case is we want to use some third party APIs for our internal systems then should APIGEE be used as a facade for those APIs?

2 6 3,388
6 REPLIES 6

@Vipul Agarwal ,

Yes, Absolutely, One of the pattern we have seen across our customers is not only publishing internal APIs that they produce but also consume external third party APIs using Apigee as a facade where they implement business logic on how they consume external APIs.

I don't have specific use-cases / examples, but i have heard about the pattern many times.

+1

API facades for external services? Why not?

Here are a couple of scenarios

  1. I worked with one customer who used APIs from a third party, and that third party had a habit of changing their own APIs pretty regularly. This customer had numerous apps invoking the ever-morphing APIs. They used Apigee Edge as the isolation layer that. They were able to build a stable facade, exposed to their own internal consumers, while modifying the southbound part of the API proxy to conform to the latest API from their fickle partner.
  2. Another customer had a common set of credentials to use against a 3rd party service. These credentials were sensitive and not shared among the internal apps that had reason to use the external service. So they used an API facade to map between enterprise credentials and creds valid at the 3rd party.
  3. A third customer wanted to gauge traffic volumes, and just by passing the API traffic through Apigee Edge, they could see trends over time, error rates, and performance.

Food for thought: in the connected enterprise, exactly where is the firewall?

If you use cloud services (Kronos, Workday, SAP, salesforce, Okta, etc), these services are part of your enterprise. If you also use cloud providers like AWS EC2, Azure VMs, or GCP, then those external services are also part of your enterprise. And maybe some services are running within traditional corporate datacenters.

The point is, the distinction between "internal" services and "external" services becomes an artificial one. A distinction of historical significance rather than of practical current significance.

Services are services.

Great answer @Dino , +1

nmunro
Participant III

@Vipul Agarwal,

I echo the previous two answers.

We had the same questions when we started our first implementation on apigee.

There is the tendency to think about your APIs as "come-and-get-it" where your back-end systems are always the target, where you are always the publisher (to use your term).

This is in part due to the way platforms like apigee are marketed; as a facade to your internal systems. There's nothing wrong with that as it's easy to understand.

However, as @Dino points out, it's highly likely that your enterprise consists of systems that you consume as a service. These are also "back-end"/internal systems.

I think when we addressed the questions you have, it was a significant point in our understanding of apigee and API management.

We no longer talk about client (external) and back-end (internal) but rather client and target. I think when you think about it this way then you open up more options and you are more free to focus on the value of what you're delivering.

If you think about it, everybody (almost!) is providing APIs. If we all sit behind our facades with the come-and-get-it/publisher approach then nothing can be connected. At some point the decision about the roles of client(consumer) and target(publisher) has to be made.

At a minimum, proxying "external" APIs will add visibility through apigee analytics but I think you'll find more value where security is concerned, and also in a consistent experience that makes sense for your enterprise.

For example, a salesforce.com API becomes a "my-org" API for some capability - essentially the fact that salesforce.com is the target is less relevant (what happens if in future you decide salesforce.com should be replaced?).

For some examples of places we proxy an "external" API:

  • We use apigee to proxy salesforce.com APIs for a mobile application (essentially we have no "internal" back-end in this interaction)
  • We use apigee to proxy salesforce.com APIs for SAP (where SAP provides data to salesforce). apigee adds value here with OAuth where SAP-as-a-client only needs to deal with tokens from apigee - important because salesforce.com is not the only target that SAP interacts with.
  • We use apigee to proxy a service from FedEx, again with SAP as the client.

One use case that wasn't mentioned yet, but worth calling out IMO.

Say your enterprise enters into an agreement with Bing maps so you can provide maps in all your apps. If the apps you're building call the API directly, you know have n number of integration points with Bing. If you decide to switch over to using Google, or some other mapping provider, you need to update all those apps. That's a big effort. If you proxy the mapping service through your API management solution, the apps are building against api.company.com/maps (or whatever). You can change providers without updating the apps; you simply need to update the proxy.

Not applicable

As I understand there are many use cases or reason to consume external API in the Apigee Edge and then available or consume in the App of the organization as Apigee Proxy API. it is not best practice to consume external API directly in the application bypassing the Apigee Edge.

I have a similar situation and if above my understanding is not correct, please let me know.