 Hi there. My name is Mohit Trivastav and I'm a PM manager in the Azure Developer Experience team. Today, I'll be walking you through API apps, a key app type in Azure App Service. In a nutshell, API apps makes it really easy to build and consume APIs in the cloud. In addition, it integrates really seamlessly with API management for a seamless, integrated experience for management, hosting, and developing your APIs in Azure. Our first design principle when it came to making it easy to build your APIs was that you could bring your API as is in the language of your choice. And if your API is already an app service, it was really important that you shouldn't have to redeploy your API if it's already hosted as a web app or a mobile app. The first turnkey feature we then add on top of your API is a simple authentication. And that spans both service to service and user authentication. And it also spans a number of identity providers, including Azure Active Directory, as well as social providers like Facebook and Google. The next turnkey feature is cores. And what cores lets you do is, in the portal, you can specify a number of domains for cross-domain browser access. And that's especially relevant if you're building an HTML or a JavaScript application that needs to call into your APIs. And finally, we make it possible for you to specify the endpoint of your swag or metadata. And that's really important if you have partners or customers who need to generate SDKs on top of your APIs, they can find where the metadata endpoint is. And also, because API apps is part of app service, it inherits the features for hybrid connectivity and virtual networks. So that means you can use API apps to build a cloud API that's modern and REST on top of a non-premises API that might not be REST and might be behind your firewall. On the consumption side, we make it easy for you to either use the native SDKs that are provided by Facebook or Active Directory, for example, or to use the mobile services SDK, which unifies the experience of connecting across a variety of identity providers. In addition, by virtue of the swagger metadata that we talked about earlier, we give built-in code generation in Visual Studio. And finally, that same swagger metadata can empower logic apps as well. And what you can do there is stitch together a bunch of APIs, both your custom APIs, as well as marketplace APIs to orchestrate a process or workflow. All the features we've just talked about, cores, API metadata, and EasyAuth are built into app service. That means they're available across web, mobile, and API apps. If you're a current API apps customer, this is a little bit different than today, where you needed to deploy a separate API apps gateway to get these features. That said, API management has a gateway, and it's certainly possible and even recommended in many scenarios that you put API management in front of your API apps for a full set of API capabilities and features. So with that, we're going to dive right into a demo. We'll walk through the basics of creating your first API app, and then we'll see how you can turn on cores and how you can turn on authentication. So now we're going to walk through the experience of creating an API app, first a pretty vanilla one, and then gradually adding some of the features that we've talked about. There are two ways to get started. The first way is you can use a built-in API app template in Visual Studio. And the other way is you can take an existing web API and publish it as an API app. So I want to walk you through that. So what I have here is an existing web API, and it's a very simple web API. So if I load the startup.cs, you'll see here that in fact it's an empty startup.cs. So that means no authentication, and that means no cores. To make it publishable as an API app, I normally want to add metadata, and I'm going to do that using a NuGet package called Swashbuckle. So I'll load the NuGet dialog and search for Swashbuckle here, and go ahead and install it. And what this is doing right now is it's dropping in a package that can reflect off of the ASP.NET web API help page API, and instead of rendering help pages, it can render swagger metadata instead. Now that it's done, I'm going to go ahead and publish this into App Service as an API app. And what's happening right now is it's round-tripping my bits from my local machine to App Service, and once the publish has completed, it's going to load my API. And because my API had no authentication, it should load right away. And because this is an API, there's no starting page that's expected. So let me instead go ahead to the swagger endpoint. So once I load the swagger endpoint that's part of Swashbuckle, I can see the list of all the operations that are available, and I can even invoke them from right here. So let me go ahead and give this API a parameter and try it out, and I can see the response. In this case, there's one to-do item for me, which is to fix the umbrella. So now we're going to walk through the consumption side of this. How can I generate a strongly typed client and call this API from a .NET application like a console app? So I have here an empty console app. Basically what you see right after you do File New. And now I want to build a console client for that to-do service. So the first thing I need to do is right click to-do client and say add. And I can add an Azure API app client. And once I do this, I have the option of either adding a client for my API apps in app service, or I can just provide a swagger metadata file independently of that so I don't have to use it with API apps. In this case, I'm going to do the former and I can see indeed my data API is now available. So I'm going to go ahead and pick it and choose OK. And you can see what that is. It generated an entire SDK for me right in my project. And the nice thing about this is all source code, so I have the ability to change the SDK if I'd like. We've made the SDK very simple. I'm going to, in fact, use the SDK right now to build this application. So the first thing I need to do is create a client. In this case, the client is named after my service, my data API. And then once I have the client, I can use it. So I can say for each to-do item in client.to-do items or to-do list.get, give it my name. I can iterate over those and I can print out the payload. So in this case, let's just say to-do.description. That's it. Really intuitive.net. That's our goal here. So if I Control-F5, I can see that same fixed the umbrella to-do in just a matter of seconds. So all that is great, but as we've noted, my API is currently unsecured and available to anybody on the internet. So one way I can secure my API is by adding code to startup.cs or startup.auth.cs, Uzo and et cetera. And that's certainly fine. But because my API is hosted in App Service, I also have the option to use the built-in auth feature. So if I navigate to the Azure portal, you'll see that every App Service app, whether it be API, web or mobile, has this authentication and authorization feature. So I'm going to go ahead and turn it on and it automatically figures out which tenant I'm in, as well as it comes up with a default name for the application in AD. In this case, it names it the same as my web app. I can go ahead and click Save. And in just a couple seconds, a number of things have just happened. First thing is my app has been created in AD. And the second thing that's happened is my web app or my API app has been associated with that app in AD. A bunch of steps that would have normally taken a long time without this experience. So now I'm going to flip to a browser where I'm not yet logged in and I'm going to navigate to that same endpoint. So if I remember it correctly, it was my-dataapi.azurewebsites.net slash swagger. And if you notice this time, I'm getting prompted with an AD login screen. So let me go ahead and log in and I have the same experience again. So really nice, just one-click way of getting AD authentication on top of my API. And I showed you a .NET example, but the same idea works for Node or other languages as well. And it's especially handy for languages where there may not be a great support for the identity provider that you're interested in. So I went ahead and created the exact same API in Node. And if you look here, just like in ASP.NET, there's no authentication middleware in my startup path. This is just a vanilla Express-based API in Node. And there's no authentication coding here. And I've already gone ahead and flipped authentication on for this API. So if I again close my browser and restart and hit the Node API, which I've cleverly named Node-data-api.azurewebsites.net, you'll see I got prompted for AD again. So as you've just seen in just a few seconds, we were able to take a Node and a .NET vanilla web API and add a number of features. We were able to add AD-auth. We were able to add metadata and SDK generation. And while I didn't show it, we have also been able to add cores in just a matter of clicks. So with that, let's go back to our slides. All right, I see I'm unfortunately out of time and I really wanted to show you API management. But the good news is my colleague has filmed the video just about that. And you can see the short URL here to learn more about API management. And if you would like to dive deeper on API apps, visit our azure.com documentation site. The full link here for API apps is right here. And if you have any questions or want to reach out to me, you can reach out to me at mohit on Twitter. Thank you very much.