Understand APIs

0:00[AUDIO LOGO] Hey, everyone and welcome back to another skill in the SPAUTO course here on CBT Nuggets. OK, so what we're going to focus in on and that's skill right here is all around the concept of APIs. Now, if you don't know what an API is, do not worry. We're going to go through all of the details that we have to understand for the purposes of the SPAUTO examination.

0:37So with that said, let's dive on in and begin. Now, the first thing that I should just say straight off the bat is an API happens to be known as an application programming interface. This is what the API actually stands for. The acronym. Now that doesn't really tell us much about what an API is and real terms what does it actually do for us. Why are they so important? So here is the deal with APIs. If you happen to have some type of application, so this could be a little app over here and let's say we have another app.

1:13A completely different app. If we want to facilitate the communication between these applications so that they can ultimately talk to one another, then an API can act as a type of middleman between these two applications and affect allowing this app to push information and to this app or to if it so wishes read and consume resources that are provided or service or, should I say, provided by this application. So again, that's probably is really quite abstract.

1:46How about we look at a more general or real world analogy. Now, the classic analogy when it comes to APIs is the analogy of a restaurant. It happens to be very, very useful. So this is how I want to explain it to you. So imagine this, then you happen to be the client, OK? Remember we have this client server architecture. So imagine you as the client happen to walk into a restaurant. So here you are here and you go into your favorite restaurant, whatever it may be.

2:18Now, the restaurant in this type of analogy that is going to be the server. And like I say you over here will be the client. Now think about it like this, when you go into the restaurant you sit down and really what you're looking for from the restaurant is to be able to consume what they have to offer, i.e. What type of food they are offering, what type of drinks they are offering. Now the key distinction here is that once you are inside of that restaurant, you really don't have to deal with all of the deep details of how that restaurant is actually operating behind closed doors.

2:57So what do I mean when I say that. So really within the restaurant here, we may have a general area whereby all the customers are sitting here at all these tables here. And behind some type of door, you're going to have a kitchen where all types of madness are taking place. We're going to have chefs running up and down, checking timers, they're putting things into ovens, pulling things back out of ovens, ultimately preparing all of these foods that you're going to consume, as well as all of the other customers.

3:28Now like I say, you as a general patron within this restaurant, you actually have no real awareness of what is going on in the kitchen here. You don't know how many chefs that are, who is the head Chef, maybe it's Gordon Ramsay. We don't actually know. You don't know who is washing plates, who has been tasked with handling the desserts. Again, none of this is of any importance or concern to you. Instead, the way you interact with this restaurant is really going to be through a waiter.

4:03So a waiter is going to come to you as you are seated at your table, maybe they will give you a menu surely. And as you look through this menu, you see all of the services, so to speak, that this restaurant is offering. Now, if you want to be able to get some type of service, i.e. maybe you want to order some pasta, then again, how do you actually get that pasta? You just send that request to the waiter and the waiter will go back to the back room where the kitchen is, ultimately inform the kitchen of what new order has came in.

4:40And behind the scenes, all of this magic is going to happen. That you don't actually see or have to be concerned with, but ultimately, will produce that lovely pasta that you want to eat and again they will give it to the waiter and the waiter will deliver that pasta directly onto your table whereby you can therefore consume it. So really what I am trying to highlight here is that all the back-end operations, all of that is completely hidden from you. It is being totally abstracted.

5:11There's not part of the process at all from your perspective as the client. The only thing you are really dealing with is this waiter who is going to be the restaurant's API. This is who the restaurant elects to present their services to the public. And that is the only person that we as the consumers of this restaurant that is the only one we actually interface with. We interface and interact with the waiter alone. We're not talking to the chefs. We're not talking to the dishwashers.

5:42And in fact, if the kitchen happens to be pretty bogged down, let's imagine that there's a lot of chaos going on within this kitchen right here and let's say we are waiting an hour for pasta, we could actually send another request to the API, to the waiter, asking the waiter for an update of when our food can be expected. And the waiter can run back to the kitchen and say, hey, everyone. Can I get an update on this pasta order? We've been waiting quite a while. In which case, the waiter can therefore relay that information back to us and say, hey, it will be five more minutes.

6:16Now, this might seem a little bit strange, but that's a really kind of how software actually works. We have code in the background, which has been developed by developers. This would be like the kitchen, OK? So we've got all these complex codes but as the user of that code, i.e. the client here who is making the order, we don't actually need to care about all of that complexity. Instead, when we want to utilize the services that this code provides, the way we interact or interface with that code base is via the waiter, i.e.

6:53the API. Now, when some type of software happens to introduce an API, you're going to find that they're going to provide some type of documentation. And this is why API documentation as you will eventually see is so so important because the documentation is going to tell us exactly how to interact with the API, which ultimately allows to consume the services of that software in an easy and simplified manner. So really by presenting an API to the end user, it's going to open up a whole world of possibilities for people and other applications as well to enjoy our services and code base.

7:35So as a quick example, if I happen to pull up my web browser and I'm just going to search for Dropbox API Explorer. Again, you can choose many different APIs. Let me just zoom in here a little bit. I happen to find that the Dropbox API happens to be very well documented. So check that. So if we want to happen to programmatically interact with Dropbox, check this down the site here. We can see all of these different options. If I go to say, for example, templates, add for user, what I can do here is I can say Show Code and I can view it as a what is called a model request, which is a command line utility to make HTTP requests.

8:18Or if I wish, I could have an example of some Python code which, again, shows me some code as to how to actually programmatically retrieve that particular piece of information. Now right now this type of code may be pretty confusing. It may be pretty intimidating. But what we're going to see here is actually going to make much more sense by the end of the skill. We're going to see things such as headers, which we will talk about. We can see here that what is called the resource or the path, which we are targeting.

8:48And in fact, what we're seeing here actually is a REST API and this is something that-- let me just change the color of that. That's not quite so good. A REST API and we'll get to discuss what a REST API as very, very shortly. Now, really what I just want to highlight here is that the purpose of the API is to simplify the interaction between different code bases, i.e. different applications, or you as a human user wanting to consume particular services from a particular application via the API is the way we're going to be able to talk to that software in an organized and simplified way.

9:27And this is exactly how your phone actually operates. If you happen to check and look at some of the widgets on your phone say, for example, maybe you have some type of Fitbit app, which is actually pulling data programmatically from other sources of information. Pulling information from your Apple phone, from some type of weather application, which actually tracks the weather in say, for example, Wyoming or say, for example, in Glasgow, Scotland. The way your phone, developed by Apple, can consume the services of maybe some type of Fitbit application or weather application is because these APIs are ultimately facilitating the connection and the communication between these in different code bases.

10:13So this really is why APIs are so, so powerful and are a big, big part of the modern network automation landscape. Now, we just mentioned something called a REST API. Now the REST API is an absolutely massive mammoth in the world of APIs. It's so, so popular. And the thing is this is something we absolutely have to know about. But the question is, what exactly is a REST API? Well the good news that is what we're going to be talking about in the very next Nugget.

10:43So I hope this has been informative for you and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Hey, everyone, and welcome back. Now, in the previous Nugget we had just taken a look around the basics behind APIs. And during that Nugget, we happened to mention a very particular style of API. This is known as a REST API. Now, I did say the REST APIs are super-duper popular.

0:32We really have to know about them. So with that said, let's dig in and find out what they are all about. Now, the thing to note straight off the bat is that REST APIs are named for a particular reason. In fact, it is actually a Representational State Transfer API. Now, what this is actually in reference to is in reference to the architecture of this API. Now, the crucial thing, or rather one of the crucial things, should I say, about the architecture of a REST API is that REST APIs are stateless.

1:07That's just something we really want to be remembering. Ultimately, what we're seeing here is that the server is not going to keep track of what has been sent prior to the current request. So what do I mean when I say this? Well, imagine we have some type of server here, and over here we have some type of client machine, and the client is sending requests to the server. So let's just maybe say the client sends the request, asking how many users do you have in your database?

1:39And the server sends back a response. OK, no problem at all. Let's now say then that client now says, can you add a user to your database? And the server responds and says, yep, no problem at all, everything is A-OK. And the server indeed does update the user database. Now, the crucial thing to note here is that this particular operation here as its own isolated operation. It has no reliance on the information that was passed before it.

2:12Each transaction stands on its own here. So this is really quite useful because the server doesn't need to know anything other than what is being sent right now in that particular request. So we have a clear delineation and separation between the client and the server. So this ultimately leads to a very flexible architecture. Simply put, so long as the client is following the rules of the server-- the type of rules that you would find and the documentation-- then the client can successfully make those APIs requests to the server and the server is going to understand those requests.

2:53Now, there are some components with respect to making these requests. Now, when we happen to make REST API requests over HTTP, we're going to see things such as headers. And these headers can do very useful things, such as specifying the actual structure of the data that we want to use. So we can use the header to say to the server, hey, I want to talk to you using JSON. So when I send a particular payload to update, say, for example, how many users should be in your database, I am going to send this via JSON so that you can, therefore, interpret my payload and understand the request.

3:35Similarly, the client can say to the server, "How many servers-- or rather how many users do you have in a database on the server and send that information back to me in the form of JSON or maybe say, for example, XML." The point here is, though, is that we can specify this information in our headers. Now, another important component when working with REST APIs is something called the verbs that we're going to use.

4:06These verbs are ultimately going to delineate what we actually want to achieve. We can maybe say we want to retrieve information from a server, i.e. just pull me the information that you have stored and return it to me. Or maybe we'd like to change some type of information on the server, or maybe we want to delete some information on the server, or maybe we want to add some new information to the server. We can ultimately do this via the use of particular verbs, which we'll get to see very, very shortly.

4:41And these types of verbs are going to also be used in conjunction with the specification of a particular resource. Now, when we're talking about resources, what we're ultimately talking about are particular paths. Now these paths really point to the particular pieces of information we actually want to either modify or retrieve or delete, whatever it may be that we are specifying using our particular verbs. So an example of this may be, let's say we have some type of network interface.

5:11So this can be a router. Let's call it R1. And also, let's say we have some type of API, which we can use to present the actual configurations and state of this device to our user. So let's say we have some type of REST API. And let's just maybe say, for example, the IP address of this device is 192.168.1.1. So what an actual user could do here, some type of administrator, is that the user could send a request to the REST API specifying a particular verb to, let's maybe say, get information.

5:50So we're not trying to modify anything, we just want to retrieve the information. And we can send that over HTTP-- let's say HTTP-- just like we would any web browser. And we could maybe put in the IP address of the device, 192.168.1.1. And then let's maybe say we were looking for ISIS information because we're running a service provider router here. We can say /ISIS. Now, there's nothing magical about this particular keyword.

6:21This would all be defined within the service itself. So really within our documentation, we would actually let people know that, hey, if you want to get ISIS information, then you specify the target device IP address, followed by ISIS. This is completely arbitrary. It can be programmed in any which way. You just want to present that information to the end user, however which way you have programmed the interface. Now, let's say we want to get even more specific and we wanted to get information relating to our level 2 ISIS routers.

6:54We could then say /level2 or something like that. Now, the point here is that this particular path, this a HTTP request-- all of this here is how we actually target the particular resource, this path here. So by changing the actual path but actually pulling different information from a device-- if we just do /ISIS, we get general ISIS information. If we become even more specific and say we want ISIS information but also just level 2 routers within ISIS, we can specify that too.

7:31Similarly, what the user could do is maybe say they want CDP neighbor information. We could say /cdp. And we could access that information just like we could a show command, so to speak. But we could access this data in a programmatic way, i.e. give me CDP neighbor information, but return it to me in the form of JSON so that I can manipulate this data programmatically. Now we can also, as we will learn, specify a body within our request. But if we actually want to supply data ourselves to the server so I'm not just requesting data from the server, let's say we wanted to make some type of configuration change, then within our request, we could actually specify a body.

8:16And again, this is something we'll get to see much more often and regularly as we progress throughout this course. So really the key points to take here around REST is that this is going to be a stateless architecture, which is going to allow us to act very flexibly. However, as we will see later on within this course, this can present certain problems when dealing with network devices. But again, we'll get to that information in due time. We can control the type of information we want to retrieve or manipulate using particular verbs.

8:50We can target the exact piece of data we want, i.e. the exact piece of network configuration we want to modify or the exact piece of networking data we want to retrieve, such as like a show run or a show IP interface brief. We can do that by specifying a particular resource within our URL. If we want to have our information and JSON or XML, we can specify particular headers to do such a thing. And if we want to modify information so that we're not just reading the data, i.e.

9:23if we want to make configuration changes, we can specify a particular body, which we send to the actual REST server itself. So really, what we have here is a lot of moving parts with respect to the REST API. And the reality is, this can be a little bit confusing the first time you see it. So what I'm suggesting we do is that we look at this information in a little bit more detail, more specifically, how we can utilize these verbs and interpret how a server responds to these verbs via particular status codes.

9:57That way, we can have confidence that the server has accepted our request as we have expected. So how about we look at these details and get a little bit more hands-on? And well, that's what we're doing in the very next Nugget. So I hope this has it been informative for you, and I'd like to thank you for viewing.

0:01[CBT NUGGETS JINGLE] Hey, everyone and welcome back. Now in the previous Nugget, we had talked about some of the basics around the REST API, that is the Representational State Transfer API. And one of the things we happen to mention was that REST APIs are going to utilize particular verbs.

0:32Now why do we need verbs? Well, verbs are ultimately going to implement something called CRUD. Now CRUD as yet another acronym, is going to basically represent the type of operations that we can implement against a REST API server. So check this out. What C stands for is create and then the next one would be read and then the next one is going to be update and then finally, we're going to have the DELETE operation.

1:09So here is how this is going to shake out. When we want to create a new resource, i.e. something that does not exist on the server, we're going to have a particular method we can use and that is called a POST request. This is the type of verb that we're going to be using, or methods if you prefer. This is the type we will use when we want to create something afresh. So let's imagine we had a networking device, again, let's call this R1, and we wanted to create a brand new loopback interface on this device.

1:46So let's just imagine this device had the address 8.8.8.8. What we would do is we would send a request, so let's say HTTP and let's just put in the address of the server 8.8.8.8. And let's just for whatever reason see that the actual resource we would target would be /loopback and the name of the loopback. So loopback-0. Again, this is me just making this part up on the fly. This would be defined programmatically by the server itself and explained via the documentation.

2:20So this is the resource we want to target. And what has is it we want to do right here? But we want to create a loopback that does not exist. So if we want to create something, we're going to use a POST request. We would actually send a POST request. And this really is how things are going to shake out. Let's move on to the next one. Let's say we wanted to perform a Read operation. Remember, CRUD, read the second. Well, the way we could do this is to utilize the particular verb, or method if you prefer.

2:55And the particular verb is going to be a GET request. So Similarly, to follow our example, let's just have R1 here, once again, with the IP address of 8.8.8.8. If we happen to send a request with a particular resource specified, let's say HTTP, and we target the address. And let's say we wanted to read all of the interface information relating to IP addresses. So we maybe just say ip-interfaces.

3:26Again, I'm just making this resource up completely on the fly. So we've got the resource. We know what we want to target. We want to read that information. So we're going to send a get requests. So we send a GET request to this particular resource, and then the server is going to return back the IP address information programmatically, again and something like, say JSON format or XML. So again, we move on once more. What was the next one? And on CRUD operations, it's going to be U, which is the Update operation.

3:59So this is going to map to what is called a PUT request. Now a PUT request is actually quite an interesting request. It can be used to actually create a resource from a fresh, just like a POST request. But it can also be used to update an already existing resource. There are some cases whereby you would just use a PUT request to act like a POST request, so to speak. And there are some occasions when you would rather specify a POST request out right. We'll get to see more of these details later on in this course, when we're dealing with things such as the rest RESTCONF protocol.

4:36For now, just understand that the PUT request can create a resource from afresh. So I may as well put create here and brackets, but it's primary function is to update an already existing resource. So again, to go back to our example, we have R1 and that's a terrible drone. Let's try that entirely again. R1 here was 8.8.8.8. Let's imagine that we had some type of access control list on our device already configured. We want to modify or update that ACL.

5:08Well, what we would do is we would target the particular resource. So let's say HTTP again, with all the 8s. And specifying the resource again. Totally making up this up. Let's just say /ACL. And let's say this is Access Control List 10, so ACL 10. We can modify ACL 10 by pointing to this resource and by specifying a PUT request. Now again, I should point out here because we are making a request such as a PUT request, it's not enough to just say, hey, we want to send a request to ACL 10.

5:44That doesn't actually tell the server what changes should be applied. Let's say we now wanted to deny ICMP any. This is where we would specify the body that we actually talked about. So we could actually construct some type of request say, for example, formatted and JSON to denote the actual change we want to make. So we send the PUT request along with the body to this particular resource to programmatically change the ACL configuration right here to update that configuration more specifically.

6:17And then finally, we would have the last in our CRUD operations, the D, which is delete. This one is the easiest one to remember to actually map because the actual CRUD operation DELETE actually maps to the DELETE verb or the DELETE method. So this is a 1 to 1 mapping. It's the same world used. So again, finally, we have R1 with its IP address. Let's say we had loopback 0 configured on the interface. We now want to remove that interface.

6:48We no longer need it. What do we do? We target the resource. So I'll just pop this in and add then this path. Let's just say loopback 0. And the way we would delete this resource is by sending a DELETE request, i.e the delete methods along to this particular resource, which would ultimately remove loopback 0 on the device. So this really is how our verbs are implemented. Try to remember that CRUD operation and how the different methods actually apply to the different parts of the CRUD operation.

7:21Now when we happen to be sending these requests, these POST requests or GET requests or DELETE requests, the server itself is going to give us some type of feedback, feedback letting us know how a request actually went. So here is the deal. When we send a request, we're going to receive back from the server some type of status code. So think about it like here, we could have our network administrator right here sending some HTTP requests to the router, which has a REST API exposed.

7:55Let's just maybe say we send some type of DELETE request to delete our loopback. And whether the request actually happens to succeed, the server can send that response back in the form of a three digit code letting us know, hey, the DELETE operation you requested was successful that has been applied. Or conversely, what the server may do is send back a different three digit code ultimately saying that the request that you sent was denied for whatever reason.

8:29So why exactly are these three digit code? Now the very first digit in this code is going to give you the general information about the response itself. The first digit denotes a type of gripping, so to speak. So let's imagine you got a code of 100. It is the first that you hear that is going to tell you the general information. So if the three digit code starts with a 1, this is just known as an informational response.

9:00Meaning that the server is just returning some genetic information. However, if the response begins with a 2, this means that the operation that you sent was successfully applied. So if we happen to send some type of DELETE request to remove a resource from a server and the server returns to us, let's maybe say a 200 code, well, the 2 at the beginning tells us that our request was successful and the other digits gave us just a little bit more specific information.

9:32A 200 code is just a generic response saying that everything was OK. It was successful. Whereas if we happen to send a PUT request to update the resource, we would get a 2 or 1 response. Again, the 2 tells us straight away that our request was successful. The 201 specifically tells us that something was successfully newly created. So you would not see a 201 when you happen to send a DELETE response because you're not newly creating something.

10:04So you might be able to see here that this information really can be very, very valuable. If we happen to get a code that begins with a 3, this ultimately points to a server redirection. So the request has been redirected elsewhere. The next code if you happen to see beginning with a 4, this means that we have some type of client error. Pretty much that means that the request you sent, you have made an error on your end. So maybe you happen to send your request with bad credentials, so your authentication was incorrect.

10:40Then the server might let you know that by sending you a 401. The 4 tells you straight away that it was your request that was the problem and the 401 specifically is relating to authentication errors. Whereas maybe say you have perhaps seen on a web page a page 404, that means that your request was incorrect. The 4 tells you that. And more specifically, the 404 status code tells us that a request was not found.

11:10And then lastly, we have status codes beginning with 5. That's the notice that we have some type of server error. So if you happen to receive a response from the server with maybe say a 500 status code, the 5 straightaway lets you know that the server is at fault. And a 500 status code, specifically denotes an internal server error. So really there happens to be a whole bunch of these types of status codes. Let me actually show you.

11:42If you happen to Google HTTP status codes, maybe go to Wikipedia. If we just Zoom in a little bit. Let's scroll on down. We can actually see some of the information here. We can see the informational response, successful responses, redirection, client error, and server error. And if we scroll on down, we can actually see more detailed information about them. So a 100 status code would denote a continue. A 201 is a resource created as I just said. A 204 is a no content response.

12:14If we scroll on, then we can see some client errors such as a 401 unauthorized, 402 requires an actual payment to be made, 403 is forbidden. And again, we can keep scrolling through all of these different types of status codes. We can see we have an absolute ton. So the point I'm trying to highlight here is that the server can actually give you quite a lot of detailed information back whether your request is successful or whether if your request is not successful. You can kind get a good idea of how you could actually troubleshoot that problem.

12:45Like I said, if you happen to receive a 401, you know that you should go and check your credentials are correct. So this is one of the very big benefits of using REST APIs. So check this out. How about we go and make a little request, then. So what I'm going to do is I'm going to download some particular software known as Postman. Now this is a platform for testing APIs, for building APIs, so on and so forth. It is very, very useful. If we click on this here. Let me zoom in a little bit. If we download the desktop app, just click on Windows, Mac, or Linux.

13:19They happen to be using a Mac device right now. So I'll click this right here. I'm using the Apple chip, so I'll just click this here and a download should begin. That should be really quite similar, whether you happen to be using Windows or Linux natively. OK. So the download has completed. Let's click this. We're going to extract us. OK. So now you can either create a free account or sign in if you already have one. Or alternatively, you can sign in later. So let's click Skip and go to the app. So check this out right here. Via this particular application, we can send particular requests to our APIs.

13:54So what I'm going to do here is I'm going to go to my favorite public REST API that is good for testing. Let me show you where that is. If you happen to search for a GO REST API, let's click this top link right here, we can see here we have the server, which gives us some fake data that we can use to test. So check this out right here. Here are some particular resources that we can target, say, for example here if you want to target particular users of this fake database or particular posts or particular comments or to to-dos, whatever it may be.

14:27And we can see here we have some examples. This is a type of example we would look at when reading API documentation. We would just say, hey, we want to create a new user. How would we do so? We would send a POST request. Oh, sorry about that. POST request to this particular resource. Similarly if we wanted to details, we would just send a GET request to this particular resource. And this case here, 17 be an example of an ID for a user. And similarly if we wanted to delete the user, we would specify this particular resource, again, specifying the ID of that user.

15:04So let's actually try to see some particular user. So we'll actually use this resource here. So let's just copy this and we'll go to Postman. So if I just hit the plus sign right here, what I'm going to do is to enter in the URL I want to target. So I'll just paste this in right here. And notice here, this is where we can actually specify the verb or the method that we want to use. So I can see a GET, a POST, a PUT. We actually have more methods such as PATCH request, but we don't have to worry about that quite just yet.

15:35And we can see here things like DELETE request. So right now we will send a GET request to this particular resource. Now within our headers, if you recall, we can specify particular pieces of information. We can say, for example, specify and accept header. That's the type of data we want to accept. And the value I want to specify here is I want to get my data in JSON form. So I will say applicationhttps://www.cbtnuggets.com/json. Similarly, if I have to specify particular authorization to access this resource, I will go into the Authorization tab and then specify maybe an API key or basic authentication, but we will specify a username and password to log in to the server.

16:20And this case here with GO REST, we have no authentication or, no authorization should I say. It's just a free resource, so we don't actually have to worry about this. Similarly, if we wanted to send some type of POST request or PUT request to update the resource, we would want to do so by specifying a particular body. So again, we can specify the body here. We could put it in raw data, so on and so forth. But again, we'll keep things pretty simple. Right now we're just sending a basic GET request. So we don't actually have to send a body along with that because we're just retrieving information.

16:54So what I will do here is we can see we have a header, we have an authorization set to no. We have a resource and we have the actual verb we're using, a GET request. So if I just send right here, we're going to send off the response, notice here, we can actually see the status code 200 OK. That means that the request was indeed accepted as successful by the server and we have the actual response. So we can actually see here we have this data listing all of the users within the database and that's a specified in JSON format.

17:28You see this right here, this is all JSON. Let me actually just pull this up a little bit. And this is the type of data that we can work with programmatically. So that we can use particular programming languages such as the Python programming language. And we'll get to see how we can do this in a little skill. So if I go back and look at the documentation here, and I happen to change the resource the time targeting to target the comments resource. So if we look at the data we have right here, we see information relating to the users. If we change the actual resource here and paste this into comments and send off a new request, we can see we have the 200 status code.

18:07Now within the actual output, we can actually see the posts that were sent. So notice we're seeing the ID of the user, the name of the user, the user's email as well as what they have actually posted. So this as the comment that user happened to leave that looks like to be some type of Latin text, which is common for demonstration purposes. But the point remains the same. We send a request, we target the resource. So you can imagine if we happen to change that resource to maybe be, let's imagine 8.8.8.8/bgp-neighbors again, I'm totally making this up, we could get BGP neighbor information.

18:47Whereas if we happened to specify OSPF neighbors, we would actually get OSPF information. And if we wanted to delete a particular OSPF neighbor, we could send DELETE request and then specify maybe say, the router ID of that neighbor we want to delete. This is a type of procedure we would walk through when using REST APIs. So that's all for a REST API status codes on verbs. The next thing we have to talk about is the remote procedure of call.

19:19And that is what we're going to be talking about in the very next Nugget. So I hope it should been informative for you and I'd like to thank you for viewing.

0:12Hey, guys. And welcome back. So now what I want to do is I want to turn your attention to a different style of API. Previously we had talked about the REST syle of API. But now what we want to do is to look at what is called the RPC style of API. This is the Remote Procedure Call. Now, there are some striking similarities with respect to RPC and REST. RPC is going to also utilize this client server model.

0:46Now as the name suggests, RPC, the primary function of the RPC is so that you as a client can use the RPC to call processes on a remote system. That would be the target server you're actually connecting with. Now, the real interesting point here with respect to RPC is that when you make that remote procedure call, it's really like running the process on a remote system as if it was executed locally.

1:18Now RPC is similar to REST in the respect that we can get information and modify information on remote systems. But the big difference here, really, is that with RPC, everything is going to be much more lightweight. So we're going to get a performance benefit when utilizing RPC versus REST. Now as we progress throughout this course we will eventually come to a very big protocol that is known as NETCONF, which is the network Configuration Protocol.

1:48And NETCONF, as you're going to see, actually utilizes these RPC, these remote procedure calls. And we use the RPCs to get information from our devices, such as state data. That could be interface counters, statistics, or it can be, say, for example, BGP peering information. Or if we want to get configuration data, such as our BGP route reflector configuration, we can do so using these RPC. Similarly, if we want to modify the configuration, say, for example, we want to change an access control list, then as we can see here, we use the RPC with NETCONF to be able to make that modification as needed.

2:32Now, as we progress throughout this course, we're going to actually learn about something called gRPC. This is Google's take on the remote procedure call. And similar to using regular RPC, although at an even greater scale, this is going to provide us really great performance benefits. But, again, we'll get to look at this in a lot more detail a little bit later on within this course when we talk about gRPC, as well as something called gNMI, which actually utilizes gRPC.

3:05But, really, for the purposes of the examination, we want to have an awareness of RPC as an alternative to REST. We have a lot of similarities in that we have our client server model. We can make changes on remote systems as if we were executing that procedure locally on our local system. And like I say, the real driving factor when using RPCs is that lightweight overhead, the performance boost you get with that. But the reality is in the modern world, the REST API is much more common and becoming much more popular.

3:41So, really, that is all for our introduction into RPC. So for now, I hope this has been informative for you. And I'd like to thank you for viewing.

0:12Hey, guys. And welcome back. So now what I want to do is to turn your attention to what are called synchronous APIs, as well as asynchronous APIs. So the question actually is, what are the differences between synchronous and asynchronous APIs? When would you want to use one versus the other? So let's start by talking about what asynchronous API actually is. Now, the first thing to note here is that synchronous APIs are blocking, and they're not going to return until a process either finishes, or if that process happens to error out.

0:48Whereas when we are talking about an asynchronous API, this is one which is non-blocking. So, really, what this means is that when we happen to utilize an asynchronous API, we can wait while doing other things. Which means that asynchronous APIs are really, really good for handling lots and lots of requests. Because if we implemented synchronous APIs, we would otherwise be bogged down due to all of the waiting between those requests.

1:19So let me give you a little analogy to help you understand what is actually going on here. So the analogy I often use here with respect to being able to describe asynchronous connections is the concept of a chess grandmaster. So you may not be aware of this, but in chess, grandmasters sometimes as a kind of demonstration of their prowess, what they will do is they will play multiple different people at the same time. So what we can see here is my really good drawing of what are going to be tables.

1:51So you can imagine a grandmaster going on to, say, table 1, and then round 2, table 2, table 3, 4, 5, and 6. So each table has a different opponent, and the grandmaster has to play every single opponent. Now imagine this as the synchronous connection. This is how this would actually play out. What would happen as the chess grandmaster would engage table 1 and the first player.

2:21So we would make a move as the grandmaster, and then we would wait for the player one to make a response. However, the game is not finished. So because of this, we ultimately have this type of blocking condition. So the grandmaster can actually leave the table until the game is complete. So you can imagine that with all of the waiting and all of the deliberation of player 1 trying to decide what to do against this highly skilled grandmaster, let's maybe say this whole game takes 30 minutes.

2:53Now, once the inevitable happens, the grandmaster defeats the novice player, the grandmaster then moves on to table two. Because the game has complete, the grandmaster is now freed up to go elsewhere. So the same thing repeats. We go to table two, we make our move, table-- or rather, player two makes their move. And, once again, we are engaged within a game, so we cannot move on until that game is complete. Same, again, that this game maybe takes 20 minutes before the inevitable happens once again.

3:24The grandmaster wins, and then is freed up to move on. So you can imagine this continually happening. This maybe takes 30 minutes, 20. Let's maybe say 30, again, for here, 20 here, whatever it may be, so on and so forth. So this whole process of playing all of the six players, handling all of these requests may end up taking multiple hours, four or five hours. Now, this really isn't a very efficient use of the grandmaster's time because the grandmaster are very, very skilled.

3:55As soon as they get their time to make a move, they know exactly what they're going to do. They're not having to wait and think, they just want to move on and complete the game. So imagine this as an asynchronous operation. Let me show you how that's what actually differ. So now we're going to be async. So here's how this game is going to happen. The grandmaster is going to play their first move. And then as soon as the grandmaster makes their move, they are freed up to do as they wish. So the grandmaster immediately goes to the second table and plays the next move.

4:29Meanwhile, player one here is still deliberating and trying to strategize about what they should do, but it doesn't actually matter. The grandmaster is not locked in, the grandmaster can just keep moving around. So, again, after playing table two, the grandmaster runs over to table 3, and then table 4. Meanwhile player one is beginning to make their move, as as player two. But the grandmaster is racing on row. If went to table 5 and table 6, and suddenly they're back at table 1 again.

5:01And now player one has made their move, so the grandmaster can make another move and then jump to the next table. Because, again, asynchronous is non-blocking, so the grandmaster is free to move on and do other things as opposed to waiting. So the reality is the grandmaster can just keep running around all of these tables, playing the move that they're going to play. And as opposed to waiting for every game to complete, and eventually we get this type of concurrency going on.

5:33And, ultimately, the grandmaster could potentially defeat all six opponents in around 30 minutes, as opposed to four or five hours. So that really is the big difference when we don't have to wait on an operation, returning until it either finishes or errors out. As soon as we get free time, we can go on and do other things. Now, when it comes to synchronous APIs, a very classic example to implement a synchronous API would be something like, say, a local news app.

6:04Basically this application is going to wait for you to give at some information, such as you provide your location, and then application is going to return news relating to that particular area. So this idea of the application waiting for us to give it some information before completing the operation, this is very typical of synchronous APIs. Whereas if you happen to be dealing with, let's maybe say, like a real time data such as data that you're going to stream in to the system that is not requiring you to continually update it on your end, you can just make the request initially, and just let it process.

6:46And as things are changing, the asynchronous API can just pull in that information continually, and feed it through. So this is really good, like I say, if you're dealing with real time data. So if you had some type of application that was continually monitoring traffic and telling you about particular traffic congestion, and it was just constantly updating based on the data coming in, this will be a good use case for an asynchronous API. Similarly, if you wanted to monitor particular financial information, such as trading information relating to the stock exchange which is forever constantly fluctuating, having that data just stream in and be handled by an asynchronous API is really very useful.

7:33Now, another very good use case of an asynchronous connection is relating to network interfaces where we actually have a lot of waiting. The waiting actually relates to the input, output. As we are sending the request over the wire, say, for example, we are making a remote connection from somewhere in the United States to maybe, say, somewhere in the United Kingdom. The actual distance that we've got to travel, all the different connections on that route, that is actually implementing or, rather, introducing some type of waiting.

8:08So when we have that waiting, we don't want to be in a blocking state, we want our API to be able to move on and do other things whilst we are waiting on that connection completing. As opposed to being held hostage to whatever network latency we have. Now, I will say, synchronous APIs, as it stands right now, are far more common and simpler to implement. Whereas asynchronous APIs, they are gradually becoming more and more popular.

8:39And, really, the big advantage here is with respect to performance. So being able to understand the differences between synchronous connections and asynchronous connections, and when you would use one versus the other, those really are the details that we want to understand to satisfy the criteria set out within the ASP Auto Examination. So that is all for our introduction into synchronous and asynchronous connections. I hope this has been informative for you, and I'd like to thank you for viewing.