Adding API GET Calls - C# on Linux Episode 16

In this episode, we're going to be adding the other get command for API project. Now this video is part of a series dedicated to developing C# applications on Linux. If you haven't already check it out, this is episode number 16 of the series. There is a playlist for this entire series. So I encourage you to check that out. And if you want to help the channel and help uh sponsor more free content like this, you can go to I am Tim Corey. com and check out all the training I have to offer there. All that training helps fund more free content so that everyone can have a great education C#, not just those who can afford it. Let's jump over to our um our Linux machine and here we are in VS Code and we've got our database pulled up here. This is actually where we left off in the last episode and we're going to work on adding another get command. We have our get all, we did that a couple of videos ago, but we're going to add our get one command. And to do this, I'm just going to copy and paste. And I'm going to say um / uh ID int like so in curly braces and then I'm going to pass in int ID. And this is going to be the specific ticket you're looking for. And so we're going to say instead of get all, we're going to have the get. So that's the um the get stored procedure and if you remember, the parameters is looking for an ID which is an int. So we can come back over here, we can minimize that and we needed not just pass in empty object here. We need to pass in that integer. So I'm going to pass in ID. Now if you remember, let's pull this back up actually. Uh our parameters, notice the ID is lower case. Now the other ones, they're not um the other ones actually doesn't have parameters. This one does. Notice they're all uppercase. Um, whereas this one is lowercase. And this works out nicely for me because I'm passing in just one value. And so that ID, um, I can just pass in just this ID parameter as also the value. So what happens is it's technically doing this. Okay? But you don't have to specify. Now, if I want to pass in a uppercase, I would have to specify this is the name of the parameter, this is the value. But since I am, um, passing the same name I can just pass in just ID. All right. So let's try this now and make sure it works. Let's save it first and let's come down here and run. Wait for it to launch. Okay, so we have our API service is running. We can open this up and let's go to Swagger. And now we have our get. Let's try it out. We're going to pass in ID of two and hit execute. When we do, we get just the second ticket back. So you can see here, let's zoom in a bit. We have an error code or I'm sorry, return code of 200 means success. Um, and we have one value being returned. That is actually returning an array. We don't want to return an array. So let's modify that. Um, so we can, um, what we can do is return the first value. Now remember that the load SQL async returns back a list of ticket model. we can say, um, first. Or we can say first default. Um, first default, that way is going to return back to default value, which is null, if it's not found. So, let's, um, try this again. We're going to hit save on this. I didn't use the hot reload. I just restarted it. So, now it should return just one, not an array of elements, which makes more sense. You're expecting one back if you ask for an ID. Let's run this again. And again, we can go to Swagger. And we could actually make that launch automatically, but I haven't done that. We can, though. Okay. So, we're going to pass in two, and hit execute, we get a 200 back, and we get just that object back, one object. Now, let's do this again and pass in four. And hit execute. We have a response body of null. Okay? Now, we could say, you know what? Um, that's not expected behavior, because we're saying it's a 200 code, we should probably say 404 instead. Um, we can do that, where we can, um, return a

uh, a not found exception, um, if we want to, something like that. But, um, otherwise, we can just do this right here, um, first, and that's going to throw an error. Um, now, I closed the browser out. Um, but honestly, first, because that will throw an exception if it can't find it. So, let's run this again. Wait for it to launch. This is why hot reload's awesome if you don't forget to close, if you don't close down the site site, because it's faster to go back to where you were. All right. Back here. Always test out a working parameter first, so let's pass in, uh, one, and we get back one. Let's pass in now a non-working one, execute, and if we hit continue on our site, it should give us a 500 error, which isn't what we want. But that does give us an error at least saying, "Hey, an error's occurred while processing your tickets. " I don't love that. I do want to process this as if it's a failure circumstance. So let's do this. Let's change this return. So we're going to cut it out for a minute and we're going to say Let's say if tickets dot count is equal zero. Because it should always return back a list. So that list can have zero items in it. else Actually, you know what? We don't even need an else. Let's just return tickets dot first. Okay? So that takes care of our of our check. We're going to do this instead. We're going to return different thing here inside of the if statement instead of returning first, because if we check to make sure that there's not zero, then what we can Actually, you know what? I still do like the idea of saying um So here here's my thought process. I'm doing this on the fly. I'm not actually pre-doing this right like that. I'm trying to think through um the edge cases. You should always be thinking edge cases, not just the happy path. Because you know, I might not be able to test the edge cases as easily. But imagine for a minute that tickets wasn't a valid list for whatever reason. Well, it's going to throw an exception, and I don't love that. Um I don't love the idea of returning a um you know, a or adding another variable. I think I'm going to do that, though. So, var outputs equals tickets. firstordefault like so. And then if uh ticket or I'm sorry, output um is null then we're going to do something here. Otherwise, we're going to return outputs. Okay. So, that makes me feel a little better because it allows me to um say, "Hey, you know what? Wait a minute. Let's go ahead and um put this in a variable and then check for null. " Because if anything happens where for whatever reason the list is null or whatever else, um hopefully the error will be in the list and um it's going to be caught and say null. Uh I'm not sure it's going to catch a whole lot actual errors because if this list is null, then this won't work. Um so, and actually I could do this. Ha ha. Um that will solve another problem. If the ticket list comes back as null, um I might do a null check for it first and say, "Hey, if it's null, just put null into the output variable. " Which then again gets caught in this filter. Okay. So, that I think takes care of the next problem in my list. So, let's make a few changes here. Um what we're going to do, let's close that out, is we're going to specify the type of response. Right now, we're saying return output, which is a ticket model object. But, we don't have a way of saying, "Yeah, give me a ticket model object or give me a um a return of 404. " So, we had changed this. So, what we're going to do

is we're going to say um after async, we're going to specify that the return type. So, that is going to be a task of type results. And let's close out these angle brackets because there's been a lot of them. Um, we're going to say okay. And the okay's going to return a ticket model. And then after the okay, we're also going to have the not found. — [snorts] — Okay? And then we still need to have one and I still have the wrong number of brackets. There we go. Um, this is where the colored brackets really help. So, so this is the pink goes with the pink. And then we have the blue ends with the blue. And then we have our ticket model has the yellow ones. So, this is going to this is the return type. It's going to return a task uh because async. And so, the actual return type is this. It's going to be results either okay or not found. So, now instead of saying output, we're going to say the typed results. If I spell it right. Typed results of type uh oops. Not dot okay. And then we have pass in the parameter of output. And then here, we can say uh typed results. dot um And this is the not found not found. We can just say not found. That way we know we get a 404 message when we try to look up something that's missing. So, let's come back to our run and we're going to run this again. Wait for it to load. There we go. So, our API service, let's go there. We go to swagger. And then on our ID again, we're going to run one, try it out. Run one that we know works. So, there's three. And that worked. We got 200. Cool. Still works. Um always make sure the things that you expect to work still do. Now we hit four and we run it and we get a uh 200. Interesting. Um that's not what we're expecting here. We're expecting to see a 404 because we're Oh, right there then there. Nope, that's the possible responses. That's the actual server response is 200. That's incorrect. Um let's find out why. Um because we're returning a if output is null then we should be getting the um the typed res- Ah. We need to return that, not just say it. So, uh let's make sure our hot reload's working. Um and now let's execute this again. And I don't think my hot reload worked. But, that's okay. I can just stop it and start it again. Sometimes you have uh return types or other things that are modifying how the program actually works, it doesn't um like to do a hot reload. Okay, Swagger. And ticket ID, let's pass in our working one. So, again, that works, 200. Let's do our non-working one. And we get a 404. There we go, error response status is 404, means we could not find that record. Okay. So, this is careful, there's possible responses. These are the potential, oops, I don't want to do that, stop it. Um, these are potential responses down here. This is the actual server response right here, so therefore we can see that code is 404. But now the system knows these are our two options for what you might get back, which is helpful because you can know, oh, I need to test for a 404 because that's a potential return value. Okay. So, that means now we can close this all out. Um, our code is complete for all of the gets. So, um, let's do this, let's put this on a separate line because it's how long this thing is. Um, so there we go. Let's save that. Um, I will include the source code down below in the description again, um, if you want this, but all we did here was we add the one endpoint and then learn that we have to do this, um, this results type response

um, actually this response, because the fact that we want to return a 404 when we don't find a ticket when we look it up, okay? So, that's it for this video. In the next video we'll look at, um, creating new data or inserting data into our database using, um, another endpoint, this one with the post uh, All right. Thanks for watching and as always, I am Tim Corey. —