[MUSIC PLAYING]
DINO CHIESA: Let's have a look at the API
runtime in Apigee Edge.
You have services or you're developing services.
The goal is to expose them as consumable APIs
with the appropriate security and behavior and management.
Let me show you just some of the options
in Apigee Edge that help with that.
First, let's talk about API security.
We'll start with a bare API.
This is a JSON API, and there's no security implemented
by the back-end system.
With Apigee Edge, you can add security
without changing that back-end system.
The simplest and easiest way to apply security to an API
is with API key verification.
Let me show you.
I create an API proxy, specifying the back-end URL
as the target.
I add in key verification with the Verify API Key policy.
Save that.
And now, every inbound request will need to pass and API key.
Easy.
By the way, to make this feasible,
obviously, we need clients to invoke the proxy,
not the existing back-end system.
And we need to restrict access to that back-end system
so that only the Apigee Edge proxy can connect with it.
We normally do this with a two-way TLS on that connection.
As a more advanced alternative, Apigee Edge
supports OAuth version 2.0.
This allows you to verify a token within the API
proxy rather than a key.
A token is a time-limited key derived from the consumer key.
Virtually every Apigee customer uses
OAuth to secure their APIs.
Token verification works very similarly to key verification.
It's a single policy in the proxy.
Save it.
And now, every inbound request must present a valid token.
Apigee Edge can, of course, issue tokens
according to the various OAuth 2.0 grants--
client credentials, authorization code,
implicit password.
And you can specify the expiry of tokens, the scope on tokens,
when you issue them.
Now, let's talk about API beauty.
We know that beauty is in the eye of the beholder.
But let me tell you, today's developers
don't want to behold XML or SOAP.
Your older services might work great,
but if they're not easy to consume,
you won't get the agility you want.
With Apigee Edge, you can transform those older services
into elegant, easy-to-use APIs.
First, let me show you a SOAP service.
The response includes lots of angle brackets, namespaces,
and framing.
Not beautiful.
This is what we see with legacy services
and some third-party SaaS services you might depend on.
An Apigee Edge proxy can accept a simpler inbound payload
and transform that into the heavier XML
the existing service expects.
And at the same time, it can transform the response
into lighter weight XML.
An easy way to do this is with XSLT.
For the request and the response,
I just include an XSL policy in the API proxy
and specify the transform.
Let's see it work.
Wow, much simpler.
Taking that a step further, Apigee
can transform the simpler XML into JSON.
We use the built-in XML to JSON policy for that.
Here's what it looks like.
I'll invoke it again.
So easy.
No more angle brackets.
What if I want to transform the resulting JSON?
Maybe I want to rename the properties
or augment that payload with some additional client-specific
data.
I can do that with a JavaScript policy.
This is really neat.
Within the API proxy, I can add a little bit of script
that manipulates the payload in any way I'd like.
Super easy, simple, and it works great.
By composing multiple policies, I
can have the proxy perform the transformation
that I want for any API.
Existing services get renewed.
That's an API makeover.
We talked about security and beauty.
Let's talk about performance now.
Some back-end services are expensive.
Maybe it's a third-party service where you pay by the call
or where you've got a call limit,
or maybe it's a large data set that changes slowly,
like a product catalog, and it's just not worth reassembling
that result each time.
You can use Apigee Edge caching to cache the results
of back-end services.
This can deliver noticeable performance gains
for clients and users and can relieve pressure
on back-end systems.
Just one additional policy.
Here, I'll show you the difference in performance
using the Apigee Edge cache.
The uncached service takes hundreds of milliseconds.
The cached service takes less than 10.
At scale, that makes a huge difference.
And with Apigee Edge, you have fine control
over the cache expiry and granularity.
OK, I've showed you how to make a back-end service more
consumable by adding security and beautifying it.
Another common desire is to be able to compose
multiple back-end systems into a single API.
Maybe you want to add a geocoding API.
Maybe you want to add in a data protection API.
So composition is a thing.
With Apigee Edge, you can do that.
The service callout policy is a simple way
to gather a response that can then
be composed with the response from the back end.
I just drop in a policy, configure it,
and then I can combine that response
with the response from the target.
Suppose you've got multiple systems
and you want some light orchestration, maybe
coordinated with conditional logic.
With Apigee Edge, you can use the hosted target
to do that orchestration.
Write your logic in Node.js or Python or Java.
The inbound request is proxied to your code.
And that code can then decide what back end or back
ends to invoke.
It all runs within the scope of the Apigee API proxy.
Finally, Apigee Edge includes extensions, so you can easily
connect into existing services, like Google BigQuery, Cloud
functions or storage, or AWS Lambda, or the Informatica
Cloud.
The extension capability is available right
from the policy palette.
Just drop in an extension, and it will execute
within the proxy context.
You can combine any or all of these techniques
in a single API proxy to compose your APIs the way you'd like.
Now, I want to show you how you can use Apigee
Edge for conditional routing.
In the simple case, Apigee Edge gives you
circuit breaker capability.
Apigee can automatically distribute load
across a set of back-end services
while monitoring the health of those services
and removing unhealthy points from rotation.
But suppose you want to perform some conditional
routing, maybe routing based on a varying weight for A/B
testing or canary rollouts or maybe routing
based on a client ID.
Apigee Edge allows you to do that, too.
Here, I built a dynamic router based
on a routing table lookup and some JavaScript
to select the target.
When I want to add in a new target or change the weights,
I just update the table.
No need to touch the API proxy, and we've
got data-driven routing.
And again, you can compose this capability
with the other elements you've seen,
for example, conditionally executing an extension callout.
Here, I showed you some of the basic capabilities
of Apigee Edge--
adding security to existing APIs, beautifying existing
APIs, composition, extensions, caching, routing.
This is just the start.
There's much more capability in the product--
role-based access control, mandatory flows for APIs,
IP whitelisting, header injection.
Apigee Edge is a power tool for curating
beautiful, secure, consumable APIs.
[MUSIC PLAYING]