Hey, friends!
I'm Scott Hanselman, and this is Azure Friday.
I'm here with Anton who's gonna talk to me about some of the new
stuff going on in Azure API Management.
You got a new UI and the portals, some new features,
and you brought me a demo.
>> Right.
So over the past year, we have been developing an entirely new
UI inside the Azure portal.
So up until now actually, most of the configuration of APIs
have to be done inside an external portal we call
the Publisher portal, which is still there.
But we developed that completely,
and over the past few weeks, we have been slowly releasing that
in general availability as well.
So that's actually what I wanna show you today.
So here I am in
an API management service that I have opened.
And just a quick overview of what we have,
we have this brand new API management section
where I can perform all of the regular operations.
For example, configuring APIs and policies,
products, name values which is really the new name for
properties to our key value store, a few users and groups.
By groups in preview only because we are still missing
the AD functionality that's coming very soon.
>> Okay.
>> And analytics is also something that we
are still working on.
We have notifications, identification recipients
basically, and notification templates.
And then further down, we have the full security configuration.
So security of the developer portal, like identity providers
and delegation, security of the APIs,
like OpenID Connect, And certificates.
And also the two ways to programmatically control API
management so the management API and the Git repository for
the configuration as well.
Then of course, we have our regular settings,
nothing new here.
What is interesting, we also have Azure Monitor support.
So now we emit the number of metrics into Azure Monitor
where I can set alerts and I can generally use the infrastructure
that's available there.
This is in addition to our analytics which are not
going away.
>> Uh-huh.
>> So, but probably the most interesting from the UI
is our new APIs and policies configuration experience.
We've completely redesigned that.
And so starting off, we've made it much easier to get started,
not just by importing OpenAPI or WSDL files,
SOAP APIs, but also importing Azure resources work.
For example, Logic Apps, API Apps, or Function Apps.
>> What is the, forgive my ignorance, but
OpenAPI Specification,
how does that relate to something like Swagger?
>> Well, it is the new Swagger.
[LAUGH] >> It is the new Swagger?
>> It is Swagger nowadays, and
we are actively working on Swagger itself.
One of our team members, Daryl Miller,
is an active participant in the new Swagger specification, so
we’re quite heavily invested in that.
>> That's great.
>> So what I'm going to do though,
I’m going to show you the design first experience.
I'm going to create a blank API here, and
I'm going to just very quickly, I'm just going to call it tgif.
I'm not going to set a back-end
on purpose because I wanna show you a trick later on.
I'm going to add it to a product.
And so as I create this API,
here it appears in the list of APIs.
And before I show you the rest, I'm just going to add
an operation because obviously I still don't have any.
So here we have the visual operation editor.
I'm very quickly going to do this.
We can't, >> That is a much nicer
UI than before.
With all due respect to the previous UI,
it's just easier to visualize.
>> Yeah, yeah, we have really tried.
We have done usability studies and we have really tried to
design something that users will not get lost in and
will find a way quickly through and to accomplish their task.
So here, of course, I can do the regular things like set query
parameters, headers and request parameters, request samples, but
also respond samples.
And I'm going to create one because this is going to play
later into what I'm going to show you.
So I'm going to say this API can return 200 OK,
and can return an application/json response.
So I'm just going to type in just some sample data, mainly,
so we know.
>> How is that sample data used?
>> Well, it is going to be provided as documentation on
the developer portal.
>> Uh-huh. >> And in addition to that,
we have a new feature called mocking where API management can
return a response even if your back-end isn't available or
isn't there yet.
In this case, as you saw,
I defined the API without a back-end.
So if I call this API right now, it will just give me an error.
But with mocking, I'll be able to make it return a response so
I can start my testing earlier before the back-end is ready.
>> Very cool.
>> So let me save this.
So what you'll see in this part of the screen now when I
open this operation is that we now draw a diagram
of the API pipeline.
So here, I see the front-end I just defined, and
I see that it goes to a section called inbound processing.
So these are the policies that modify the request,
then it goes to a section called back-end.
Where of course, I don't have a back-end set, but
I can set further policies to change the back-end.
And then I have the outbound processing section, the policies
that modify the responses coming from the back-end before it is
sent back to the client.
>> And we've seen in previous episodes of Azure Friday that
people can call explore, but you can do all kinds of things.
You can then add additional information,
you can change JSON into XML.
You can really,
really do amazing stuff with API management.
>> Right, right, so
we have our full policy editor available here.
In fact, for each one of these sections, besides the regular
visual editor, we have also a code editor.
So in fact, before I show you policies, I just wanna
do a quick look here at the code editor for the API definition.
>> Mm-hm. >> So we
have a full on Swagger Editor built-in, of course.
It has validation.
It gives me an error because I don't have a host,
I didn't set it on purpose.
>> Right, there's no back-end.
>> Right, but I say, if I were to type in something here, I
get real time validation, and I get another way to edit my API.
>> That's nice.
I know a lot of us have struggled
writing those manually.
>> Right, so I'm going to go back here.
And by the way, the same is true for all the sections.
We do have a code editor, so for policies,
this is our old code editor in its full XML glory.
We have made finding the policies a lot
easier because we now have over 30 policies.
So I would organize them in categories.
But what I wanna show you is the new visual policy editor.
So we are still adding policies to it,
but we've made it very easy to rewrite the URL or
set additional query parameters, headers, the body.
And also, this is where I would enable mocking.
So here, I have mocking.
So I can switch it on by simply clicking on static responses,
and I can select what I want to return.
So I could make the API return any valid response,
HTTP response, or one of the samples I have defined.
So as I save this, I will get a warning here,
mocking is enabled so I know that I'm not getting
a call to the back-end and I can switch to our new test tab.
So previously, users had to go to the developer portal to
test the API and see how it works.
Now, we have built this into the administrative interface so
that it is much quicker.
So if I click Send here, so here it is.
I got a 200 OK even though there is no back-end, and
I get that sample that I had to find.
>> What would mocking do if there wasn't a sample?
>> So it will do a cascade of steps,
basically, trying to produce a response.
If there is a schema but no sample,
it will generate a sample based on the schema.
>> Wow, now you're just showing off.
>> [LAUGH] >> That's cool.
>> And if there's none of that either,
then it will simply return an empty body.
>> That's cool.
This would be really great, if you think about people who
are going to put together an application and
they're trying to move as agilely and as fast as they can.
They have a mobile app.
They haven't got the back-end done yet.
They could hook things up and get them almost hooked up.
>> Right. The idea is that you don't want
to block your front-end development, that mobile app,
if you don't have the back-end in yet.
But if you know exactly what your API is going to return,
you can make the API return anything.
And in fact, mocking is a policy.
So if I were to go back here into the code editor, in fact,
here in the preview we already see that the policy is here.
>> Yeah. There's the mock, right there.
>> Right?
But if I go into the old editor,
I will see that it's just a policy.
I can place it anywhere I want.
I could do a conditional statement, and maybe
return a different response based on a different parameter.
So I can really do some more powerful stuff with it.
>> I see. So you could mock
based on a header that was coming in or whatever you want.
>> Exactly.
>> That's really interesting because a lot of times when we
make mobile applications, we do our mocking in the client,
which is fun and fast.
But it also forgets about things like latency and calling out to
real back-ends and real HTTP and networks being slow.
It's much better to have that mocking happen on the back-end.
It gives you a much more real experience.
>> Yeah, I mean the idea is also that is you are doing an API
design for
a scenario, you've probably first designed your API.
You've defined it to some extent and
you know what you want it to return.
And especially if you have built already an OpenAPI specification
document, you can simply import that,
that may already have the samples in it.
You just click mocking to make it enable and the API works.
>> Uh-huh. >> So,
>> And you said that those
samples that you put in the mocking also can appear in
the Swagger and to automatically generate the documentation.
So there's value in putting that work into designing a sample.
>> Right, right, right.
So all of the developer portal documentation is generated based
on the definition of the API.
If I were to switch to it right now, if we have time,
I can very quickly show you.
This is just our sample portal which of course,
>> This always blows me away.
Like this is made for people, this is the thing I don't,
when people don't know that API management exists.
That you're making APIs and not getting a free portal for
your API, it just makes me sad.
People need to know about this, this is great.
>> I see you have played with the styling previously, so
it made everything white.
So in fact, this.
>> [LAUGH] >> Fix your CSS.
>> Yeah.
>> I'm not gonna mess with it.
>> That you even get to try it.
So you have your built-in subscription key,
there's your mock right there.
And people get to go and play with it such a valuable thing
for anyone who's putting together a public API.
>> Right, right, so everything is generated automatically,
it makes it very easy.
>> Fantastic, all right, and this available now?
>> This is available now.
As I mentioned, we are still working on the analytics
subsection, so that is going to come in the next couple months.
>> Okay.
>> And the group section which is actually fully
functional except for its other active directory capability.
That's probably going to be finished in a month or so.
>> And then how long do we expect the old publisher portal
to be available?
>> So we're going to keep it for the next couple months as well.
Simply because people are obviously taking
time to get used to the new interface and
we don't want to upset anybody's workflow.
Certainly in a couple of months, we will place a warning
on the portal saying when we plan to actually deprecate it.
And people will have enough time to get adjusted if they have
basically not started using the new interface.
>> All right, fantastic.
I'm learning all about the new UI for Azure API Management and
some of the new features like API mocking here on
Azure Friday.
[MUSIC]