Building APIs with Amazon API Gateway

awesome welcome back here to the 80s loft in San Francisco here today for those of you here in the room thanks for getting to stay with us and joining us here in person all this week we've been covering recaps of reinvent launches and kind of updates into the technology space that we have here at AWS today's day is focused entirely on the surrealist platform of services that we have our portfolio I should say of products and so far we've had three different sessions here today we have covered a view into lambda and service applications spend a little bit of time talking about some of our tooling including the AWS Sam template engine and the Sam CLI and then just before this we covered the lambda layers and runtime api announcements from reinvent to really big key critical features in AWS lambda that were really excited that we were able to announce we're continuing on here today in this next hour we're talking about API is the API gateway and then again at the next hour we will finish up with diving little bit deep into a Tobias step functions if you're just joining us again my name is Chris Mons I am currently a principal developer advocate for service here at AWS based in our new york city office been an AWS for a little over six and a half years across a couple different roles but come primarily from a start-up background worked for a number startups in new york city area primarily and will be considered ops or DevOps just as the admin type roles so why are we here again overall today so again today is primarily about server list but this session in particular is about api's and the power of AP is one thing I like to do and that I've spent a lot of time over the last couple years doing its talking about how we internally in Amazon have shaped and done product development for quite some time if we go back historically and we look at Amazon first launched back in 1994 and grown obviously since then so we're you know 20 and change your old company if you used amazon.com the retail side the retail site back between 1994 and 2001 opened up your web browser went to amazon.com went to the homepage went up to the search bar search for whatever product you might be looking for at that point in time landed on a search results page Danah listing looked at a bunch of different listings read all the information add it to a car went through the checkout flow and eventually checked out all of that happened as part of a large monolithic application and actually we did a lot of things back then in Pearl we had a lot of large monolithic databases and so what we found is we came into 2001 was that this was kind of holding back our ability to move faster and to grow our platform and be able to support new capabilities and features and so we spent some time thinking about how to reshape basically the flow that we had for how we did product development terms of how we had our team shaped how we built this monolithic application and then the delivery pipeline that allowed us to get through deploying out these new features and I like to say that back when we had the monolith what happened as we look to add new features and capabilities is that it wasn't akin to too many cooks in the same kitchen it was too many cooks stirring the same pot everyone adding their own ingredients taking a sip and realizing that the Gulag didn't taste too good and so it's back in about 2001 that we started to go through a really really dramatic transition through how we were shaved as an organization for the people side we moved from these large monolithic teams to something that we now call a to pizza team model kind of a small cell based mini kind of a team inside a larger whole we broke down the application into micro services and now these teams are highly pelo allies delivering their own components in terms of how we think about our architecture again we do what today is considered architectural II microservices so we went from that one big monolith into what you see here which is actually an image from about circa 2008 2009 all of the services that were inside Amazon so this kind of Death Star's looking diagram as I like to describe it here again represents all the various different capabilities and services and stuff that you see now again but now almost a decade ago so the lines of connectivity represent dependencies across these so which services were dependent on each other and so in the middle there are kind of common services like authentication and authorization and other things that were used across other services now the each of these little boxes basically represents something that has an API and services were basically shaped that they would only connect to other services API to get information and you could only share your own services information via an API so it's very much ingrained and the culture of how we think about software now primarily these connect over HTTP there are some other means for transferring information today things like services like SNS or queues or other streaming services but by a large HTTP restful api is what we've built and we could certainly to be largely black box from each other so if i am building a service and you're consuming it all you really get to know is my services API spec the performance you should expect and and you know what my api does so you don't really get to know what languages were in in operating system it runs in what databases I use any of that kind of stuff another way to think about this is that we first launched AWS s3 so simple storage service one of the first services we had here at AWS believed back in 2006 when we first launched that product it had eight separate micro services that made up what it is and now this is an image here from reinvents where one of the leaders of s3 got up on stage and talked about the history of the product and so started at 8 back in 2006 and we jumped forward to 2018 s3 is actually more than 235 micro services just one product 235 micro services now s3 happens to be a product that has a whole lot of capabilities does a whole lot of different things now that it first didn't we launched it 12 years prior but again that's kind of the model that we have as we expand we add more common more micro services sometimes we divide services into other ones all API driven so api's are kind of the name of the game for how we build technology so this leads us to some pretty interesting stats you know today we have thousands of these two Pizza teams building this micro services architecture practicing continuous delivery with multiple environments we talked about things like dev staging and prod before and what it means is that in 2016 we actually did a little more than 60 million deployments that year so that's a lot of deployments again api-based applications now this is just us there's other ways to look at it there's a really awesome book out there called building microservices by a gentleman named Sam Newman it's kind of considered one of the authoritative sources on this concept of micro-services and in relating this to api's Marc Andreessen who's a famous VC here out in the valley has a phrase that software is eating the world he said this a number of years ago there was kind of a retort from a gentleman named dr. Steve Wilmont who's currently at Red Hat and represents the API space from them who said well it's ap eyes that are eating software all right software that people are designing today by and large is API driven so here's your small little biology lesson of the day does anyone know what honey bees have to do with building micro-services anybody nobody good so I could teach you something non-technical today so if you went into your favorite web browser and you searched for AP is which you might think of as AP eyes it could also be APIs which is the genus for honeybees and so you might occasionally get lost on the the wrong page looking for information about AP eyes or you might be really interested in honeybees but so I don't know for sure that Sam and the folks that are Riley put honeybees on the cover as part of kind of a tongue-in-cheek joke I think that they did but there's a relation that you have between the two of those anyway a little fun fact more about API so again they show up all over the place right many of us are wearing or carrying a device that are talking to AP eyes all day long again whether it be the the phones and our pockets the things on our wrists the cars that you might be driving if you have one the devices that are around your home increasingly api's are everywhere terms of companies that have been very disruptive in in various different industries they have been largely around building ap is if we talk about Airbnb you know the headquarters just down the street here they've been building api's for the last ten plus years uber square slack all API driven organizations and how they build their architectures and their technology so API is super critical super important the way that we think about modern software today and getting away from this these concepts of the monolith let's are about building your api's and I'm going to assume here that most people here already have a fundamental basic understanding of what api's are and how they work let's let's you know kind of take it from a low level and then go a little bit deeper alright the basic technology stack for an API is typically you've got a client the internet or a network some sort of API server some sort of back-end and then databases data stores etc that you might be talking to now when it comes to things like api's there's basic ways that you can do them and then there's ways that you have to do it if you want to expose your API to millions of customers similarly to what we do and many other companies that are out there and even internally when you're managing API is there's a number of things that you struggle with things like managing multiple versions environments so stages in our terminology if you need to expose access to other developers so companies for example like stripe here have an API exposed developers that's incredibly popular access authorization can be a challenge things like traffic spikes dealing with management overhead of having to maintain this layer and so this is typically where people think about having some sort of API gateway and so again I mentioned this earlier today API gateways as a concept is not something that we invented here at AWS there are many different API gateways in the industry there are hosted api is there are Enterprise API is you can buy they're open API gateways that you can find but one thing that I've been encouraging companies for for half a decade now is find an API gateway product and centralized on it get everyone the organization use the same API gateway standardize on it for public private whatever it might be find an API gateway happy to be slightly opinionated I think that we have a pretty amazing API gateway product here at AWS it's got a lot of capabilities and I'm not going to read for the laundry list of these here but just to you know cherry pick a couple ability to get out API keys for developers being able to do things like throttling and modeling at usage tiers SDK generation that's a pretty cool one DDoS protection there's a whole lot of stuff that you can do with amazon's api gateway it also meets the key criteria for a service product so you don't pay for it when it's not in use it automatically scales it's automatically available there's no servers you have to set up manage for API gateway and if you've been here in the room for most day or if you've been following on Twitch you've seen us briefly demo some capabilities of API gateway just really quickly now API gateway is has been around for about three and a half years now has a number of capabilities to it it's really robust piece of technology or service I should say and so we've got different ways of exposing api's out to your services or your clients and then different ways that those api is can be powered and we're gonna go into all that stuff right here now I mentioned this very very early today but just coming back to it again we did just announce a couple weeks ago support for WebSockets and ap is now WebSockets representing an interesting shift in the API space in building near real-time API interaction where from the backend of the API you want to push a message out to the consumers of that API so this can allow for really interesting things whether it be mobile apps or dashboards or IOT or chat BOTS and stuff like that now WebSockets as a technology itself is not new but one of the challenges in the space of service has been that traditionally the compute tier that handles interfacing with your data and your customers has to store some state about which clients there are involved in the WebSocket connection there's an active client and there's a state that has to get managed now this has resulted in people needing to run very outsize compute tiers because they have to track all that state even if messages aren't being pushed and so this can be a place where web socket API eyes can become very expensive one of the challenges we've had in the service space is that server lists workloads by default out of the bag are just kind of ephemeral lambda functions go away they don't maintain state API gateway is kind of a transitory proxy at the end of the day so this is pretty new and pretty different and pretty exciting because basically what happens here is that API gateway manages that state for you it tracks the connections and and what clients are around and then any back-end can be used for your WebSockets API and again with this you're not paying for you know servers you're only paying for what you use with API gateway now in terms of what goes behind API gateway again whether you're doing WebSockets or just normal rest-based HTTP API is could be almost any computer service you could think of so you could certainly put ec2 or one of the load balance products that we have here at AWS behind it you can put a container behind it and this can be a container running from one of our services or if you run kubernetes yourself or something else and then obviously lambda which we've shown a couple times here today now when deploying a micro service with ec2 it's pretty straightforward you're typically going to have ec2 configured in an auto scaling group maybe maybe not but that's general best practice then you have some sort of a load balancer so elastic load balancer application load balancer and LB or network load balancer depending on what your need is from that load balancing tier you'd put that behind API gateway expose out your web interface from those services and then API gateway can handle the outbound interface to your API with ECS or eks or far gay or kubernetes or any container workload your options are either that you run something like nginx locally that represents out a service or you put those behind a load balancer as well and in this case API gateway then is representing back through those to the container based workload that you have and scaling and all of that is handled either by the service or by something like auto scaling behind the scenes now we've already kind of covered lambda earlier today and so again what happens with a lambda based back-end is that API gateway calls the lambda API to invoke it you never need to think about scaling it you never need to think about load balancers or anything like that API gateway will just automatically call the lambda API for invocation of your function so this represents again a number of different architectures again with the API gateway and lambda it's pretty straightforward it just invokes the lambda API but you can actually put API gateway in front of a number of different things so we can put in front of step functions which we're gonna end today talking about step functions so this could be really useful if you have a a synchronous API that needs to kick off some sort of a workflow behind the scenes you could also and I think this is one of the coolest things you do with API gateway that people don't know about is put ap gateway in front of almost any aw service that you could think of and so one thing that we see people do is have say a mobile application that needs to just get data back and forth from a database like RDS or like dynamodb what you could do here with DynamoDB is just map the dynamodb api behind the api gateway expose out any sort of api from the api gateway that you have there and do all of your logic for how you handle creates reads updates and deletes in your mobile application so instead of even having a computer you can just directly exposed DynamoDB up to your application but you can use things like the api keys the api gateway provides usage here's throttling caching of the information in the api gateway again without having to manage your computer so that's pretty cool you can put it in front of things like Kinesis so you can expose Kinesis out to motive things like mobile applications so if you wanted to collect say session information or tracking the information about that from this mobile device I could have it talk basically directly to Kinesis through API gateway without having to embed in my app say AWS credentials so just a couple of examples that you can do there you can also put API gateway in front of resources that exist inside of a private data center for example via direct connect to your AWS accounts or your Atos VPC virtual private cloud you could expose private resources inside your data center you can also put API gateway in front of any public HTTP endpoint you have an app running in Heroku you can put API gateway in front of it I've been operating another cloud provider you could put API gateway in front of it so it can be backed by anything publicly or basically privately HTTP serving now you have three different types of endpoints to choose from and they represent all sorts of different needs that you might have one is edge optimized so this was the first that we first launched API gateway with and this is where we basically will give you a cloud front which is our CDN service distribution so cloud front has 100 plus points of presence around the globe I think we're almost about 160 or so points of presence if I can remember the number right and what this means is that if you have users that are connecting from the web again browser or mobile based you can make use of the acceleration of having a CDN service in front of that API you might also have an API that needs to be exposed just inside of a region or one that you want to bring your own CDN configuration to and then you can use a regional API and so if you are using another CDN service like fastly your Akamai or something like that you could put that in front of your regional hosted API and then lastly private API is so something launched just last summer these are API is it exists only inside of your virtual private cloud and so this is for things like internal micro services that going back to the diagram I had of s3 being 235 micro services almost all of those are private into the infrastructure and not consumed externally by customers and so again supporting that growth of the micro services world that we see so sticking with the theme of today let's again saying that we chose we haven't got API gateway we're gonna have lambda as our back-end tier and then whatever database we might have behind the scenes now I mentioned this earlier but just to rehash this one really really common architectural pattern that we see that's that's growing rapidly today is this concept of a service web application where the entire stack can be serviced pay for what you use no permanent infrastructure and no servers that you run and again this is a situation where you're using typically some sort of modern JavaScript framework to represent your web application whether it be something like react or view or angular or any of those that would get stored in s3 with your CSS and and other static content and served out with s3 as a web server now that could optionally be fronted by cloud front and then although your business logic could be an API gateway and lambda and again with this you have automatic scale just pay for what you use high availability no servers to manage so pretty exciting and something that we see kind of shifting the industry in this way so let's talk about security so going back to that diagram that we have of all of the various capabilities of API gateway where would you imagine from here that you could add security well the answer is actually everywhere there's different ways that you can add security to every single bit of this stack right we could have security at the client-side so your customers need to log in with a username and password in order to access your back-end you could also have specific API keys that only exist in the mobile device then able to access the backend to the V and a half things like encryption on the wire so API gateway is gonna use SSL for the AP is for API gateway to your back-end in the case of it being lambda it's going to use iam permissions to say whether or not you can talk to that lambda function or if it was other backends you could do things like be able to authenticate that back-end and then from your lambda function to your data base which we've seen earlier today you have the function policy which says what can this function do and what can it talk to you so we can add security in all these various places but in talking just about API gateway we have a couple different security mechanisms that exist just at the API level so we see here we have I M permissions so this is basically the ability to say that I am or AWS credentials can be used to access an API and interface with it we have a lambda custom authorizer so this is where you would write a lambda function to interface with some sort of custom logic this could be a user management system that you run this could be a user a lambda function that interfaces with something like auth0 or you know any other sort of identity provider that you might be working with we were something called cutting user pools talk a little bit more about here in a moment which is a completely managed user management system and then we have a concept called resource policies what's unique about resource policies it ties into things like private API endpoints you could say all of the services in my VPC can talk to this or just certain subnets or just certain AWS accounts and it's kind of a wider way of scoping who and what can access your API gateway now lambda custom authorizers are pretty popular if we see this for people that have an existing user management service where they are already handling things like API keys or some sort of other credential that they give to their customers and so you can create a lambda function that basically interprets the success or failure of accepting those credentials and then uses a token to tell the api gateway you know this is good or not more or less simple i version of it i gave the example earlier of how we had had a request for basic HTTP off for API gateway it's not something built into it and so the lead p.m. for for API gateway actually went and built one and hacked it together and published it in the service application repository and so you can have everything from basic username and password up through more sophisticated you know tokens or security keys lambda custom authorizers basically support any of that now if you don't want to manage your own user system which is something that I would never encourage anyone to do their options like kognito user pools and so what user pools do is give you a completely managed user credential and information management system you can have everything basically handled for you from sign up and and sign in workflows being able to do things like have multi-factor whether it be a token or an SMS email verification password resets it could also do things like detect if people are trying to log into an accounts like trying to brute force into it and react to it there's a whole lot of capabilities and coming into user pools we could probably spend a whole hour talking about that but in general this is one of those things that as a developer running your own user management system is not providing value to your business and so it encourage you to look at the the various providers that are out there this technology verse building this stuff yourself so start a little bit more about what goes into deploying API so we've seen today so the really basic examples of what you can be done with surplice api's and using Sam for example to deploy them but it's important to note that we have a lot of customers that aren't using lambda behind API gateway they're using things like ec2 or ECS or other technologies and so it's important to know how to deploy api's without Sam I've mentioned a little bit earlier there's this concept of stages and api's you can use these for things like lifecycle management so having dev tests prod or alpha beta gamma a side story when I worked at Etsy we we had a strong kind of back and forth about what we should call the pre-production environment and we argued about whether it should be called pre prod or staging or whatever it might be and instead we settled on princess so we called our non production environment princess and you deployed to princess before you deploy to prod and it was just because we realized the term didn't matter but in this case you could have an API gateway for princess and an API gateway stage for prod and and do that so whatever you want to call it you can call it that but essentially think of them as separate out environments that represent the same API definition and spec over time now these have API gateway stage variables that align with that stage that represent you know effectively key value pairs that can be passed down to customize the functionality of that stage at whatever stage it is so for dev I could have certain values passed down for product and have certain values passed down and again we gave the example of how you can use this for doing traffic shifting in lambda and and we're not at least and be able to map these stage variables back to things like lambda aliases and versions and be able to do things like true software lifecycle promotion processes and fun stuff like that but API gateways got a couple capabilities that make it powerful beyond just what you can do with interfacing for example with lambda and so API gateway does have its own concept of canary support we talked about Canaries with Sam and safe deployments earlier here today but with API gateway you can do a very similar thing where you can shift a certain percent of traffic to a two-year customers of your API and so this can be really useful for a number of different things a deploying from version one to version two of your application and you want to push out just a small amount of traffic you could do that but what's really interesting about API gateway or one interesting thing I should say about API gateway is that we see customers using this to do a lot more creative and interesting things let's say that today you have an API that's running in a traditional monolithic sense or you have an API that's running on virtual servers you know running inside of AWS or anyplace else we'll see customers use API gateway as a mechanism for migration so put an API gateway in front of your API that is monolithic and running inside a virtual machines and then basically use Canaries to shift portions of traffic out to a new back-end and you can do this on a method by Method basis you could take a sing API call from the entirety of your API and pointed at lambda and test it for a period of time that you define indefinitely a couple hours a couple minutes a couple days and then decide whether you want to shift traffic in one way or the other obviously people will be able to do use this to take api's and move them from on-premises up to the cloud so taking them from their data center moving them up to an AWS environment and so again you can get really fine-grained down to the method level shifting this traffic or you can do an entire API or you can do again various different parts of it again pretty straightforward I have version one of my API I'd like to I'd like to deploy version two so I could figure up in deploy version two on API gateway and I don't do anything with my API clients they're going to a certain back-end and that's just gonna be there behind the scenes or the API gateway definition stays the same from like a URL perspective and then whatever's going on in the backend is separate and different and that's fine and now I could sit here and again we generate different logs and metrics for the different versions of your API so I can go and compare and contrast against those and then if things don't look good I can merely roll that back if they do look good then I can roll it forward and move on to v2 and again my clients don't ever have to know what's shifting as part of this so really great for doing migrations I've seen customers want to do it for trying out different languages hey we've traditionally written this API in Java we'd like to explore go on a method by method basis you can move to go and change out the backends and so again harder to do without an API gateway product so how can we do other things right how can we get our clients to connect to our API now it's trivial to just publish an API definition until your developer customers if you produce an external API or even internally to other teams here's an API spec go get them but one thing that I really like is when companies actually produce client SDKs and so with the API gateway we can create client SDKs of our API so assume that I define my API in something like swagger now called open API which is a template driven way for defining ap is kind of a standard so I defined my API to play it up to API gateway I've got version 1.1 I can actually say hey API gateway give me an SDK or give me code in nodejs that represents my AP is and it's going to give you a zip file that has all of the code that you need in nodejs for basically all of the functions that are inside of your API and I could take that and I can wrap it up as an NPM I could put that in some sort of NPM repo publicly or privately or I could put it in a lambda layer for example and then I could tell my customers externally or internally hey here's version 1.1 nodejs client for my api go and consume that and they consume that codebase points back at the API they don't have to know my API spec they don't have to write a whole lot of code I'm giving them basically the keys to access this data over time I might decide that I'm gonna release the next version of my API and so I just go through the same process you swagger document upload it up to API gateway chin Arena new client SDK wrap it up as an NPM or whatever or a layer publish it and away you go and so it's it's pretty straightforward to do this but it's pretty powerful and I think that if you're building ap eyes that are meant to be consumed by not your organization or even yourself generating an SDK will save you some time and being able to do that now the SDKs that API gateway generates for you follow best practices that we have at AWS so by default they will do things like back off and retry if you so configure it the code is there and so it's an interesting learning tool as well I would say now one thing that we've recently done this happened right before we invent but we continue to put more capabilities into it is we relaunched the API gateway developer portal and so this is something that you can use to expose to the customers of your API publicly or privately and we've actually launched this as a service application so I am going to show that to you now so I can come back in here to the lambda console and go to functions great function start this app repo let's see I type in are there remember the right search phrase right here easiest way to find it is Amazon API gateway developer portal and we'll find out what's new I'll just go the documentation that's right and in the documentation here it will link to the name for this second yeah cool so this is the the application detail here in that's right it doesn't have the word developer the title just deaf portal sorry so this is the application here in the service app repo again I can go in here and just click deploy and it'll take you back into the console and I can find out all sorts of of aspects about this it has a bunch of application settings it's got a rimi file that walks directly through all of it and what you end up getting after this is deployed is a really sophisticated stateless application it's actually a really great example of a full-fledged service application that has 31 resources that come out of it api gateway definition a whole bunch of lambda functions Cognito user pools and s3 buckets and so it lives in an s3 bucket and so i think if i remember where second here if I come and get the outputs for it that's right this is the CloudFormation console just watches via Sam that's right sorry I broke this earlier anyway you can come and find this here and launch it pretty tribute I again linked out of the docks but the Deaf portal is really powerful so you can go through and publish an API for it we're working on a lot of other capabilities so it has full documentation has things like keys that you can generate for developer customers and so I would definitely encourage you to take a look at the developer portal we're gonna be adding a whole lot more functionality to this real soon team's cranking away on it and so this is something that is is pretty new in terms of API gateway okay couple of things here about APA gateway I always like to say that you can't move fast if you're not measuring what you're doing as a former operations person as a former operations devops is kind of person and I've spent a lot of time building out metrics logging and monitoring systems I am really happy that this stuff is all built into the service ecosystem today and so inside of both API gateway and lambda we capture a number of metrics for you they're just generally made available and can be consumed inside of lambda code you can also create custom metrics using the cloud watch metrics API call for put metric data in terms of logging it's the same way so API gateway actually has a number of capabilities for capturing log data for you you can specify the level of the logging so error or info or both of them you could also capture full-body request content though I would caution you that this could be a lot of data to store for a really busy API and you do pay for logs so you want to turn that on when you're doing debugging but potentially not all of the time and this could be configured at this stage or per method so really fine-grained if you want to say do what I mentioned before about transition single API method to a new back-end you can specifically turn on full capture for that and be able to get that information lambda similarly has access to to logging as well captures anything that's just output and then you can do things in cloud watch logs such as what's called log pivots which allows you to generate essentially a regex or a regular expression that can pull data out of your log lines and generate metrics and alarms based on that and then dive into those and the other thing is is that it's really easy to take those logs and then put them into I'm sorry this should say elastic search for s3 and then look at them with things like Cabana or ethene or quick site now integrated into API gateway and I think it's really pertinent for API gateway is something called a table x-ray and so 80 of us x-ray allows you to do profiling a tracing of calls in a distributed system so you know thinking about that 235 services that make up s3 knowing how traffic and how requests are flowing through some number of those is really important and so with x-ray which is supported in apa gateway it's supported in lambda a number of other AWS services we actually can see a map of what the request flow looks like from a service call perspective across different services so this can be really useful for understanding where there might be failures or issues you can see histograms or performance and be able to go back and look at what failed when and potentially why and so it shows you this this cool little graphic that you see here this service map it also gives you a waterfall view of calls that were made inside of the flow so if I had an API gateway based example here you would see the first service being a PA gateway that talks to a lambda function that maybe talks with database and I can capture that full flow of calls and see how it's performed over time now I mentioned this pretty briefly before that I again with API gateway there are lots of people that are using it without lambda it is not just tied to lambda and for api's and api definitions in general there was a tool called swagger that's become very popular in industry in version 3 renamed itself to the oppa API specification or OS for short and you can use this to define out your AP is now when you use Sam to set up a service application we actually generate behind the scenes swagger text for you in cloud formation you can actually embed swagger into cloud formation but you can create this yourself to define your api's and there are a number of testing tools monitoring tools security tools that will take a swagger document and do things like generate a test suite generate monitoring generate security tests or validation and so swagger / open api is really great it's the Extender specification for this and so encourage you to take a look at this just for you know interfacing with a third party world that's out there so let's go again real quick here and pop out and hop into the API gateway console we spent a lot of time here today in the lambda console but here in the API gateway console there are all sorts of things you can do so we can see here I have a whole lot of different API is defined you know earlier before we were talking about layers in runtime I showed you that I had a PHP API and it was a really basic thing it has a single resource just slash of my URL and then it supports any call that I want to make to it in terms of HT peak also puts gets the leads post etc now we've got other api's that are a bit more sophisticated let me go find something here well for example we have our magic 8-ball which had the route for 8-ball as well as in any see if I can find it slightly meteor example I have another API here but let's actually dive in look at how these are configured so again this is the resource I just have a singer call that I suppose that I support here for slash in terms of stages I have a prod stage and a stage that's just called stage and I can go and dive into that if I want to set for specific types of HTTP calls how I should respond and what I should do in this case it just inherits it from the overall stage and the overall stage level this is where I can go in and set things like cache settings I could change the way that logging and tracing happens I could set up stage variables I could do SDK generation I do document history sort of Canaries all sorts of stuff like that I could also come in and do things like shape gateway responses so let's say that you were putting an APN gateway in front of a legacy API and that legacy API doesn't do the best things sometimes you may actually want a service to respond with a 200 code and an error message versus a 400 code which would potentially cause a failure in a client just as an example so you can come in you can configure all of the HTTP requests and responses you can model different types of mappings for things I have a good example of that here and then obviously there's a dashboard in here for seeing what's going on in this API so lots of information that you can get from this lots of things that you can set and configure inside of this and so a valuable place to become familiar with cool so just wrapping up you know again we've talked about a number of different aspects around API is already here today but the importance of API is in the industry and how people are building software I think is still even kind of in the early days there's still companies that I think aren't paying attention to the importance of how to think about building api's but again the devices we wear the technologies we interface with the companies that have shaped the various different industries that are out there are building api's and there's a good chance that it's something you'll have to become familiar with benefits of things like api gateway in terms of there not being infrastructure that you have to manage automatic scale paying for the value that you get for it so not paying for idle obviously incredibly important lots of different integrations for authentication authorization getting the various capabilities about supporting different types of how the api is exposed edge regional and private different backends so EC 2 containers lambda anything out there on the internet means that you've got a lot of different things that you can do with api gateway just like I was with a lot of the other stuff we talked about here today you can find out this and more about the API gateway building api's on AWS to amazon.com slash server lists again if you look at the white bar up there you'll find access or you'll find links to things like the application repository developer tools resources various partners and stuff that exists and so like in the resources for example you'll find all sorts of getting started stuff for building api's and managing api's so encourage you to check that out again my name is Chris Munn so you can find me at months at amazon.com or actress moans on Twitter I we're not done here today we're gonna start up here at 3:15 here Pacific time talking about step functions but for now we're going to take a quick little break and come back to that thank you for everyone who's joined us here remotely on Twitch again we'll be right back real soon here with the rest of our day and for those of you here physically in the loft thanks appreciate you being here and hope you stick around for the last session so thank you you

Channel: Amazon Web Services

Views: 71,874

Rating: 4.8210678 out of 5

Keywords: AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud

Id: XwfpPEFHKtQ

Length: 43min 3sec (2583 seconds)

Published: Fri Feb 01 2019