Let's Learn .NET - Web API

>> Hello everybody. Hello, Cecil. >> Hi. >> Thank you-all for joining us here today. Good morning. Good evening. Good afternoon. Wherever you are joining us from, we really appreciate you taking that time to spend it with us here today. Who are we? My name is Jayme Singleton. I am a Program Manager here at Microsoft for the.NET community, and I'm joined with my good friend, Cecil. >> Hi Everyone. I was just taking a look in the chat and I'm seeing we have people from all over joining us today, Canada, Quebec, the Philippines, Moscow, like all over the globe. >> This is amazing. >> Yeah, it's awesome. Thank you-all so much for joining us today. Jayme, why don't we tell folks what are we doing here? >> Sure. Today we're here to cover learning all about Web APIs with ASP.NET Core, we're going to go into what Web APIs are, what.NET is, ASP.NET, and how you can use them in your everyday life, and why they're important >> If you head over to the website, which is let'slearn.net/webapi, the entire agenda is there, so you can see exactly what we're going to cover today. We're going to go through some modules using Microsoft Learn. The first module, we're going to talk about what APIs are, we're going to talk about consuming APIs, what are some of the use cases that we have for you. Then in the second half of it, we're going to talk about actually building Web APIs using.NET. We're going to use the.NET templates, we're going to use Visual Studio code. I'm going to do it all on a Mac because we can do that now because now that is open source and it runs everywhere. >> Amazing. Tell us a little bit, Cecil, what is.NET? What are APIs, why do they matter, why do I care? >> Sure. Let's start with what is.NET? For me,.NET is a platform that allows us to write any type of application that we want. If you talk about writing mobile apps, desktop apps, web apps, Web APIs, even if you want to write microservices.NET gives us the flexibility to write any type of application using tools like Visual Studio, C#, F#, Visual Basic. For me, it's just like a great experience that I could use the knowledge that I have across these different platforms. Now when we talk about Web APIs, and we'll dive a little bit into this as we get into the workshop. But whether APIs, there's essentially a way that we could communicate with different services across the Internet. We're going to really dive in to see how ASP.NET Core really gives us a really good programming interface over creating these types of things. Let's go through the fundamentals section that we have up here. Let's take a look at some of the things that we're going to actually need to start building these APIs. Now, the first thing that we're going to need to do is, we need to install.NET. Usually what I want to do is, I'll head over to.NET/download. Here, I can just hit the download link and I can download a version of.NET that will live on my machine. Now, you see here we have two versions that are highlighted. There is the.NET 5.0, which is the one that I'm going to be using today, but there's is also.NET 3.1, and you can notice that one says it's LTS. LTS actually stands for long-term support, so this means that this is going to be supported for a pretty long time versus the.NET 5.1. Well, this one is going to be supported not as long, but whenever the next version of.NET gets released, then we're going to hopefully push your auto upgrades at that one as well. Now, you can notice here that's up to automatically select my operating system, so I'm on macOS. But again, if you're on Windows or if you are on Linux, or even if you want to run.NET at a Docker container, you have the option to use any one of these that you want. I already have that installed on my machine, so I'm not going install it, but if any of you are following along with us, please go ahead. You can click download, it's not a very long downloaded all it's like click, click, click, okay. It installs the SDK, it installs compilers, and a lot of the tools that you need for us to get started today. Now, the other thing that we're going to need to install to get started, we're going to need Visual Studio Code, or sometimes we call it VS code. When I looked that up really quickly, again, just like before, I can download a version of VS code, and it runs on Linux, it runs on Mac, it runs on Windows. Again, everything that we're going to show you today is going to be able to run across different operating systems. Using VS Code and.NET, regardless of whatever operating system you're on, you're going to have that same experience across the board, which is one of the reasons why we wanted to use these sets of tools. Now, I already have VS Code installed on my machine, but what I didn't want to show you is some of the extensions that I have installed already that are going to make this a little bit easier for us as we build our applications. If I head over to the extension section, first thing I want to do is look for C#. The first option that you're going to see here is C# from Visual Studio code. Now, I already have this installed, but again, you can go ahead and hit the Install button. This will give you some of the tooling and the debugging support inside of VS code that you're going to need to do that. The other tool that I have installed is called The Rest Client. We may use this, we may not, but it's another great tool that I like to use whenever I'm building Web APIs. It allows me within VS code to be able to make requests and, you know, look at my HTTP requests and responses so I can test it out in the space whether I have it jump around so much. Does that make sense? I'm going to guess that makes sense. Now, after we have those things installed, let's see, those are everything that we're going to need. Why don't we start off and head over to the workshop and see what we're going to do? I'm going to come back over here, I'm going to close these windows because we don't really need them anymore. Let's take a look at our agenda. Let's start off with the first part of the workshop. This one is actually hosted on Microsoft Learn, and this one is called Explore the art of the world by using RESTful APIs. Let's go ahead and kick it off. Here you can see some of the learning objectives we have. We're going to learn about RESTful APIs, we'll learn some of the strategies to connect to external Web APIs. We're also gong to talk about querying Web APIs and we're going to see a couple of examples too. Let's go ahead and kick off this first one. Now, in this first section of this Learn module, my buddy Broke down here has a really cool video that he goes into depth about what exactly our Web APIs. He actually says here in the section, he thinks Web APIs is like a kitchen sink. He thinks that the kitchen sink is the API between you and the pipes, and the pipes are that a thing that supply the water to you. Me, I think is Web APIs is like the interface into the worlds. If a webpage for instance, is the window to the world, Web APIs are like the road that we run on. That makes sense as an analogy. But let me actually head over to symbolize. I'm going to give you a little bit of a better example. When I think about Web APIs, I think about, let's separate those two terms, we have the web part, and then we also have the API part. When we think about the web, we usually think about how we can communicate with each other back and forth over the Internet. We think about things like web browsers and HTTP and the ability for us to search for things online and those types of things. When we think about APIs, now we're thinking about contracts of programming languages that allow us to run certain operations on machines, whether they're local or remote. APIs actually stands for Application Programming Interface. There's a lot of different types of APIs that exist on your machine. When you put those together and you get web and APIs, those are really just APIs that you could use, operation that you can invoke on a machine, whether it's local or remote, and you can use that inside of your applications to create some really interesting experiences. Now, if you building different types of apps sites, like mobile apps with Xamarin, maybe desktop apps or UWP, games, web applications, we'll even Web APIs as well. You know, all of these can make use of Web APIs to create a really interesting experience. You can imagine you're doing something like, you know, looking at product information or storing contacts. If you having a game maybe have a leaderboard situation where you're trying to see who has the highest score. Web APIs have great opportunity for you to be able to pull in some of this information into your app and make use of someone else external services. Now, some examples of Web APIs inside with the Microsoft ecosystem are like Microsoft Graph, for example, which is a really big API that gives us a lot of information about what's happening inside of Microsoft 365 accounts. Also, we have Azure DevOps, has an API too. If I want to know about what's happening with my bills, what's happening with my check-ins or my CI/CD pipeline. I can use the API to bringing some of that information. Also, we have cognitive services, which as machine Learning, we have PlayFab, which is an API that you could use for gaming type of scenarios. All of these are really just great examples of how you could bring these APIs inside of your application. Now, let's go forward a little bit and let's head over to the next module. I'm not going to read through a lot of these because I believe you could read these through yourself. It'll be pretty boring to have me do that. I'm going to go ahead and take a step forward really quickly. Now, in this first part, it really wants us to start building an API. If you take a look here at this first section, I'm going to zoom into this a little bit so you-all can see it better. It actually wants you to use Node.js and install this thing called the JSON server. Using that server, it wants you to point to some file, this right here, and it's going to use that to bootstrap an API for you really quickly. Now, since this is a.NET event, I'm not going to write it in JavaScript, but I am going to go ahead and create one in.NET that we can start using. Then as we go down a little bit, it talks about how you can use that API that they just built to issue various types of queries. For instance, if we enter a particular URL that says objects here, for instance, we should see it return a lot of those different types and a lot of that different information that was coming back from that thing. What I'm going to do, I'm going to go head over to VS Code. I'm going to close some of these things because you don't need to see them. But I actually went ahead and created some of that endpoint for you. I'm going to go ahead and run it with a.NET run. Now I'm going to actually copy that URL. Notice it says local host 3,000, just like it did in that learn module. I'm going to paste this in my browser and I want us to take a look and see what exactly we are getting back. I'm going to open a new tab and I'm going to paste this in. Oops, that's not what it's supposed to be. I forgot something. See, this is a good example of why you shouldn't copy and paste. When I hit objects, what it's doing is returning to me that response back from my API. Now, if I open some of these little objects that are inside of here, you can see some of that data. Some use the information as what this looks like. There's some dates in here and so on and so forth. Now, some of you might be wondering, well, why does this look like this in Cecil's browser and it doesn't look like this in my browser? Well, I'm actually using an extension. I'm a big fan of using extensions because it makes that development experience a little bit better. The extension that I'm using, I'll show you what this is called. It's actually called the JSON Beautifier and Editor. What happens is that whenever I make requests or whenever there's a web thing that returns JSON, it's not going to look like a big wall of text, it's going to give me that nicer experience that I can navigate through. This is just the one that I like to use, you might have a different one that you use. One good way to just search for them is to head over to the extensions section. You can click on "Get extensions", then usually you could just search for JSON. Then you could see there's tons to options here and you could just pick the one that you like. This one just happens to be the one that I like. But what you're seeing here so far is that I've just made a request to an API, and that API is returned to me some information about the data that it holds. You want to think about APIs as an interface into your ability to use certain resources. In this case, the resources that this one is containing is information about a museum. You're saying, hey, I want to be able to get that information. If you think about some other operations you might want to carry out, you might want to do, like create, read, update, or even delete some of those resources. I will see as we go on some options for us to be able to do that. All right. As we scroll down a little bit inside of this API, it's going to talk about things like API endpoints. My API endpoint essentially is like the address of where my API lives. Because if you think about it, APIs live on the web or it's just on some HTTP thing. We need to know, well, how do I access that thing that I want to use? How do I get to that API and how do I make a call to get the information that I really want us to work with. That's where HTTP comes in. HTTP stands for Hypertext Transfer Protocol. It's a protocol that allows us to communicate with APIs or Web servers. It doesn't matter whether they're local or remote, but it allows us to be able to share information between each other in a very uniform way, which I think is pretty cool. I'm going to head back over to the slides here really quickly. I don't want to talk to you about how HTTP allows us to flow information back and forth between two places. Imagine Jayme, my friend who's here with me, wants to find out some information about some shows that are happening on Channel 9. She might decide that, hey, she's going to go over to our web browser, she's going to type in channel9.msdn.com and then her web browser is going to make a request over to that endpoint. That endpoint, again being https://channel9.msdn.com, it's going to generate that HTTP requests, which is going to get sent over to some server that exists somewhere. Now, those servers their job is to receive that request, process it, and carry out whatever operation that they need to carry out. They're going to generate a response and send it back over to that browser. That browser essentially is going to take that information and turn it into something useful that the user can consume. I'll usually call this a request-response model or a client-server model as well, where your browser's acting as the client and the server, well, server's acting as a server and their job is to process requests that come in. Now, here's an example of a URL. We spoke about our APIs needs to have an address. I need to know how exactly I could reach my API. URLs are essentially like the address. Like how do I reach this API? URL roles are broken up in so a couple of different parts. First is the scheme. The scheme lets us know well what type of protocol am I actually using. In this case, you can see that we're using HTTP, but it could be anything else like FTP or something different. But for web APIs, we're probably going to be using HTTP. Then the next part of our URL is going to be the host name. The host name let's us know, well, what is the domain that this thing lives at? Here in our example, ours is graph.Microsoft.com. Then the last part of that is the resource. What's the thing within this domain that I'm trying to get at? In this case, I'm trying to get at my information, which is why it's a /v1.0/me. I want to know about my stuff. We read this API left to right it's saying I want to make an HTTP request to Microsoft Graph to get information back about me, right? Now, using things like HTTP methods like put and post and generating requests, we could send requests to this API and then we can get some information back, usually in JSON or some people like to use it in XML format that we could start integrating inside our applications. All right. Let's take a look back at this API that would have been created. Hopefully some of you may or may not have gone ahead and tried that out, that little Node.js example out and taken a look at this. Now, one of the things that you see it allows us to do here, notice it's saying that the method we use whenever we made that request is that HTTP GET. Now, inside of Web APIs or inside of HTTP, there is a lot of different HTTP methods that we can make use of. For instance, you might have heard of HTTP put or post. You might have heard of deletes or even using patch. Whenever we're building APIs, depending on the type of operation that we're doing, we can use those and map them to certain HTTP request methods or HTTP verbs, some folks called them HTTP verbs, to carry out those various operations. By default in our browser, if I go ahead and paste something in the browser, it's just going to do an HTTP GET. It's going to say, hey, get me the thing that's coming from this place, which is essentially what we did. But what if we wanted to do some other things? What if I wanted to create an object or delete an object, right? We can map those to those types of HTTP methods that I spoke about earlier. Let's keep on going. Actually, it's test time. I think it's time to test Jayme. I hope she's been listening to me. I don't know if she's still here or not. >> It's like it's the time now. Okay. >> It's quiz time. >> Lets go. I have been [inaudible]. >> I hope you have. What we're going to do, every now and again within the chat, within the stream, we're going to do these little pop quizzes and make sure that you're paying attention and not like watching YouTube or something like that. >> Even though this is streaming. >> First one, are you ready? >> Yes. >> All right. First question is, if the API is a sink, which of these statements are true? Is it the first one that says data is a faucet? Is the data a drain? Or is the data in the pipes? >> I'm going to go with C, the data's in the pipes. >> Data is in the pipes. Okay. We're going to see. We're not going to find out until we do all of them. >> That's okay, that's harder. >> All right. API stands for what? Is it Application Programming Intelligence, Application Programming Interface, Auto Project Interface, Amazing Programming Intellectual. Wow. >> I'm going to go with Application Programming Interface. >> Okay, Application Programming Interface. Are you sure? Are you really, really sure? No pressure., I'm just asking. No? Let's do the second one. It's necessary to understand the entire architecture of an application to use its API. Do you think that's true? I know if we really talked about that, but let me know if you think that's true or not. Jayme, I can't hear you. I don't know why. >> My microphone got muted. I said I'm going to go with false. >> You are going to go with false. All right, so I hope all of you in the chat are going to check it out. Let us know what you think. I'm going to hit "Check Answers" and if Jayme's right. >> I want to see all your answers in the chat and see if you guys are paying more attention than me. >> Hopefully all are following along too and trying the stuff out. All right, let me do "Check Answers" and looks like you've got all of them right. >> Told you I was paying attention. >> I hope you didn't cheat and do this before. >> No. >> Okay. I'm just saying. >> No, I swear. >> I believe you. >> Everybody who got it in the chat amazing. >> I believe you. It looks like it went ahead and moved me forward to the next one. I didn't know I did that. >> Before we keep going, I have a couple questions, Cecil. >> Sure. >> What is the difference between REST and Web API? >> REST and Web API. I want to say that there's a difference. Web APIs are really, like I mentioned, that mechanism that allows us to communicate over an Internet using those HTTP verbs put, post, delete, and so on and we'll talk a little bit more about those. REST is a set of conventions for building Web APIs. They're not difference, but I would say REST is very complimentary to it. When you talk about a particular architectural style, like what are the types of conventions we use? What are some of the expectations that you have? Whenever you make requests and receive responses. That's kind of what REST does. It gives us rules that we need to follow. Now, what you'll find is, some folks follow rules more than the other ones and you'll probably also hear folks talk about the RESTful maturity model. How RESTful is your API and things of that nature. Now, we're not going to get into that debate here today. But I'm talking to you about it because it might be something that you see as you're starting to search around on Google or Bing or something like that and looking up information about REST. Again, today we're really going to focus on just building APIs and we're going to use some conventions. But I definitely wouldn't be telling you, "Hey, this is a super RESTful API we're building today. >> Great. Thank you for that explanation. We have a few questions in the chat. Are you ready to take a few questions? >> Yeah, we can take a few questions right now. >> Amazing. We did get one of them answered already. Next question I have from Singh, is Web API verse gRPC. >> Web API versus gRPC. I'm guessing you want me to tell them what the difference is. All right. Web API is more of a open protocol, so to speak. Web API essentially is really just as using HTTP to carry out certain types of requests. gRPC is more of like a remote procedure call, RPC style of thing. Whenever we make requests, for instance, with gRPC, it always uses binary versus Web APIs or just plain HTTP. It sends information over in texts. gRPC, it uses HTTP 2 by default. I don't think you can go any lower than HTTP 2 when you're using gRPC. For Web APIs are just regular HTTP requests. You can use HTTP 1.0, you can use HTTP 2.0, I believe HTTP 3 is also on the way too. When you think about backward compatibility, that's something you might want to consider as well. Today, browsers have much better support for HTTP APIs versus using gRPC. Maybe you want to build a JavaScript thing or you want to build something using Blazer or something like that. There's much better support for just making regular web requests than using something like gRPC. The other thing I would tell you about gRPC it's, because it is binary, it is a little bit more performer. It's a little bit faster and then we have that well-defined contract upfront. So you know about the different operations that you can call and things that you can do with it. It's usually like a trade-off. Are you running on HTTP 2? Are you building a browser app? How important is that binary format performance worth to you? Then you can way those pros and cons to see what makes the most sense for you. Hopefully, that makes sense. >> Yeah, it makes sense to me. Just for anybody out there including myself, what does gRPC stand for? >> I think it stands for and I heard this name is like the definition has changed a couple of times. But I believe it stands for Google Remote Procedure Call. That's what RPC stands for and the G, because it originated out of Google, but I think they changed it to be something else, Remote Procedure Call. I don't know what the new one is, but originally it was Google Remote Procedure Call. Any more questions? >> Yes, I do have a few questions. I'm playing around with my audio. I think I'm getting a little bit of echo and I apologize in advance for that. We have a few more questions actually. From Satyendra, what is the difference between Web API and Microservices? >> Web API and Microservices. Well, you can use Web APIs to build Microservices. I wouldn't say that there's a difference. It's just a matter of what tool you want to do to carry out the job. Now, Microservices for me are just a selection of patterns that you could use to build scalable distributed applications. If you think about scale, if you want to think about performance, if some of those things are really important to you, if the ability to be able to segment your entire application into very distinct pieces that are independently deployable and scalable, then that's essentially where Microservices give you the benefit. But there's no difference, it's not like a versus kind of thing. You could use Web APIs to build Microservices, and I believe using things like HTTP and gRPC are very common when you folks are doing that. >> Amazing and we will actually be going a little bit diving deeper into Microservices next month at this event. Stay tuned for more information on that. >> That's right. It happens on this March, next month, right? >> Yes, we'll be back here in a month to hang out with all of you again. I have a few more questions though on Web APIs. Let's see, it's a lot of comparing. Next one is go dig too. Okay. I'm going to skip that one. GraphQL versus Web API. >> Sure. GraphQL versus Web API. Again, very similar. Like I mentioned before, GraphQL runs over HTTP very similar to how Web APIs run over HTTP. GraphQL applies almost like a DSL or in particular formats for how you make requests for information. For instance, the way that you query for data or do mutations or change data has a very specific syntax for you to do that. But at the end of the day, they're all running on HTTP. Again, HTTP 1, HTTP 2. I would say with GraphQL, it gives you a little bit more power to give you the ability to query for the parts of the data that you care about. I'm trying to be very specific with how I explain it. For instance, imagine we had this API that we just used. Let me see. I'll paste this thing back in here really quickly then we can take a look at this. With a regular Web API, we'll just get this, we'll get the shape of the data. These are the things that the API returns. With GraphQL, it gives us the ability to specify, again, built into the protocol, what are the things that I want to retrieve? What if I only wanted to receive the item property, or what if I wanted to receive item and artists and not received this entire collection of properties per entity? GraphQL will allow me to do stuff like that. It'll allow me to like pick out the thing and shape the response in a way that I want it to. Which, again, is not as easy to do with something just as like a plain Web APIs. But again, from the underlying protocol perspective, it's still HTTP. You're still making put posts, get requests. You're still using the infrastructure of the web to do that, it's just that, again, GraphQL is like Web APIs plus some extra stuff, plus some extra conventions that make cordiality a little bit more flexible from the client perspective. Hopefully that makes sense. Let me know if that doesn't make sense. >> I did understand that. Feel free to put your questions in the chat if you need Cecil to explain further. We are taking your questions live. Speaking of, we have a question from Chris, from Life TV, REST verse OData. >> REST versus OData. Okay. I mean, it's the same thing like REST versus GraphQL. It's the same thing. I would say GraphQL and OData are two different formats or two different protocols that allow you to have that flexibility in terms of querying for information. Again, the GraphQL stuff looks a certain way and they have their way of doing things. Very similar, OData has it's own way of doing things. One of the things I like about both of them is not only do they give you that control, that ability to select the properties that I care about. But also it gives me the ability to run it in every different programming language that it support across the board for.NET, for Python, for Java, for JavaScript. They are both very open standards. OData is a little bit older, as you can imagine, than GraphQL is. But essentially they can serve some of the same use cases. How do I want to have my data returned to my client? What's the shape that I actually want to do? Or how can I have a little bit more flexibility with the way that that information is queried? But again, it's not an HTTP versus GraphQL or HTTP versus OData. It's more so I look at them as enhancements and not as competitors, I suppose. >> Okay. Then if I were to give you this question from Nan; how would you compare SignalR to REST, Web API, or gRPC, what would you say? >> There sure are a lot of comparison question, what's going on today? That's a good question though, SignalR is different because SignalR is more of a real-time duplex pipe. That's to say, when you think about REST, we think about GraphQL, OData, and all these types of stuff. The requests usually originate from the client. It's a request-response type of thing, like I showed in that diagram a little while ago. The client is going to be like, hey, I want some stuff. Then the server is going to return that stuff. When it comes to SignalR, we have the ability to start that communication from either side. I could send notifications from the server first and then can establish that communication. Or I could send requests starting at the client first. Again, it's really just depending on what you're trying to do. Also too, SignalR, most of the time it'll use WebSockets, but it has other things that it'll use as well. But let's say we're using a WebSocket perspective. Essentially it's sending frames back and forth over the wire, which is very different from something like a GraphQL or OData or just plain HTTPwhich were' usually selling JSON. Then the JSON is usually very human-readable. If I wanted to go on the wire or use something, some type of HTTP clients or inspector or something like that, I can actually look at it and see what's going back and forth over the wire. >> It has a better visual representation, arguably. >> Sure, it does. Then, like I said before, it's duplex. The communication can originate from any place then go both ways. >> Amazing. You're ready? I have a few more questions for you. >> Let's do one more question and then we'll move on a little bit. >> Okay. Question from Macau; when should we use Web API? >> All the time. >> Maybe in comparison to other pieces of tech? >> Sure. When should you use Web API? I would say one of the good things about using Web APIs is when you have services or you have information that are on different machines and they may exist on-premises in your infrastructure and they might exist somewhere else. But you want to be able to give folks access to your data. You want folks to be able to either query it or create it or manipulate it and work with it in some way. HTTP is probably the most common protocol across all devices. You can think about IoT devices. You think about your smartwatch or your tablets, your phones, all these types of things. All of them have support for HTTP in some way or the other. When you think about being able to have a very widely accessible set of resources, HTTP for me is just the way to go when you want to do that type of stuff. Now, if you're talking internally and let's say this is a network that you can control, an environment that you can control, it's a little bit internal, you might want to use some different things. We spoke about gRPC for instance. You know what I mean? If it's something internal, maybe you don't really care too much about actually looking at what's on the wire. I could send things between my different services like really quickly. Or if you think about databases, for instance, most databases don't use APIs, they use sockets. If I connect to a MongoDB, I'm connecting to a socket. If I connect to SQL Server or SQL Azure, I'm connecting to a socket. They have their reasons for doing that from a security perspective and from a performance perspective. But again, when it comes to efficiently sharing information throughout a wide variety of clients, I think HTTP is usually the better way to go. When we're talking HTTP, then we're going to be talking about creating Web APIs with HTTP. >> Got it. One more question and then we'll continue moving on to our next workshop. John, from Learn TV wants to know, do you have any tips on securing REST API endpoints? >> You know what I would tell you to do? We're not going to talk too much about security. There is a little section that talks about security in the next page, I believe. But if we're going to jump the gun a little bit, if you head over to docs.Microsoft.com/asp.net, we do have like a whole bunch of docs around using things like ASP NET identity, using things like OAuth and JWT tokens. Because when you talk about security, security means a lot of different things to different people, and so it depends on what you mean by secure. It could mean, hey, do I want to secure the connection. Then we'll talk about things like HTTPS. Do I want to secure a username, an identity of a person. Then we get talking about things like, ASP.NET identity and JWT tokens and stuff like that. Are you talking about, do we want to secure the hardware that the thing is actually. Again, security means a couple of different things for folks. But I would sell you, definitely head over to our docs and we should have some pretty good guidance specifically about securing the identity or access to a very specific API that you're building. >> Excellent. Thank you for your tips. All of all of the resources for this event can be found at Aka.ms/WebAPI_ Resources right there. If you need any links to the downloads or the documentation, or even the Learn modules that we're walking through, feel free to head on over to that link and all of the information and resources are provided for you. Don't forget about the Learn challenge that we're doing as well. You complete these modules, you get points, you win challenges you get prices. It's amazing. >> I like presents. >> Yeah, who doesn't look presents? You get to walk through your Learn module, so you're growing your education as you're also getting points is a little bit gamified, so it's really fun. We just covered getting started with Web APIs. What are they? Why they're important? How they're useful? We did a bunch of comparisons. What do you do next for us Cecil, what else we're going to talk about? >> Well, what do we talk about actually building these Web APIs.? That's all I'm going to do? >> Sounds great. >> Let's head back over to my screen really quickly, and what we'll do is, we'll head over to this second part of the workshop, which is create a Web API using ASP.NET Core. Again, hopefully you-all can follow along with us and let us know too if there's any feedback you have about these modules that we're going through. I want to skip the introduction, let's just get to it. Now, these exercises, in this part, we're going to be a little bit more hands. They get it requires us to start using the.NET CLI. We're going to spend a little bit more time inside of Visual Studio code. What you'll notice here too, this access to use something called the sandbox. I'm not going to use that, but you can, if you wanted to. What I'm going to do instead is actually run the code on my machine, so you can see what it actually feels like from real developer perspective. But again, you don't have to, but that's just what I'm going to do. I'm going to move that out of the way. Let's walk through the first part, which is going to tell us how we can set up our environment. First, like I mentioned before, we're going to have to have .NET uninstalled, so make sure you have it installed. It once it's installed, you'll be able to do something like this. I'll be able to call a command and .NET New Web API Essentially what that'll do is scaffold out a new Web API project for us. I think that'd be pretty cool. Why don't we try that? I'm going to copy this command. I'm going to head over to VS code. Looks like I have stuff running. I'll stop my stuff from running. What we'll do is, I'll paste that in there. Now, I don't want this entire path. I just want the Contoso's pet path. I'm just going to do that, so .NET new Web API, Contoso pets. You see that shouldn't take too long, is going to create my product for me. It's going to set it up. >> I have a questions Cecil. >> Yes. >> Why did you delete that? Why do you only want the Contoso portion? >> Why do I delete that? Because I'm already in a folder that I want this to be in. What this command will do is, it'll create an ASP.NET Learn folder and then a source folder and then ContosoPets.Api folder. I don't need three levels deep or folders. I want it to be in the folder that I'm in right now. If you wanted it to create this level deeper folders, that's totally fine, but I just wanted to use this service level folder. This last piece, this is going to be the actual source or destination of where my code is going to live. Does that makes sense? >> Yes. Thank you very much. >> Yeah, cool. Now that we've created that we have a new Web API project, now you'll notice that, and I've already opened out on VS code, but you'll notice that we'll have a set of folders and files and pretty much shape of a new projects. Now if you've never done ASP.NET before, if you've never done C# before, some of this stuff might look new to you, but we are going to take the second to look through that as soon as I go back there. After that we're going to call .NET builds. Now, if you're new to programming, what .NET build does is it'll look at all the code that we've written so far, it'll compile it. Essentially just means that it's going to prepare it to be run, is going to package it up, is going to prepare it to rerun, and then somewhere the bottom we're going to call the .NET command to actually execute that code that we just built. We're going to create a new Web API. We're going to build the project. Again, we're going to package it up and get it ready to go, and then we're going to actually run it. Let's go ahead and check that out and see what happens. Like I mentioned before, I went ahead and I created that project. I'm going to go into it now, so it's ContosoPets.API and we'll open that in a new window really quickly. You can see here on the right side, I'm going to bump this up a little bit so folks can see what's happening here. But you should have a folder structure that looks something like this. I'll have a startup file, I'll have a program that's CS file. You'll see something in here called controllers, for instance. I'll just say yes did that pops up. Then you'll see this thing in here called a CS Proj file. Again, we'll dive into this a little bit more as we go on. But for now, how will we just run it and see what happens when we run this Web API. Now, there's two ways that we can run it. I can run it on the command line, which is what it's telling you to do. This Window's super-big, I need to zoom back out. It's telling you to run it on the command line, and the way that we'll do that is within the folder that you just created the project, I can do a .NET Run. In a second is going to build a project. It's going to start up a web server locally on my machine. Then now it's going to start hosting it on an address. If you remember, we talked about addresses a little while ago when I showed you that example of Microsoft Graph. That's what we're going to put inside of our web browser to know where this thing lives. If you look here in the window, you can see this one has an address of localhost 5001. That just means that it's running here on my machine. I'm going to pop that in here. I don't see anything. Well, that's not fun. Let's take a look and see how exactly can I see where my API lives. Now, if you take a look inside the controllers folder, you should have a single file in there called WeatherForecastsController. If we take a look at this, you'll see there's some methods in here that let us know, well, this thing is responsible for managing the requests and responses. I'm going to guess that if I do something like the address/weather forecasts, hopefully it should load my API up. Let's try that and see what happens. There you go, so now I'm seeing data. Now we're getting somewhere. If I open this and I'll zoom in to that really quickly, we can see that by default, that new Web API template creates an API or weather API. Or we could use that to look at some of this data that is returning for us, so that's pretty cool. Now, since I'm using .NET5, there's another cool thing that we get by default that really helps out when we're testing our Web APIs. That's called the swagger UI. I'm going to do name or a thing/swagger. Now, you might be wondering, hey, I thought were building Web APIs, where this UI thing come from? I haven't written any HTML or CSS to this point, so how was it that we have this thing showing to us? Well, if you're using .NET5. Again, not .NET 3.1, but.NET5 and above, by default, the Web API templates come with this thing called swash buckle and swash buckle add support for this thing called the swagger UI. Using the swagger UI, I can start making requests to my API within this browser UI. Notice I can click this operation. Notice it's gets right to the HTTP get, I get hit tryout. I can even execute it. This is actually my real API. This is the thing that we just built, but I'm executing it here inside of the browser. I didn't have to do anything other than just create a new project. If you notice, I haven't written a single line of code yet. But we already have an API that's up and running and we are ready have this UI that we could use to iterate on and test our APIs as we started go for it. I'm going to close this. Let's head back and see what else they'd wants us to do. You'll notice here in this third step here, it's wanting us to use a command called curl. Now, if you're on a Windows machine, you may or may not have this command. If you are using, for some of you folks might be using Windows Subsystem for Linux or something of that nature, you may have this, but by default you don't have this on Windows, so you might want to do something different. When it comes to testing on our APIs, we're probably going to just rely on using that swagger UI and we're not going to do too much in the command line for the rest of this workshop. Then here you scroll down to the bottom. You can see here this is the same example of that stuff that we saw earlier. Now, let's take a step forward and talk about how we can add data to our API. Because I think data is important. I think about data as the resources that our Web API allows us to interact with. Because Web APIs to me are all about resources. What's the thing that I want to start carrying on operations again? What's the thing I want to manipulate? Before we go far, let's look at a couple of examples. Let's say, Jayme has a store and we have Jayme's store of awesome stuff and maybe she has different products in her store. But if she wanted to have an API that gave you access to those things in her store. Well, she'd probably need to create a resource. She needs to model a resource around her products. So it'll be something like her web address/API/products. But now we have to think about, well, what do those products actually look like? Do we have a price and a quantity? Do they have a color or shape? Do they have size and weight? What are the properties that are going to be important for people that are calling the API to use? That's essentially where our data is going to come from. Usually, we are going to have data stored in memory. We're going to have it stored in a database somewhere on a file. Maybe even the data might be coming from another API that we're pulling in and manipulating in some way for us to return. But how do we do that, we need to figure out, well, what's the shape of the thing that we want to return? Again, let's take a look and see how we're going to do some of that stuff. The first command that it wants us to run, wants us to do this, make dir and touch products. It pretty much wants us to create a product class. Then after we create this product class, it wants us to define the shape of the product that looks something like this. As you can see, our product has an id which is of type of integer. It has a name, and it also has a price. Now, another thing I want you to notice about this product is, not only does it have a shape, but it's also using these attributes. If you're unfamiliar with attributes in C#, it's almost like adding metadata. How can I add some information, additional information about the things that are inside of my code? This attribute is saying, this particular property that's here is required, it's needed, we need to have it as we're doing stuff. Also here, notice the price. It says well, the price can either be between these two values. It could be one cent or it could be $9,999.99, it could be one or the other. But using these attributes, it helps our code enforce, what does it mean for our resource or our model to be valid? Because you can imagine, what if you had a product that had a negative price, that probably wouldn't be valid. That wouldn't work out well for us, because now our application is in invalid state. Again, we want to use validation to give us some of these types of things. What I'm going to do is, I'm going to copy this. I hit this Copy button that's on the UI, I'm going to head over to my API. I should probably stop it from running too because I don't want to do that. I'm going to hit the Add button and I'm going to add, actually, no, I'm not going to do that. I'm actually going to right-click on the folder. Notice I have this thing that says, New Class. This is where it comes in helpful when we add those extensions that I spoke about a little bit earlier. Those extensions would add some of these little menu items and options for us inside of.Net, inside of our.Net projects. I'm going to do New Class or New C# Class. Notice at the top, now we need to give it a name, I'm going to call it product, and now here you go. I have the product. It looks like it put it in the controller's folder. It actually doesn't matter what folder you put it in, but I definitely don't want it in there and now I'm just going to paste in that code that we got from the other part. There you go. You can see here that we're using this product. Since we are using C# nine, we actually have the option to use another type of class or another type of way to model our code. That's actually called records and it's something that I wanted to show you-all today. I'm going to change this user record and then I'm going to tell you why I changed it to user record, but let me change this code for you first. Now, records are something that were introduced in C# nine. So again, if you're using a version of C# that is lower than that, you won't be able to use it. Well, one of the reasons I like using records is because it's like classes, but with some additional opinions applied to it. For instance, out of the box, when you use records, you get things like the ability to do comparisons between two things without having to write it yourself. It overrides things like the hashCode and equality. It does things like it makes your items immutable by default. Which means, when we talk about immutability, we think about our code or our product not being able to change without us knowing about it, us having some control over that. Anyway, I like using records, particularly for returning API responses because I feel like it gives me a little bit more control and a little bit more flexibility over the things that I'm lecturing. What else we're going to do next? We have the product, and then coming down, I think we need to add some database stuff. Yeah, we do. In this next section, we're going to add EntityFramework. If you're unfamiliar with EntityFramework, it is one of our data accessing classes or data accessing libraries that we have in.Net and it really gives us a good programming model over querying databases, querying for records or tables or data using a very C-sharp way. Instead of me writing SQL or writing something in a very database-specific language, I could use EntityFramework, and I could use loop statements, and I could use conditionals, and I could use classes, and being able to get the information back in a way that's easier for me to use. I'm going to go ahead and add this package to our project. I'm going to copy this and back in our command line. I'm going to clear out somebody's windows that are here. I'm going to paste in that command that we saw a little while ago. Now, for me, I'm going to remove that version because I think that version might be a little bit older than the more current one. I'm just going to do dotnet add package Microsoft.EntityFramework.InMemory. Now, the InMemory part is important because that means that you can go through this exercise, use EntityFramework without actually having to set up a database. Everything that is going to happen is going to happen in memory and you're not going to have to worry about installing something and figuring out what the connection string is and doing all of that type of stuff. Again, for the sake of the demo, it makes it easier. Please do not use this in production. Remember I told you, do not use this in production. That is not what this is for, this is for testing and demos. All right, so now that that's added, you should see that inside of our csproj file and now it wants us to add two files. It wants us to add a ContosoPetsContext file, and it also wants us to add a SeedData file. Why don't we look at the context file first and see what's in here, now copy that too. Whenever we are working with EntityFramework, we use something called a DbContext, and essentially that's the type that manages our connection to the data. In that case, our connection is really just working with something in memory. But again, imagine you're using something like SQL Server or AzureSQL or MySQL or MariaDB or something like that, that Db connection, that Db context is going to be able to manage that for us. I'm going to copy that and what I will do is I'll just create that class. What was it called again? It was called ContosoPetsContext. I'm going to right-click here, Add Class. I'm going to say at ContosoPetsContext Then it's going to create that inquiry and now I'm going to just paste that in there. Let me minimize this window too, it's a little bit in the way. You can see for our DbContext, we define a constructor here for it, but we're also defining products and the products here essentially represents a table or a collection. It's where our data's going to live. As you can imagine, if we had more than just products, let's say we had products, let's say we had inventory, and shipping, and other stuff, we can have those different tables represented as properties inside of EntityFramework. Let's keep going. The next thing I think we need to do is, let's scroll down, it wants us to add this thing, added contexts, to our ConfigureServices method. Now, this ConfigureServices method lives in startup.cs, so let's see how we can do that. I'm going to do "Control P". "Control P" is one of my favorite commands. It pretty much allows us to open up the command palette inside of VS Code and then move around and do stuff. If you're on a Mac, it's "Command P", but if you're on Windows and Linux, it's "Control P". Anyway, I'm opening that up and I want to look for a startup.cs. Notice it shows to me there and we got it open. What I went ahead and did was we had to find that method call ConfigureServices, and now we have to add that code to it and I think I copied it. Actually, I'm just going to copy this part, because I think it might copy the whole thing and I don't want it to do that. Now, let's talk about what ConfigureServices does for us for a second. Let me format this, move this around. Looks like this thing is mad at me. I'm going to add these using statements and then we'll get through them as I said. >> What did you do, Cecil? >> I did something bad. Am I in trouble? What happened? >> No, I was just making sure. You just copied this over directly from the Learn module over into here? >> Yeah, this part that's highlighted, I took this highlighted part and I added it to this ConfigureServices method. Now, what does this ConfigureServices method do? Within the context of ASP.NET Core, this essentially is where we set up our services. We set up what's called dependency injection. Essentially, it allows us to make a lot of these different things that we want to use inside of our application available to other parts of our code. I like to think about dependency injection as a developer shopping list. Imagine you need to go to the store, you write down your shopping list. Your shopping list is, "These are the things that I need: I need water, I need eggs, I need quinoa and coconut water," or whatever the case is. Then you take your shopping list and that shopping list is attached to you. These are the things that I need. Now, something is going to provide you that stuff. Something is going to out and get it for you. That might be DoorDash, or Instacart, or your mom. You give them your shopping list, "Here. Could you please give me these things?" That's very much like dependency injection in your code. In our code, our classes could say, "Hey, I need a database. I need access to configuration. I need these things, could you please give them to me?" This method here configures the provider, the things that it's going to return it to you, so you could start consuming it in different parts of your code. Hopefully that makes sense to you folks, and we'll see how we navigate through that in a little bit. We registered our DbContext, and I think the next thing we need to do, it wants us to create this SeedData class. I think this job of the SeedData class, if I'm not mistaken, is to create some dummy data, some fake data that we're going to use inside of our app. I'll go ahead and copy this and we'll create that SeedData thing. I'm going to hit "Add". No. Sorry, I did it wrong again. Right-click "Add New Class", I'm going to call this SeedData, and then I'll just paste that in here. I just, again, copy-pasted the stuff that we had in the module. Now, what you'll see inside the SeedData is that there's a method on line 8, it's called Initialize. Initialize takes that DbContext that we have, it makes sure that our database is empty, in this case our in-memory database is empty, and it just adds some stuff to it. You could see here it adds two products, there's a Squeaky Bone product and then there's a Knotted Rope product. Now, we've added database support and we've added some fake data that we can start using inside of our database. Let's keep going. I think the next thing we're going to have to do is, here it is, now we have to go to the Program.cs file. Now, if you remember inside of VS Code, we had Startup.cs and Program.cs. Now, the job of Program.cs is, well, that's pretty much the entry point, that's where our application's going to start, so that's where whenever we do a.NET run, it's going to be, "Okay, well, here's our application, this is the web server. I'm going to start it up for you and you could start using and making requests to it." You can see inside of here, what it's doing is it's adding all this code that's here at the bottom to pretty much create that database seed. Essentially, as we start-up the application, it's just going to go ahead and boot up that database and also add that data to our in-memory store. I'll just copy this like I did before, I'm going to head over to Program.cs and we're going to paste this one again. I feel like I'm a glorified copy-paster today, but hopefully you'll see this is what it actually feels like when you go through these Learn modules. The exact code that I have here is the same code that we got from that Learn module. Let's see, what else do we got to do? Let's scroll down a little bit. Now, it wants us to build it and then we can move forward to the next module, so let's go ahead and do that. The next part is talking about adding a controller. Now, before we add the controller, let's talk about what a controller is. Now, controllers are like an artifact from MVC, MVC being Model-View-Controller, which ASP.NET Core has a lot of great support for, but when it comes to Web APIs, controllers are essentially one of the mechanisms that we could use to accept requests and return responses. Again, we go back to thinking about Web APIs allow us to carry out operations. We send a request to do this operation and then the server returns a response. That part that's in the middle, what is the work that's actually going to have to happen, that's essentially what happens inside of our controller. Now, we're going to create a new controller that's going to be able to handle us working with these products. You can see here, we're going to add a ProductsController. It says, just add an empty class, ProductsController. Look, I have more code to copy. Now, we're going to copy a whole bunch of code here, so let's go ahead and do that. I'm going to copy this. Hope you're all still following along with me. I'm going to go to the "Controllers" folder because this is where I want to put my controllers. You don't have to, but it's just a good idea to have things in the same space sometimes. I'm going to call this ProductsController. Now inside of here, I'll just paste in that stuff. Now, why is this thing read? Because I didn't paste it right. Let's try that again. There you go. Now we have this controller that's going to be able to receive requests and return these responses. Let's take a look through the code and see what it actually does. It's not always good to just blindly copy and paste code from the Internet inside of your project. Our controllers inherit from this thing called Controller Base. Inheriting from Controller Base gives us a lot of extra methods that we could use that just make development of APIs a little bit easier. Here in line 17, you can see that we have a constructor. Our constructor again is the thing that sets up our controller, like, how do I initialize it? How do I tell you, how do I create a new controller? Notice how we're accepting a "ContosoPetsContext", and that Pets Context is that one that we created whenever we set up that in-memory database. But how is exactly it going to receive this? We're not going to create it. ASP.NET is going to create it, and like I told you before, this is like the controller shopping-list. It says, "Hey, I need this thing," and ASP.NET is going to be the good little citizen that's going to go find out how to create a context, and provide that to the product's controller. Then the last piece we have down here in line 23 is an action method. Now, our action methods are actually responsible for doing the work that it takes to process that request, so the controller receives the request, hands it off to an action method, it processes the request, and sends it back over. You can obviously have more than one action method inside of your controller, so now the question is probably, well, how do I know which action method I'm going to pick? That goes back to those HTTP requests and response methods that we spoke about a little bit earlier. Notice this one is annotated with "HttpGet". If I make an "HttpGet" request over to the API controller for products then it's got to issue, it's going to fork out to this one that says "GetAll", or if I had one that was a Post, or a Put, or Delete, it would call that associated action method to invoke that method to carry out processing that request and generating the response back. Let's head back over [inaudible]. >> Hey, Cecil. Before we keep going, just because we're all following along on our learn modules here, I just want to make sure that we're not going too fast for anybody. People can catch up, but also I have a couple of questions for you that are relative to what you were just discussing. Do you mind if I ask you a couple of questions right now? >> Yeah, please. >> Cool. We are taking questions in the chat. I'm taking them as I'm getting them in, so apologize if this is a little bit backdated. Miguel asks, "How easy is it to add Swagger to a WebAPI built using DotNet Core 3.1 or a previous version?" >> It's not hard at all, and usually what I tell folks to do, the Swashbuckle folks have a really good set of documentation that we could use. If you head over to GitHub, this is where you can check out the Swashbuckle stuff on GitHub. It's https://github.com/domaindrivendev/Swashbuckle.aspnetcore. They have a lot of great documentation here that you can take a look through that'll show you how to get started. Usually, it starts off with just installing a Nuget package, which again would be this Swashbuckle.aspnetcore, and then it'll show you some of these additional methods that you need to have. Here you notice in the configure methods, or the Configure Services section that we spoke about a little while ago, you can see that there's an "AddSwaggerGen", and literally I honestly, I'll be real with you, I come in here and I copy and paste these samples into my code and they just work. That's one thing that you'll do, and again, as you scroll down, you'll see, you'll also have to make this call here to "UseSwagger" as well, and that's the thing that would actually generate the documents that we could use to test out our APX. Whenever we want our API again, I'll show you exactly what that document looks like, because I think it's an important thing for folks to understand exist, and also to the purpose that it serves. But to answer the question that's not hard at all. As you can see here this is pretty much it. Another thing that you might want to do is, by default, the UI doesn't have everything, or the Swagger UI doesn't have all the information about your API, and that's when we start talking about, how can we go in and start customizing different aspects of it? Maybe I want to customize the different response codes that I can recharge, or I want to customize the different media types that it supports, or I want to customize the different routes that I can send messages to. Then again the documentation is usually pretty detailed. You can start digging through that stuff and see how exactly you could do that. But no, it's not tremendously hard at all, and I believe Swashbuckle, it does support 3.1, it supports 5.0. I don't know if it supports 2.2, but you shouldn't be using 2.2 anyway because it's out support. >> Yeah, that one's a bit outdated. "What is the benefit of using Swashbuckle over NSwag?" >> What's the benefit of using Swashbuckle over NSwag? I would say they're both pretty good. I think Swashbuckle has been around a little bit longer, and so I think it's just the more popular one that a lot of folks use. I think it really boils down to a matter of taste. Like what API do you prefer to use for this or the other. But NSwag is just another option in addition to Swashbuckle that will allow you to generate a Swagger UI and open API doc, we haven't really spoken about open API, but when I go into the Swagger UI again, we'll talk about it. It's really just another option for you to do that. Another thing that I really like about the NSwag stuff as well, is that it also has support for generating clients. What is a client? I have a WebAPI, but my WebAPI exist on the server, and now I want to be able to make requests to that server, and want to be able to say, "Hey, give me the products, or add a product, or give me some information, or let me buy it." I want to do stuff. But how do I actually make those requests? Well, we make those over HTTP. There does exist a space where, hey, I don't really want to write all that HTTP code myself, and so we rely on client SDKs to do that for us. With NSwag, I believe they have a CLI tool, and some generation tools, that you could point to your Swagger doc, or your open API doc that you get generated, and it will look at it and see all the operations that are available in your API, and it'll generate those clients for you. One of the things I like about it too is that it not only does that, but you can get them generated in tons of other languages as well, Python, Node, Java, JavaScript, all kinds of stuff. >> Awesome. Thank you. >> Sure. >> Couple of other questions here before we move on. Kushal wants to know, "What is the best way to filter data in a database side or in the API code?" >> What's the best way to filter a database calls using an API? I think it depends. That's a hard question. The best way is best depending on your use case. Like, what types of options you want to have available to the callers of your API? For instance, you might think of, hey, well, my data looks a certain way. Maybe I only want to have certain records available to them, or maybe I only want to have certain properties of those records available to them. Maybe I want to have some records available to some and some not to others, and now there's a whole security thing that we have to think about. How do I create partitions or sections of that stuff? Honestly, I think it depends. I also think it depends as well on, what are you storing your data in? Are you using a SQL, are you using no SQL? Is it coming from a different place? I wish I could give you a more specific answer, but honestly it just depends. It depends on what you're doing. It depends on where your data is. It depends on what type of querying concerns that you have. It just depends. >> Okay. Sure. Well, let's go ahead and keep going and I'll save a few questions for you for later. >> Sure, no problem. Again, just as always, for folks that are in the chat, feel free to go ahead and keep asking your questions. I'll stop at any moment in time and answer them for you. Also, if I'm going too fast and there's anything you want me to hit pause and go back over, totally fine let me know because we're doing this for all of you. We want to make sure that you understand everything that we're trying to show you. >> Absolutely, and we'll also take some time at the end to make sure that we answer all of the questions that come through as well. >> Right. We added the controller. I think after we add this control, we've got to build then run it. Let's spend some time now talking about that swagger UI I've mentioned before. I've added all the code from that page. I'm going to go back into my command terminal and I can dotnet run some run it. Now, I want to show you another option that we have available as well. If you're using VSCode, which I'm assuming all of you are, on the right side in the navigation menu, there's a little thing that has a bug in it, and this is actually our debug view. Using the debug view, you might've seen a little pop up that might have said, "Hey, do you want me to add assets to make this thing debuggable?", I hit "Yes". What it would do is it would generate the tooling that's needed inside of VSCode to allow me to debug this using Visual Studio Code. What I want to show you is I'm going to put a breakpoint here. A breakpoint for those of you that may not be familiar, is just a way for me to say, I want you to run this code, but when you get here, I want you to stop. I want you to pause and then give me a chance to inspect what's actually happening. I'm going to go ahead and run this. Like I said before, it's going to go and get our source code, it's going to build it. If there was a problem, it would yell at me and be like, "No, you did something silly Cecil, so we're not going to actually make this happen". There's going to boot up that web server and we're going to start doing stuff. Our web server is up and running, I'm going to go ahead and copy that URL again. I'm going to head back over to my browser. I'm going to put in the URL that's hosted at, and I know what it's hosted at because it says here at the bottom inside of the logs. That might be a little hard for you to see, but it's down there. Then I'm going to do /swagger. Remember, I can do /swagger because, out of the box inside of.net5, the Web API templates do have the swagger support in there by default. If you recall, we did add that additional controller called the Products Controller, and notice how we now have this additional products endpoint here. That means that now we can start making requests to this product endpoint. If I click on this, now, our swagger UI will allow us to do things like we can try it out. I can hit this Execute button, and you remember I hit that break-point. The breakpoint was, "Hey, I am running this code, when you get to this point, I want you to stop". It stopped here, and what I'm expecting to happen is it's going to call our contexts. Remember we went to the supermarket and be like, "hey, we need this context, can I get this from our developer Shopping List?" It brought that in to me. Now I'm going to query that until it gives me all the products. I just want to say, in general, you probably wouldn't do this, in general you probably wouldn't say, give me my entire database, but we only have two items in here and this is fine for demos. But like someone had asked a little bit earlier, you might want to use something like link. Or if you're using Mongo or Redis or something, you might want to use the requisite querying facility that's in there to be able to return those results in a little bit more of a controlled manner. That returns, an asteroid returns, you should see our data is shown here. The squeaky bone and also the knotted rope. Now your question is probably "Cecil, how in the world did it know about this stuff? I don't understand this". We talked about a little bit before, but I want to dive into it just a tad deeper. Let's go one level deeper than we did prior. Out of the box, what the swagger UI does or what the swash buckles stuff does, is it adds something called an OpenAPI document. You notice here we'll have the name of our API, but right under it is this link that we can click on. If I click on this link, it'll open it in this little thing I got here. But it'll open up a document and inside of it, it'll tell us about different things about our API. Here I can get some basic information, like here's the title and the version. I can even add additional things in here like maybe your API has a license and a terms of use and a company, and whatever. I could start enhancing my API by adding some of these things. Also notice here it has a Path. Remember we talked about URLs. The last part of that URL being the Path to the resource, how do I get to the thing that I actually want to use? That's also described here in this JSON document. Notice we have /Products and we also have /WeatherForecasts. If I open up the products run, I have my GET request. Then you can notice here that it returns a response and then there's some tags here, they're just tagged as products. But essentially, this is a JSON document that will let us know what are all of those different operations that are inside of a web API, what are the responses that it returns and what are the types that it accepts. Now we could use it, you could use it, the swagger UI uses it to generate this UI that we have now to test our APS. Going back to that end swag thing that we spoke about a little earlier, using tools like NSwag or AutoRest, we have a lot of options. We essentially point those tools to that JSON document, to that OpenAPI Specs document. It'll look at all those operations and that's what will generate those clients for us. Our.NET Client or C# Client, Visual Basic, Python, Java, JavaScript, whatever. It could look at that in a very platform agnostic way and be like, "Well, how do I create things that could start using this API if I didn't just want to do raw HTTP?" We have R. this year. I think we have a couple more that we're going to do. I think we're going to add some additional methods also here. Let's see how we can do those. Oops, wrong way, this is the way we ought to go. I'm going to stop my debugger really quickly, I don't want to keep that running. Let's close this swagger UI, we'll close this and let's see what else it wants us to do. Here's two things that we didn't really talk about. On top of our API, our API controller, there's something in here called a route attribute, and then there's also something here called a controller attribute. I think these are important to mention. The Route attribute essentially is what helps ASP.NET Core know, how do I get to the controller that's managing the thing? Right now we have two controllers, we have a products controller, and we also have that WeatherForecastsController. But they both have GET methods. How do I know which getMethod are you actually going to invoke? This is where a routing comes into play. Routing allows us to take that shape of that URL and send it to a particular controller that's going to be responsible for managing it. Actually, let's play around with routing just a little bit so you-all can understand what I'm talking about. Inside of this products controller, notice here at the top, I have a Route attribute. This actually is using a special syntax, but this is just saying, I want you to look at the name of the controller, that's why this controller token is here. The name of my controller is products. That would mean that if I make a call to /Products, there you go. If I make an API call to /Products, it's going to invoke this controller. Just like you can imagine if I was using the WeatherForecastsController, I'd have to make a call to /WeatherForecasts and it will invoke that controller. One of the things that you can do here as well, as you could make this to be anything that you want it to be. What if I wanted to change it? What if instead of just going to products, I wanted to go to /api/products. What if I wanted to go to /api.product info. You can change that to be whatever you want. There's pros and cons of using the token versus just using a hard-coded value. One, if you have a hard-coded value, then it will pretty much be consistent. As you change the name of this controller and the name of other things that are inside of her, you don't have to worry about changes of your code actually affecting the changes in your route. Or, again, you might want to use the token, therefore I might want to put back the controller here. Now this would make a call to instead of just /Products, it will be /api/products. But if I change this to be a category controller or an inventory control or something else like that, then this last part of the path will change accordingly to be able to match that. Again, depending on what you want to do, you could do one or the other. Now that I've actually changed that, let me prove it to you and show you that it's actually working. I'm going to go ahead and hit run, and now want to expect it, let's take this off. I don't need it there. I'm going to go ahead and run this again. Now you should see when we take a look at our swagger UI, the actual path of our attention changed. It's running, let's open this up super quick. Notice now the path has changed. Notice it has gone to /api/products. Again, based on however you want to control the routes or the path for you to get to a particular resource, you have that ability using those routing attributes that come built-in. Another thing that's in here that we do want to talk about is the APIControllerAttribute. What this does, as it says here, it gives us some opinionated conventions that we could use to apply to our APIs by default without us really having to do some work with it. Things like the way that binding happens inside of ASP.NET, the way dot routing happens, the way that response codes are returned, some of these things would just be created for us by default. If you wanted to, you can really dig into the dots, they have a very long list well-documented about all the different conventions that this thing applies for you. What else is in here? We spoke about constructor injection. We spoke about that a little bit. We built and tested it and rerun it. Again, we should have seen all those products that we had returned from our API. We saw this, we saw this, we saw this. Now let's take some time and talk about the CRUD operations. Actually what I want to do is I want to head over to the slides really quick and review some things for you just so that we understand what's happening, and also to put some context around what we're doing. Like I said before, whenever we make an HTTP request, essentially what's happening is that the browser or your client is generating some stuff. That's going to go over to a server, and then that servers going to receive that request, process it, and then return response. This is what an HTTP request looks like over the wire. The top we have something called the request line. The request line has things like the path. Remember we saw the path. It has the HTTP verb which can be put post delete, and also has the version of HTTP that we're using. Then after that we have a collection of key value pairs called Headers. Headers inside a requests are very similar to like metadata. It's just additional information that's important for the server or the thing that's processing that request to know about it. For instance, you can see here we have an accept type, what's the type of information we accept? There's the content type which tells us, well, what's the type of content that's actually in this request. We have the host where we're coming from, the user-agent and tons of other stuff. Now, the last part about it that we want to talk about is the body. Now the body of the request is essentially like the information that's contained inside data request, like some additional whether it's products or resources that we want to create our whatever the cases. Now the body is an optional section. Depending on the type of HTTP verb that you're using, it may or may not be there. But essentially these are all the components that make up an HTTP requests. Now, after the request is received, again, on the server side is going to get process. Now the job of the server is to return response, and the response codes or to response for an HTTP message looks very similar to a request. The main difference is that instead of having a request line, it has a status line. The status line is important because it lets us know, well, what happens to that request we made? Was it successful, that it failed? Was there a validation error? Do we have a connection error? Do we need to do a redirect? Whatever the case, like what happens to my request? That first-line will give us that information and the version of HTTP that we're using. It'll give us the status code, whether it's 200 okay or whatever the case is. Then just like the requests as well, it has key value pairs inside of HTTP headers that we could use. It also has that optional response body. You can imagine, let's say I've made an HTTP requests to say get products, then we'll get a response but that looks something like this. Inside of the body it'll have that representation of that resource. What's the representation of those products, or those recipes, or those inventory items that we want? In this case, you can see that we're using JSON to do that. Now, we also spoke about these CRUD operations a little bit, but I wanted to show you more of this diagram to hopefully landed in a little bit harder. Again, you think about that we have those resources. I guess in our case we have products. I might want to create products. I want to read products, update, and delete. Excuse me. Based on what we want to do, we're going to have those different HTTP methods that are associated with them. Again, if I want to create something, I'm going to use a POST request. If I want to read something, I'm going to use a GET request. If I want to update something, I could use PUT or PATCH. If I want to delete something I use a DELETE request. These are really just conventions that the industries have just accepted. These are things that we generally do whenever we're creating Web APIs. I know on the server side, well, how does this server lets you know when bad things have happened. That's what those response goes, those status codes come into play. Based on whether it's a success or a failure, I could use the successful codes, which are usually like the 200 level codes, or a failure code which are usually like 400 or 500 level codes. As an example here, you can see if I did a read request with a get, I might return at 200 level status code. If I couldn't find the resource that I was looking for, then I'd say it's 404 Not Found. If I wanted to update something, I can update it and we can say, okay, well, there's no concept to return, but it was successful to return a two or four, or maybe he told me to update something that didn't exist and I couldn't find it, so I return a 404. But again, these response codes let us know what exactly happened as we were sending these messages back and forth. Now, these are the general categories of status codes that we talk about. Usually I don't see folks use that 100 to 199 range very much, but they're there, they're available to you. But you can see that we have that 200 range; 200 and 299, which represents successful status codes in HTTP. We have the 300 level codes that are usually for redirection. That's like say, hey, I hit a re-proxy. Maybe you changed your URL, or you changed the domain name of something, and it says, "Hey, I used to be here but I live here instead now, my address is different," kind of what you would do at the post office when you have your mail redirected. Then we have the 400 and 500 level errors. The differences with these are with 400 errors, they're usually the fault of the clients, the fault of the entity that's generating that request. With the 500 errors, it's usually a fault of the server. Again, who's to blame? Who are we pointing our fingers at? Is it the server's fault, or is it the client's fault? Based on that, we know hopefully, on our side we can be a little bit resilience, and how we respond to these things. Do I need to do a retry, or do I need to end it up? Maybe I need to reboot the server, or maybe I need to call someone to be like," Hey, I'm really not sure what's going on here, but I think there's a problem, could you take a look at this and fix it for us?" Again, those status codes are there for as well. One thing you could do too inside of your code, we haven't really shown it, but we probably could. One of those things that we could do with your status codes is you probably want to love them. You probably have some type of reporting system, management system, e-mail alerting system to say, "Hey, when bad things happen, who do I let know about that?" Inside your code, you can look for errors or you can capture them. Instead of giving your user a lot of weird-looking status codes in gobbledygook, and they're like, "I don't know what this is," it sounds like, "I don't know why you're showing this to me." We can just say, "Hey, bad things happened, but we're looking into it." Then on the other side, we can start making requests with right people that are going to be able to deal with that. Hopefully that makes sense. Let me know if it doesn't, and then we [inaudible] Again, we could always [inaudible] >> Hey, Cecil. I have a question. Could you elaborate further on conflict return code? >> On what resource? >> Conflict return. >> On conflict return, sure. If there's a conflict, so you can imagine. Let's say, Jayme, you have a products and your products is called, I don't know, like you're making hats or something like that. Now, I'm going to go ahead and I'm going to create a hat product too. Now one of us is going to win. Someone's hat is going to get there first. The person that gets there last, your API can look at it and say, hey, well, this is a duplicate record. Or this is something that we already have or a change was made to it, and so you don't have the most up-to-date version or information about the thing that exists, so nom setting there's a conflict here and you probably need to either refresh the information that you have or maybe change the request that you're trying to make. Again, it's like both of us are trying to go into the door at the same time. You know what I mean? Only one person's going to be able to make it, and then someone is going to have to take a step back, reestablish themselves and then they can go through the door. That's what the conflict return type is therefore. Hey, if bad things happen and we're not on the same page or that thing, again, maybe your data is old or it needs refreshed or you got a bad old cache or something like that, you can let them know and know that person, that client can refresh that information and get the most up-to-date one, and yet if they still want to make a change or still want to make an update after that, then they can go ahead and do that. >> Awesome. Thank you. >> Cool. Anymore questions? >> No. Let's go ahead and keep going. >> The next thing we want to take a look at is how we can implement these CRUD operations. Like I told you before, CRUD stands for create, read, update, delete, and we just saw those a little bit in that last slide that I just showed you. When it comes to those CRUD operations or particularly when it comes to those HTTP action verbs, we have associated attributes inside of ESPN on a coordinate we could use. You've already seen like the HTTP GET attribute, but we have attributes for pretty much all of the verbs. Again, PUT, POST, HEAD, OPTIONS, PATCH, and so on and so forth. We'll take a look and see how we can start to use some of these things. Let's take a look first at the retrieve products. Now this one is going to pull up a product by id. What's special about this one is is also going to be using a GET request, but the route is going to be a little bit different. Instead of it just being slash products is going to be slash products slash and then the id of the thing that we want to retrieve. You can see that because when you take a look at this Azure route here, notice that it has this little token, then we have two curly braces and id in the middle. Well, that id is going to be a part of the route, it's going to be a part of the path that we're going to make a request to when we want to get information back. Now, since we're using ASP.NET Core, our action method, is going to be able to receive that as a parameter, and then we can pass it into our database and we can start to return the right response. Why don't we take a look and see how we did that. I'm going to copy this and I'm going to stop that. Now let's go down a little bit. Oh, look, it even tell me where to put it. I'm going to put it right here in the middle where it says GET by Id. Again, we have a GET operation. Let's close that. We're going to use our DBcontext, which is in memory at this point to pull out that item. Now, if the item is found, it will just return it and I believe is just going to return an okay. But an okay being like a 200 level status code. If it's not found, we're going to return NotFound, which I believe is a 404 status code. Let's go ahead and run this. Actually, you know what I'm going to do? I want to try something different. What I'll do instead of just stopping and running my thing all the time, which I'm sure it might be getting a little annoying for some of you, I want to try a new command. I'm going to do.NET watch run. Now what does.NET watch run do? What it does is it'll watch my code, hence the watch, and every time my code changes, it'll run the run command, it will execute that run command. This is almost a way that I don't have to keep starting and stopping the debugger all the time because you're probably like, so how many times you got to do this? I'm going to try this out. Let's see if it works for us. I got my.NET watch run started. Oh, I have an error. What's the problem? Did I break something? What's the problem? Let's do this. I'm going to do.NET clean. What.NET clean is going to do is it's going to clean my build, so anything that it might have created before is just going to wipe it out. Now, let's try this again,.NET watch run. Is it going to work this time? Let's cross our fingers and see what happens. Please work. Great. Now it's working, fantastic. Now this is running. Notice that I have that second operation added to my API. Under products I have not just /API/Products but I have /API/Products/Id. When I open it into swag UI, notice how it now gives me the option to add an ID to the request. What it'll do is it'll just substitute id into this little token that's here. You can notice that inside of the path. If I try it out for myself, actually I don't know what the Ids of these things are. What are the Ids for this things? Let's do this. Let's look in the, I think it's inside. I have, oh, that doesn't make sense. Let's do that one. There we go. Now we have one with the Id of zero and one with an Id of one. Based on what we're doing, I should be able to pull back one of these things. Let's go ahead and run that. We're going to try it out. I'm going to put one in here and I'm going to execute it. What did I get back? Id is 0, stream price is 0. Did I do that right, what's happening here? FindAsync K. >> Hey Cecil, can you elaborate on what you're doing here [inaudible] >> What I'm doing here, so I executed this, GET by Id, I put the Id in here. Now what I'm expecting it to do is to pass that information in to my DB context and it should return a product for me. But this looks like it says type error fields to fetch. Why did it fail to fetch? I need to figure out why did it not find it. FindAsync. This is what I think I'm going to do. I'm going to change the query. Let's see if this works folks. I'm going to use link instead. I'm going to say where, I'll tell you what I'm doing in a second. I'm going to use a different querying syntax. I'm going to say where p.Id equal to the Id, and then I'm going do, set those on SingleOrDefault. Great. There we go. What did I do? Why did I change this? Why is this mad at me? This is mad because it's saying SingleOrDefault, the product does not contain definition for getawait, does it not? Let me see. Got it. SingleOrDefault. What I'm doing is I'm trying to return the Id. Now, I think what happened for some reason that method that was there before, which was FindAsync wasn't probably taking that Id and querying the right property. Now, what property should it be querying? Inside here notice we have an id property, we have a name property, we have a price property. What I decided to do was, hey, let's change the query a little bit. I'm changing the query to say, hey, I want you to look at products and I want you to look for a product where the Id is equal to this Id parameter, and this Id is coming from that requests that we accepted a little while ago. This SingleOrDefault is saying, hey, there should only be one thing in here that has an Id that matches this thing. If you find it, return it to me, or if not, is going to return the default, and the default is none. Now, another option would be if I just did single. But if I did single and it didn't find it, then I get in trouble because then it's run exception and then we'll have a whole not happy situation. We don't want that to happen. I'm going to try this now and see if this works instead. I think, waiting for file to change. If I save this, I saved it now, is going to restart because I'm doing.NET watch. I'm still getting an error code. What's the problem with this thing? I'm going to stop using.NET watch. I don't think it likes me today. I'm just going to run this the regular way. I'm going to hit this debug window, just like we've done before. We're no longer running it in the command line. Hopefully this is going to build it. Now it looks good. >> We have a suggestion. Maybe you need to re-seed the DB. >> Maybe I do need to re-seed the DB. Let's do that. I want to delete a bunch of stuff. I'm wondering why is that happening? You're right, I probably do need to re-seed the database. I'm going to delete some things from my folder. I want to look at this database again and make sure the IDs are unique, the names are unique. That makes sense. Then let's go and take a look at the products. Now, if I look at how it's defined inside of here, I believe it's defined in a previous, was it the one before? It was defined at a datastore. I think I might have to label this as an ID. I think that might be what's missing from here. Let's try that and see if that fixes it, I believe. I haven't used EntityFramework in a while, so I'm going to guess that this is what we need to do. I think I could say this is a key. Now, what does the key do? The key says, "Well, this is the primary key." So I'm going to label this as the primary key. That's fine. The database should be wiped out. I'm just thinking about this. Label it as a primary key, database should be wiped out, we should be good now, I hope. Let's cross our fingers and see if this works out. We should be good. Do you trust me Jayme? Do you believe in me? >> I have all the faith in the world in you Cecil. >> That's what I need to make this thing work. >> It's looking good. >> It's in the name where it cannot be tracked. Another instance with ID is already being tracked. Where is it? Another instance of Product type cannot be tracked because another instance with this key value of ID is already being tracked. >> You didn't delete the database, did you? >> Well, I mean, it's all in memory. There's no database to delete, is there? Where did it go? Let's see. How can I delete this database, dotnet clean? It should be empty. It should be nothing in there. The ID numbers are different. I didn't add any databases. There is nothing on disk that says otherwise. There isn't. No. Let's try this. I'm going to go where we created it in the startup. I'm going to call this ContosoPets2. Let's try this. We're going to try a bunch of stuff and see what happens. I changed the database to in-memory ContosoPets2, I added a key here because the error that I was getting was it says that I already have a thing that exists with the same name. Folks in the chat, if you think you know what the problem is, let me know. We could talk about it. I changed the database it's using. This is weird. The instance of entity type Product cannot be tracked because another instance with the same key value is already being tracked. That's weird. >> What if you leave the IDE values as they were? >> Well, they're both zero. They were zero zero when we re-added them. Let's go down. >> Yes. We can change it to one and zero. >> Yeah. See, they are both zero zero. >> I'm guessing just put in two and three, and see if it's in memory. >> Okay. Sure, let's do that. Let's do three and four. We're going to save it now, and let's try it again. That is weird. I wonder if it's happening because I'm using the records. Do you think it could be a records problem? What if I stop using records? It's running. I changed it to two and three. >> Amazing. >> I don't know where that database is, because I thought it was in memory, but we can talk about that later. This is up and running now. >> Yeah. [inaudible]. >> Let's head back to the Swagger UI. Now, I have my breakpoints in the ProductsController, so I'm expecting this to stop there. I know I only have three and four, so if I did try out one, let's step through the debugger really quickly. I should return a not found, because I don't have any products with the ID of one anymore. I'll run that and I should return a not found, that's expected. That's what it's supposed to do. If I did a three and I executed this, and I run through the debugger, it should return the product. It returns a product, I get a 200 level status code. There you go. Now, it's fixed, and it's working, and there we go. Good. We sorted through that in-memory issue. >> Everybody online, you're all so smart. You helped us figure it out. >> Yeah, I appreciate it. Thank you, because I was like, "What in the world is happening here?" Anyway, now you saw how we could do that additional route, but the important part is, again, we have that additional endpoint that we're going up/api/products, and we got the individual products by using the ID inside of the route. Great. Now, let's head back here. I think there's a little drop-down here. We were in the section that's talking about implementing CRUD operations, so let's go back there. We just did the retrieve a product and just retrieve an individual product. Let's do a add products one really quickly. What's different about this one is that it's using an HTTP POST versus an HTTP GET, and so it's going to go ahead and add an additional thing to our product. I'm going to stop the debugger. Let's add the POST action, copy-paste POST, and now we should have something that's going to give us the ability to add products to the database. I believe they're going to give us a sample, are there? No, they don't give us a sample of how to do it, but even though they don't, we have the Swagger UI. This is going to be another big benefit of using the Swagger UI, because since it knows the shape of the thing, it should be able to give us an example of what we should actually put in to have our information returned. I'm going to refresh the Swagger UI really quickly. We should have a POST operation. Notice that it gives me an example. This is what it's expecting it to look like. I should have an ID, I should give it a name, and I should also give it a price, so let's go ahead and try it out. Boom. Now, you just have to replace these values. I'm going to use a big value like 230, definitely not going to conflict with that. Let's just call it hats. We can call this whatever. Jayme, how much do the hats cost? I haven't bought a hat in a long time. Twenty dollars, I guess, is what hats cost. I don't know. Now, we're going to execute this. Let's go ahead and set their break point. I like showing you-all what happens when we set the breakpoints. I'm going to run this. Hopefully, she hit my action method. Now, because this is a POST method and because we specified the thing we want to create inside of the body of the request, ASP.NET Core is going to allow us to specify a parameter that has the shape of the thing that we want, in this case it's a Product, and we're going to be able to specify that as a parameter. Again, it's taking that HTTP request, it's taking the body, and it's turning that into an object that we could use inside of our API and generally, that's what we call model binding inside of ASP.Net Core. Another thing that we may or may not have noticed is that, if you recall, we did have these attributes on here, so the fact that it got this far inside of our controller means that our validation was successful. In the next time I run it, I'm going to show you what happens when the validation fails, but so far, our validation has been successful. I'm going to go ahead and run this. Boom. I should have a 201, so that's good. Two hundred and one means created and here's the thing that we just added to our database. Now, if I scroll back up and I head over to just the GetProducts one and I execute that, I should be able to see, I still have this break-point here, I can take that out, I should be able to see the one that we just created and notice we're returning it right here. We created it, it was added to our in-memory database and notice it has this unique ID that's in there as well. Now, what would happen if I sent in an invalid request? What would happen if I send in a request and the body wasn't what we expected it to be? I'm going to remove hats or remove this name property. I'm also going to set the price to negative 1. It's still an integer. It's a valid [inaudible] integer, but it's just not valid based on those attributes that we put on top of those methods. I'm going to hit "Execute" now. Notice it didn't hit my break-point. My break-point is still set. It didn't hit my break-point, so it didn't even really execute my action method, but it did return a 400 Bad Request. Again, it's doing this by default. Notice that it's giving me some information about things that we should correct. Notice it says, "The name field is required." It also says, "The price field must be between one cents and this amount of money that's here." Again, that's validation, that's just in there by default and it's kicking in for us. Now, the client or the thing that's looking at it can correct it and be like, "Okay. Well, maybe I'll set the price. I'm going to fix the price, and that should be fine." But even though we've fixed the price, I'm still missing that name property. I still need to put something in there, so I'm still getting that 400 level status code. Remember, 400 means it's a problem with me, not a problem with the server, so we are the ones that have to adjust a little bit and do something different. Let's change the ID. Let's call this 100. >> I don't want to rush you, but I do want to make sure that we have time for questions and we are at five minutes left, so we have a lot to cover. >> Are we, already? I'm going to run this. We're going to do it quick. Boom. Look, we're going to add the thing, it's working. Now, after we run this, if I execute this, we should have shoes that costs $20 that are inside of our product inventory, so that's great. Now Since we only have a few minutes left, you can run through some of these other examples that are in here as well. You can definitely tell you to check out the modify one, which is an important one to look at, and also the delete one. But you will notice that they all pretty much follow a very similar convention. I'm going to create an attribute. I'm going to whether put post delete depending on the HTTP method I want to use. I'm going to create a method around it, and then I'm going to carry out the work that I need to do. In this case, we're working a lot with databases. In your case, you may or may not need to work with the database, maybe you make another HTTP caller. Maybe you get information from a file on disk. Then after you've gotten your information back for your resource, then you might decide, well, what's the right status code that I need to use to actually return to the client that, well, this is really what we want to do? Was it a NoContent which is at level 200 OK? Was it a BadRequest? Was it a NotFoundRequest and so on and so forth. I guess we just skip through these things. What we're going to do now, I'm going to move to the last part and we got to test Jayme again before we leave. Jayme, I need you to come back because you need to get tested. >> Okay. >> This is the real test though. This is a serious test, so I hope you're ready. >> I am. This is also a real test on the Learn module. If you're actually following along on Learn module, please feel free to put the answers in the comments, see if you can beat me. >> All right. Let's do it. Suppose you need to update a product's name, what HTTP action verb is the best fit for this request? Is it posts, put, or delete? This is a hard one. >> This is a hard one. >> Post, put, or delete? >> I'm going to say post. >> Posts. >> Although I'm not sure. >> All right. The next one is, suppose you have successfully created a product via the post verb. The response contains a location header. What's the purpose of the location header? We didn't really talk about that, but I'll let you guess what it does. >> Okay. >> If you created something, so you created a new resource, let's think about it. You created a new resource and it says it was successfully created and you've got the location. What do you think the purpose of the location is? The first option is to identify the location of the new resource that was created, or to provide a client with the URL for the post-action, or to identify an existing product with the same name. What do you think location for a newly created resource would be? >> I want to say to provide the client with a URL for the post action, but I'm also torn between identity of the location for the new resource that was just created. >> I'm going to help you. I'm going to read a part of the question that's important. I'll help you a little bit. It says you've successfully created a product via the post verb. See, you've already run post, and the post is returning a response that has in the location. Is it the location of the new resource? Is it the URL for the post-action that you already just ran? Or is it the identity of an existing resource using the same name? >> A. >> Are you sure? >> No. >> Is that your final answer? >> But I'm going with A, yes. That's what I feel most confident. >> I hope you're not cheating and looking up stuff on another [inaudible] >> No, I'm not. >> In which scenario is it most appropriate to return an HTTP 400 status code, and how is it accomplished in ASP.NET Core? I'm going to read it again. In which scenario is it most appropriate to return a 404 status code, and how is it accomplished in ASP.NET Core? Now, first option is a product was successfully updated in the database, call the BadRequest method to generate a 404. When model validation fails because the action required parameters are missing, call BadRequest method to generate a 404. It says, when you've requested a product by ID and it doesn't exist in the underlying data store, call the NotFound method to generate a 404. This one is probably a little hard. I'm not going to help you though, but it's a little hard. >> I'm going to say NotFound. >> The last one? >> Yeah. C. >> Okay. When we take multiple-choice tests, I always tell people, make sure you look over your work. Are you sure that these are the answers that you want to submit? >> Best I can do. >> All right. We're going to do it, we're going to check it. Got them all right. That's awesome. >> Amazing. >> Congratulations, Jayme. You have passed the Let's Learn.NET Web API test,. >> It's amazing. >> You've gotten all of your answers correct, so we're going to make sure that John gives you a really cool prize. Thank you, John. Appreciate it. >> Thank you. >> After this, we'll just have the summary. Let's say in the summary, you can go through here. This will give you links to a lot of great resources that we have available for you. If you have not already, I definitely recommend you check out some of our series that we have on Channel 9. As you can see here, we have one.NET Core 101 that really walks you through some of the fundamental things you need to understand about what is.NET Core? What can I do with it? What can I build with it? What is it all about? There's ASP.NET Core 101. This is actually would've been a good course for you to go through before you came to this one because this gives you, again, some of those fundamentals that you needed to do or to understand before you start building Web API. If some of the things that you saw today were a little bit confusing still, definitely recommend you go ahead and check that one out. Jayme, I think we have a course that's coming up, don't we? >> Yeah. As a matter of fact, we have an official Web API 101 course that's actually launching next week that Cecil here has made. It's a full walkthrough videos. Only a few minutes long each so it's really easy to consume, and that'll be launching next week. If you wanted to take your Web API learning that you just learned today and branch out and explore that, we highly suggest the Web API videos that will be on aka.ms.net/videos. That's where all of our beginner videos live and exist right now. Feel free to continue exploring of your development process through here. Tons of amazing resources. There it goes. As well as if any other resources you want to get from this event, go to aka.ms/WebAPI_Resources. That will have everything you need for all of the events. Thank you. All of the stuff that we talked about here today. It has some amazing blog posts that we covered, as well as videos that you can watch to further your education. Everything you need is on there. Then we actually have another one of these events coming in March on the 26th of March, and it is for microservices. We hope to really see all of you-all back here for that as well. Please let us know what you learned from this course and what you built with Web APIs. Feel free to share all of that stuff with us on Twitter with #LetsLearndotNet, and we'd love to see what you've built over the last few weeks because of this. >> Yeah. For sure. Clearly, what Jayme said, definitely let us know what do you think about this. This is the first one of the let's learn that we've done. We're going to look for your feedback, and let us know does this beginner format, live questions, and learn modules work for you? Is there some additional things that you'd like to see? Are there some additional topics you'd love for us to cover? I'm looking in the chat, and I'm seeing some folks ask about GraphQL and HTTPClient and tons of other stuff. Again, if you want to see more stuff or if you want to see less stuff, let us know, and we could try and work it out. >> Yeah. >> Also, there were some folks that have been asking for links. If you head to the page for this session that we're having right now. If you go all the way down to the bottom, underneath the agenda, there's a section called resources. If you click on that link, you'll see a link of links. Like here, all of the various links that you might be interested in. It's things that we covered, links to docs, links to download, links to tools that you might be interested in. Links to some really cool blog posts as well that talk about building Web APIs with ASP.NET Core. Again, I know you-all want the links, and you want the code, and you want all the things, they're already here inside of that link that's inside of this page. Go ahead and check it out. >> Amazing. Thank you so much. Thank you, everybody, who joined us on the call. We really appreciate you. Thank you, Cecil. Thank you, our producers. If you have any questions or would like to get a hold of us, our Twitter handles are both lead our names. Feel free to contact us with any questions or concerns. We're happy to help you and walk you through your developer journey. Thank you so much, everyone. >> Thanks, everyone. Bye.

Channel: dotNET

Views: 52,638

Keywords:

Id: BEJI2fy8MpA

Length: 126min 10sec (7570 seconds)

Published: Fri Feb 26 2021