Understand APIs

0:00[AUDIO LOGO]

0:12Hey, everyone and welcome back to another skill in the SPAUTO

0:17course here on CBT Nuggets.

0:18OK, so what we're going to focus in on

0:21and that's skill right here is all around the concept of APIs.

0:26Now, if you don't know what an API is, do not worry.

0:29We're going to go through all of the details

0:32that we have to understand for the purposes of the SPAUTO

0:35examination.

0:37So with that said, let's dive on in and begin.

0:40Now, the first thing that I should just say straight

0:43off the bat is an API happens to be known as an application

0:48programming interface.

0:50This is what the API actually stands for.

0:53The acronym.

0:54Now that doesn't really tell us much about what an API is

0:57and real terms what does it actually do for us.

1:00Why are they so important?

1:02So here is the deal with APIs.

1:05If you happen to have some type of application,

1:08so this could be a little app over here

1:10and let's say we have another app.

1:13A completely different app.

1:15If we want to facilitate the communication

1:18between these applications so that they can ultimately

1:21talk to one another, then an API can

1:24act as a type of middleman between these two applications

1:28and affect allowing this app to push information

1:32and to this app or to if it so wishes read and consume

1:36resources that are provided or service or, should I say,

1:40provided by this application.

1:42So again, that's probably is really quite abstract.

1:46How about we look at a more general or real world analogy.

1:50Now, the classic analogy when it comes to APIs

1:53is the analogy of a restaurant.

1:55It happens to be very, very useful.

1:57So this is how I want to explain it to you.

2:00So imagine this, then you happen to be the client, OK?

2:04Remember we have this client server architecture.

2:08So imagine you as the client happen

2:10to walk into a restaurant.

2:13So here you are here and you go into your favorite restaurant,

2:17whatever it may be.

2:18Now, the restaurant in this type of analogy

2:21that is going to be the server.

2:23And like I say you over here will be the client.

2:26Now think about it like this, when

2:29you go into the restaurant you sit down and really what

2:33you're looking for from the restaurant is

2:35to be able to consume what they have to offer, i.e.

2:39What type of food they are offering, what type of drinks

2:42they are offering.

2:43Now the key distinction here is that once you are inside

2:47of that restaurant, you really don't

2:49have to deal with all of the deep details of how

2:53that restaurant is actually operating behind closed doors.

2:57So what do I mean when I say that.

2:58So really within the restaurant here, we

3:02may have a general area whereby all the customers are sitting

3:05here at all these tables here.

3:07And behind some type of door, you're

3:09going to have a kitchen where all types of madness

3:12are taking place.

3:14We're going to have chefs running up and down,

3:17checking timers, they're putting things into ovens,

3:20pulling things back out of ovens,

3:21ultimately preparing all of these foods

3:24that you're going to consume, as well

3:26as all of the other customers.

3:28Now like I say, you as a general patron within this restaurant,

3:34you actually have no real awareness

3:37of what is going on in the kitchen here.

3:39You don't know how many chefs that

3:41are, who is the head Chef, maybe it's Gordon Ramsay.

3:44We don't actually know.

3:46You don't know who is washing plates, who has been tasked

3:49with handling the desserts.

3:51Again, none of this is of any importance or concern to you.

3:55Instead, the way you interact with this restaurant

4:00is really going to be through a waiter.

4:03So a waiter is going to come to you as you

4:06are seated at your table, maybe they

4:08will give you a menu surely.

4:10And as you look through this menu,

4:12you see all of the services, so to speak,

4:15that this restaurant is offering.

4:17Now, if you want to be able to get some type of service, i.e.

4:21maybe you want to order some pasta, then again, how

4:25do you actually get that pasta?

4:27You just send that request to the waiter and the waiter

4:31will go back to the back room where the kitchen is,

4:35ultimately inform the kitchen of what new order has came in.

4:40And behind the scenes, all of this magic is going to happen.

4:44That you don't actually see or have to be concerned with,

4:47but ultimately, will produce that lovely pasta

4:51that you want to eat and again they will give it

4:54to the waiter and the waiter will deliver that pasta

4:59directly onto your table whereby you can therefore consume it.

5:02So really what I am trying to highlight here

5:05is that all the back-end operations, all of that

5:08is completely hidden from you.

5:09It is being totally abstracted.

5:11There's not part of the process at all

5:13from your perspective as the client.

5:17The only thing you are really dealing with

5:19is this waiter who is going to be the restaurant's API.

5:23This is who the restaurant elects to present

5:27their services to the public.

5:29And that is the only person that we

5:31as the consumers of this restaurant that

5:34is the only one we actually interface with.

5:36We interface and interact with the waiter alone.

5:39We're not talking to the chefs.

5:40We're not talking to the dishwashers.

5:42And in fact, if the kitchen happens

5:44to be pretty bogged down, let's imagine that there's

5:47a lot of chaos going on within this kitchen right here

5:50and let's say we are waiting an hour for pasta,

5:54we could actually send another request to the API,

5:58to the waiter, asking the waiter for an update of when

6:01our food can be expected.

6:03And the waiter can run back to the kitchen

6:05and say, hey, everyone.

6:06Can I get an update on this pasta order?

6:08We've been waiting quite a while.

6:10In which case, the waiter can therefore

6:12relay that information back to us

6:14and say, hey, it will be five more minutes.

6:16Now, this might seem a little bit strange,

6:18but that's a really kind of how software actually works.

6:22We have code in the background, which has

6:25been developed by developers.

6:27This would be like the kitchen, OK?

6:29So we've got all these complex codes

6:32but as the user of that code, i.e.

6:36the client here who is making the order,

6:38we don't actually need to care about all of that complexity.

6:41Instead, when we want to utilize the services

6:44that this code provides, the way we interact or interface

6:49with that code base is via the waiter, i.e.

6:53the API.

6:54Now, when some type of software happens to introduce an API,

6:58you're going to find that they're

7:00going to provide some type of documentation.

7:03And this is why API documentation

7:05as you will eventually see is so so important

7:08because the documentation is going

7:10to tell us exactly how to interact with the API, which

7:15ultimately allows to consume the services of that software

7:19in an easy and simplified manner.

7:22So really by presenting an API to the end user,

7:26it's going to open up a whole world of possibilities

7:30for people and other applications

7:32as well to enjoy our services and code base.

7:35So as a quick example, if I happen

7:38to pull up my web browser and I'm just

7:41going to search for Dropbox API Explorer.

7:44Again, you can choose many different APIs.

7:47Let me just zoom in here a little bit.

7:48I happen to find that the Dropbox API happens

7:52to be very well documented.

7:53So check that.

7:54So if we want to happen to programmatically interact

7:58with Dropbox, check this down the site here.

8:00We can see all of these different options.

8:03If I go to say, for example, templates,

8:06add for user, what I can do here is I can say Show Code

8:11and I can view it as a what is called a model request, which

8:14is a command line utility to make HTTP requests.

8:18Or if I wish, I could have an example of some Python code

8:23which, again, shows me some code as to how to actually

8:26programmatically retrieve that particular piece

8:29of information.

8:30Now right now this type of code may be pretty confusing.

8:33It may be pretty intimidating.

8:35But what we're going to see here is actually

8:37going to make much more sense by the end of the skill.

8:40We're going to see things such as headers,

8:42which we will talk about.

8:43We can see here that what is called

8:45the resource or the path, which we are targeting.

8:48And in fact, what we're seeing here actually is a REST API

8:53and this is something that--

8:55let me just change the color of that.

8:57That's not quite so good.

8:58A REST API and we'll get to discuss what a REST API

9:02as very, very shortly.

9:04Now, really what I just want to highlight

9:06here is that the purpose of the API

9:08is to simplify the interaction between different code bases,

9:13i.e. different applications, or you as a human user wanting

9:17to consume particular services from a particular application

9:21via the API is the way we're going

9:23to be able to talk to that software in an organized

9:26and simplified way.

9:27And this is exactly how your phone actually operates.

9:31If you happen to check and look at some

9:33of the widgets on your phone say, for example,

9:36maybe you have some type of Fitbit app, which is actually

9:39pulling data programmatically from other sources

9:42of information.

9:43Pulling information from your Apple phone,

9:46from some type of weather application, which actually

9:49tracks the weather in say, for example, Wyoming

9:52or say, for example, in Glasgow, Scotland.

9:55The way your phone, developed by Apple,

9:58can consume the services of maybe some type

10:01of Fitbit application or weather application

10:05is because these APIs are ultimately

10:07facilitating the connection and the communication between these

10:11in different code bases.

10:13So this really is why APIs are so, so powerful

10:16and are a big, big part of the modern network automation

10:20landscape.

10:21Now, we just mentioned something called a REST API.

10:26Now the REST API is an absolutely massive mammoth

10:29in the world of APIs.

10:31It's so, so popular.

10:32And the thing is this is something we absolutely

10:34have to know about.

10:35But the question is, what exactly is a REST API?

10:38Well the good news that is what we're

10:40going to be talking about in the very next Nugget.

10:43So I hope this has been informative for you

10:45and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:12Hey, everyone, and welcome back.

0:14Now, in the previous Nugget we had just

0:16taken a look around the basics behind APIs.

0:20And during that Nugget, we happened

0:22to mention a very particular style of API.

0:25This is known as a REST API.

0:28Now, I did say the REST APIs are super-duper popular.

0:32We really have to know about them.

0:34So with that said, let's dig in and find out

0:36what they are all about.

0:38Now, the thing to note straight off the bat

0:40is that REST APIs are named for a particular reason.

0:43In fact, it is actually a Representational State Transfer

0:48API.

0:50Now, what this is actually in reference

0:52to is in reference to the architecture of this API.

0:56Now, the crucial thing, or rather one

0:58of the crucial things, should I say,

1:00about the architecture of a REST API

1:04is that REST APIs are stateless.

1:07That's just something we really want to be remembering.

1:10Ultimately, what we're seeing here

1:11is that the server is not going to keep

1:15track of what has been sent prior to the current request.

1:20So what do I mean when I say this?

1:21Well, imagine we have some type of server here,

1:25and over here we have some type of client machine,

1:28and the client is sending requests to the server.

1:32So let's just maybe say the client sends

1:34the request, asking how many users do you

1:38have in your database?

1:39And the server sends back a response.

1:42OK, no problem at all.

1:44Let's now say then that client now says,

1:48can you add a user to your database?

1:50And the server responds and says,

1:52yep, no problem at all, everything is A-OK.

1:56And the server indeed does update the user database.

2:00Now, the crucial thing to note here

2:02is that this particular operation here as its own

2:06isolated operation.

2:08It has no reliance on the information

2:11that was passed before it.

2:12Each transaction stands on its own here.

2:16So this is really quite useful because the server doesn't

2:20need to know anything other than what is being sent right

2:23now in that particular request.

2:25So we have a clear delineation and separation

2:28between the client and the server.

2:31So this ultimately leads to a very flexible architecture.

2:35Simply put, so long as the client

2:38is following the rules of the server--

2:41the type of rules that you would find and the documentation--

2:44then the client can successfully make those APIs requests

2:48to the server and the server is going

2:51to understand those requests.

2:53Now, there are some components with respect

2:56to making these requests.

2:58Now, when we happen to make REST API requests over HTTP,

3:03we're going to see things such as headers.

3:05And these headers can do very useful things,

3:08such as specifying the actual structure of the data

3:12that we want to use.

3:13So we can use the header to say to the server, hey,

3:16I want to talk to you using JSON.

3:19So when I send a particular payload to update, say,

3:23for example, how many users should be in your database,

3:27I am going to send this via JSON so that you can, therefore,

3:31interpret my payload and understand the request.

3:35Similarly, the client can say to the server, "How many servers--

3:39or rather how many users do you have

3:41in a database on the server and send that information back

3:45to me in the form of JSON or maybe say, for example, XML."

3:50The point here is, though, is that we

3:52can specify this information in our headers.

3:57Now, another important component when working with REST APIs

4:02is something called the verbs that we're going to use.

4:06These verbs are ultimately going to delineate what we actually

4:11want to achieve.

4:12We can maybe say we want to retrieve information

4:15from a server, i.e.

4:16just pull me the information that you have stored

4:20and return it to me.

4:21Or maybe we'd like to change some type of information

4:26on the server, or maybe we want to delete some information

4:30on the server, or maybe we want to add some new information

4:34to the server.

4:35We can ultimately do this via the use

4:37of particular verbs, which we'll get to see very, very shortly.

4:41And these types of verbs are going

4:43to also be used in conjunction with the specification

4:47of a particular resource.

4:49Now, when we're talking about resources,

4:52what we're ultimately talking about are particular paths.

4:55Now these paths really point to the particular pieces

4:58of information we actually want to either modify or retrieve

5:02or delete, whatever it may be that we are specifying

5:05using our particular verbs.

5:07So an example of this may be, let's say

5:09we have some type of network interface.

5:11So this can be a router.

5:13Let's call it R1.

5:14And also, let's say we have some type of API, which

5:19we can use to present the actual configurations and state

5:24of this device to our user.

5:26So let's say we have some type of REST API.

5:29And let's just maybe say, for example,

5:32the IP address of this device is 192.168.1.1.

5:37So what an actual user could do here,

5:39some type of administrator, is that the user

5:42could send a request to the REST API specifying

5:47a particular verb to, let's maybe say, get information.

5:50So we're not trying to modify anything,

5:52we just want to retrieve the information.

5:54And we can send that over HTTP-- let's say HTTP--

5:58just like we would any web browser.

6:00And we could maybe put in the IP address

6:02of the device, 192.168.1.1.

6:07And then let's maybe say we were looking for ISIS information

6:12because we're running a service provider router here.

6:15We can say /ISIS.

6:18Now, there's nothing magical about this particular keyword.

6:21This would all be defined within the service itself.

6:24So really within our documentation,

6:26we would actually let people know

6:28that, hey, if you want to get ISIS information,

6:32then you specify the target device IP address,

6:35followed by ISIS.

6:36This is completely arbitrary.

6:38It can be programmed in any which way.

6:40You just want to present that information to the end user,

6:43however which way you have programmed the interface.

6:46Now, let's say we want to get even more specific

6:50and we wanted to get information relating

6:51to our level 2 ISIS routers.

6:54We could then say /level2 or something like that.

6:58Now, the point here is that this particular path, this a HTTP

7:03request--

7:04all of this here is how we actually

7:06target the particular resource, this path here.

7:10So by changing the actual path but actually pulling different

7:14information from a device-- if we just do /ISIS,

7:18we get general ISIS information.

7:21If we become even more specific and say

7:24we want ISIS information but also

7:26just level 2 routers within ISIS, we can specify that too.

7:31Similarly, what the user could do is maybe

7:34say they want CDP neighbor information.

7:37We could say /cdp.

7:39And we could access that information just

7:41like we could a show command, so to speak.

7:44But we could access this data in a programmatic way, i.e.

7:47give me CDP neighbor information,

7:49but return it to me in the form of JSON

7:52so that I can manipulate this data programmatically.

7:54Now we can also, as we will learn,

7:57specify a body within our request.

8:01But if we actually want to supply data ourselves

8:04to the server so I'm not just requesting data

8:07from the server, let's say we wanted

8:09to make some type of configuration change,

8:11then within our request, we could actually specify a body.

8:16And again, this is something we'll

8:18get to see much more often and regularly as we progress

8:22throughout this course.

8:24So really the key points to take here around REST

8:27is that this is going to be a stateless architecture, which

8:31is going to allow us to act very flexibly.

8:34However, as we will see later on within this course,

8:37this can present certain problems

8:39when dealing with network devices.

8:41But again, we'll get to that information in due time.

8:44We can control the type of information

8:47we want to retrieve or manipulate

8:49using particular verbs.

8:50We can target the exact piece of data we want, i.e.

8:54the exact piece of network configuration we want to modify

8:57or the exact piece of networking data we want to retrieve,

9:01such as like a show run or a show IP interface brief.

9:05We can do that by specifying a particular resource

9:08within our URL.

9:09If we want to have our information and JSON or XML,

9:15we can specify particular headers to do such a thing.

9:18And if we want to modify information so that we're not

9:21just reading the data, i.e.

9:23if we want to make configuration changes,

9:26we can specify a particular body,

9:28which we send to the actual REST server itself.

9:32So really, what we have here is a lot of moving parts

9:36with respect to the REST API.

9:38And the reality is, this can be a little bit confusing

9:41the first time you see it.

9:42So what I'm suggesting we do is that we

9:44look at this information in a little bit more detail,

9:48more specifically, how we can utilize these verbs

9:51and interpret how a server responds

9:54to these verbs via particular status codes.

9:57That way, we can have confidence that the server

10:00has accepted our request as we have expected.

10:03So how about we look at these details

10:05and get a little bit more hands-on?

10:07And well, that's what we're doing in the very next Nugget.

10:10So I hope this has it been informative for you,

10:12and I'd like to thank you for viewing.

0:01[CBT NUGGETS JINGLE]

0:12Hey, everyone and welcome back.

0:14Now in the previous Nugget, we had

0:15talked about some of the basics around the REST

0:19API, that is the Representational State Transfer

0:22API.

0:23And one of the things we happen to mention

0:26was that REST APIs are going to utilize particular verbs.

0:32Now why do we need verbs?

0:35Well, verbs are ultimately going to implement

0:38something called CRUD.

0:40Now CRUD as yet another acronym, is

0:43going to basically represent the type of operations

0:47that we can implement against a REST API server.

0:51So check this out.

0:53What C stands for is create and then the next one would be read

0:59and then the next one is going to be update and then finally,

1:05we're going to have the DELETE operation.

1:09So here is how this is going to shake out.

1:12When we want to create a new resource, i.e.

1:16something that does not exist on the server,

1:19we're going to have a particular method we can use

1:22and that is called a POST request.

1:25This is the type of verb that we're going to be using,

1:29or methods if you prefer.

1:31This is the type we will use when we want

1:33to create something afresh.

1:35So let's imagine we had a networking device, again,

1:39let's call this R1, and we wanted

1:42to create a brand new loopback interface on this device.

1:46So let's just imagine this device had the address 8.8.8.8.

1:50What we would do is we would send a request,

1:54so let's say HTTP and let's just put

1:56in the address of the server 8.8.8.8.

1:59And let's just for whatever reason see that the actual

2:03resource we would target would be /loopback and the name

2:08of the loopback.

2:09So loopback-0.

2:11Again, this is me just making this part up on the fly.

2:14This would be defined programmatically

2:17by the server itself and explained

2:19via the documentation.

2:20So this is the resource we want to target.

2:24And what has is it we want to do right here?

2:26But we want to create a loopback that does not exist.

2:29So if we want to create something,

2:32we're going to use a POST request.

2:34We would actually send a POST request.

2:37And this really is how things are going to shake out.

2:40Let's move on to the next one.

2:41Let's say we wanted to perform a Read operation.

2:45Remember, CRUD, read the second.

2:49Well, the way we could do this is

2:52to utilize the particular verb, or method if you prefer.

2:55And the particular verb is going to be a GET request.

3:00So Similarly, to follow our example,

3:02let's just have R1 here, once again,

3:04with the IP address of 8.8.8.8.

3:07If we happen to send a request with a particular resource

3:12specified, let's say HTTP, and we target the address.

3:16And let's say we wanted to read all

3:19of the interface information relating to IP addresses.

3:23So we maybe just say ip-interfaces.

3:26Again, I'm just making this resource up completely

3:29on the fly.

3:30So we've got the resource.

3:31We know what we want to target.

3:33We want to read that information.

3:34So we're going to send a get requests.

3:37So we send a GET request to this particular resource,

3:40and then the server is going to return back

3:43the IP address information programmatically, again

3:47and something like, say JSON format or XML.

3:50So again, we move on once more.

3:52What was the next one?

3:53And on CRUD operations, it's going

3:55to be U, which is the Update operation.

3:59So this is going to map to what is called a PUT request.

4:03Now a PUT request is actually quite an interesting request.

4:07It can be used to actually create a resource from a fresh,

4:11just like a POST request.

4:13But it can also be used to update

4:14an already existing resource.

4:17There are some cases whereby you would just

4:20use a PUT request to act like a POST request, so to speak.

4:24And there are some occasions when you would rather specify

4:27a POST request out right.

4:28We'll get to see more of these details

4:31later on in this course, when we're

4:32dealing with things such as the rest RESTCONF protocol.

4:36For now, just understand that the PUT request can

4:38create a resource from afresh.

4:40So I may as well put create here and brackets,

4:43but it's primary function is to update

4:45an already existing resource.

4:47So again, to go back to our example, we have R1

4:50and that's a terrible drone.

4:52Let's try that entirely again.

4:54R1 here was 8.8.8.8.

4:58Let's imagine that we had some type of access control list

5:02on our device already configured.

5:04We want to modify or update that ACL.

5:08Well, what we would do is we would

5:10target the particular resource.

5:11So let's say HTTP again, with all the 8s.

5:15And specifying the resource again.

5:17Totally making up this up.

5:19Let's just say /ACL.

5:21And let's say this is Access Control List 10, so ACL 10.

5:25We can modify ACL 10 by pointing to this resource

5:29and by specifying a PUT request.

5:33Now again, I should point out here

5:34because we are making a request such as a PUT request,

5:38it's not enough to just say, hey,

5:40we want to send a request to ACL 10.

5:44That doesn't actually tell the server

5:45what changes should be applied.

5:47Let's say we now wanted to deny ICMP any.

5:52This is where we would specify the body that we actually

5:55talked about.

5:56So we could actually construct some type of request

5:59say, for example, formatted and JSON

6:02to denote the actual change we want to make.

6:05So we send the PUT request along with the body

6:08to this particular resource to programmatically

6:11change the ACL configuration right here

6:14to update that configuration more specifically.

6:17And then finally, we would have the last

6:20in our CRUD operations, the D, which is delete.

6:23This one is the easiest one to remember to actually map

6:26because the actual CRUD operation DELETE actually maps

6:29to the DELETE verb or the DELETE method.

6:33So this is a 1 to 1 mapping.

6:34It's the same world used.

6:36So again, finally, we have R1 with its IP address.

6:41Let's say we had loopback 0 configured on the interface.

6:46We now want to remove that interface.

6:48We no longer need it.

6:49What do we do?

6:50We target the resource.

6:52So I'll just pop this in and add then this path.

6:55Let's just say loopback 0.

6:57And the way we would delete this resource

6:59is by sending a DELETE request, i.e the delete methods along

7:04to this particular resource, which would ultimately remove

7:08loopback 0 on the device.

7:10So this really is how our verbs are implemented.

7:14Try to remember that CRUD operation

7:16and how the different methods actually

7:18apply to the different parts of the CRUD operation.

7:21Now when we happen to be sending these requests,

7:25these POST requests or GET requests

7:27or DELETE requests, the server itself is going to give us

7:30some type of feedback, feedback letting us

7:34know how a request actually went.

7:36So here is the deal.

7:38When we send a request, we're going

7:40to receive back from the server some type of status code.

7:44So think about it like here, we could have our network

7:47administrator right here sending some HTTP

7:50requests to the router, which has a REST API exposed.

7:55Let's just maybe say we send some type of DELETE request

7:59to delete our loopback.

8:01And whether the request actually happens to succeed,

8:05the server can send that response back

8:08in the form of a three digit code

8:11letting us know, hey, the DELETE operation you requested

8:15was successful that has been applied.

8:18Or conversely, what the server may do

8:20is send back a different three digit code ultimately saying

8:25that the request that you sent was denied for whatever reason.

8:29So why exactly are these three digit code?

8:32Now the very first digit in this code

8:34is going to give you the general information

8:38about the response itself.

8:39The first digit denotes a type of gripping, so to speak.

8:43So let's imagine you got a code of 100.

8:48It is the first that you hear that is going to tell you

8:50the general information.

8:52So if the three digit code starts with a 1,

8:56this is just known as an informational response.

9:00Meaning that the server is just returning

9:01some genetic information.

9:03However, if the response begins with a 2,

9:07this means that the operation that you sent

9:10was successfully applied.

9:12So if we happen to send some type of DELETE request

9:16to remove a resource from a server and the server returns

9:20to us, let's maybe say a 200 code,

9:23well, the 2 at the beginning tells us

9:24that our request was successful and the other digits

9:28gave us just a little bit more specific information.

9:32A 200 code is just a generic response

9:35saying that everything was OK.

9:36It was successful.

9:38Whereas if we happen to send a PUT

9:40request to update the resource, we would get a 2 or 1 response.

9:46Again, the 2 tells us straight away

9:48that our request was successful.

9:50The 201 specifically tells us that something was successfully

9:55newly created.

9:57So you would not see a 201 when you

9:59happen to send a DELETE response because you're not newly

10:03creating something.

10:04So you might be able to see here that this information really

10:07can be very, very valuable.

10:09If we happen to get a code that begins with a 3,

10:13this ultimately points to a server redirection.

10:16So the request has been redirected elsewhere.

10:19The next code if you happen to see beginning with a 4,

10:23this means that we have some type of client error.

10:26Pretty much that means that the request you sent,

10:29you have made an error on your end.

10:32So maybe you happen to send your request with bad credentials,

10:36so your authentication was incorrect.

10:40Then the server might let you know that by sending you a 401.

10:44The 4 tells you straight away that it was your request that

10:47was the problem and the 401 specifically

10:50is relating to authentication errors.

10:53Whereas maybe say you have perhaps

10:56seen on a web page a page 404, that

10:59means that your request was incorrect.

11:02The 4 tells you that.

11:04And more specifically, the 404 status code

11:07tells us that a request was not found.

11:10And then lastly, we have status codes beginning with 5.

11:16That's the notice that we have some type of server error.

11:20So if you happen to receive a response from the server

11:24with maybe say a 500 status code,

11:26the 5 straightaway lets you know that the server is at fault.

11:30And a 500 status code, specifically

11:33denotes an internal server error.

11:37So really there happens to be a whole bunch

11:39of these types of status codes.

11:40Let me actually show you.

11:42If you happen to Google HTTP status codes,

11:45maybe go to Wikipedia.

11:47If we just Zoom in a little bit.

11:50Let's scroll on down.

11:51We can actually see some of the information here.

11:53We can see the informational response, successful responses,

11:57redirection, client error, and server error.

12:00And if we scroll on down, we can actually

12:01see more detailed information about them.

12:04So a 100 status code would denote a continue.

12:07A 201 is a resource created as I just said.

12:11A 204 is a no content response.

12:14If we scroll on, then we can see some client

12:16errors such as a 401 unauthorized,

12:19402 requires an actual payment to be made, 403 is forbidden.

12:23And again, we can keep scrolling through all

12:26of these different types of status codes.

12:28We can see we have an absolute ton.

12:29So the point I'm trying to highlight here

12:31is that the server can actually give you

12:33quite a lot of detailed information

12:35back whether your request is successful

12:38or whether if your request is not successful.

12:40You can kind get a good idea of how you could actually

12:43troubleshoot that problem.

12:45Like I said, if you happen to receive a 401,

12:48you know that you should go and check

12:51your credentials are correct.

12:53So this is one of the very big benefits of using REST APIs.

12:56So check this out.

12:57How about we go and make a little request, then.

13:00So what I'm going to do is I'm going

13:02to download some particular software known as Postman.

13:05Now this is a platform for testing APIs,

13:08for building APIs, so on and so forth.

13:10It is very, very useful.

13:12If we click on this here.

13:13Let me zoom in a little bit.

13:14If we download the desktop app, just

13:17click on Windows, Mac, or Linux.

13:19They happen to be using a Mac device right now.

13:21So I'll click this right here.

13:22I'm using the Apple chip, so I'll just click this here

13:25and a download should begin.

13:27That should be really quite similar,

13:29whether you happen to be using Windows or Linux natively.

13:32OK.

13:33So the download has completed.

13:35Let's click this.

13:36We're going to extract us.

13:37OK.

13:38So now you can either create a free account

13:40or sign in if you already have one.

13:42Or alternatively, you can sign in later.

13:45So let's click Skip and go to the app.

13:47So check this out right here.

13:48Via this particular application, we can send particular requests

13:52to our APIs.

13:54So what I'm going to do here is I'm

13:55going to go to my favorite public

13:58REST API that is good for testing.

14:00Let me show you where that is.

14:02If you happen to search for a GO REST API,

14:05let's click this top link right here,

14:07we can see here we have the server, which

14:09gives us some fake data that we can use to test.

14:12So check this out right here.

14:14Here are some particular resources

14:16that we can target, say, for example here if you want

14:18to target particular users of this fake database

14:22or particular posts or particular comments

14:25or to to-dos, whatever it may be.

14:27And we can see here we have some examples.

14:30This is a type of example we would look at when

14:33reading API documentation.

14:35We would just say, hey, we want to create a new user.

14:37How would we do so?

14:39We would send a POST request.

14:41Oh, sorry about that.

14:42POST request to this particular resource.

14:45Similarly if we wanted to details,

14:48we would just send a GET request to this particular resource.

14:51And this case here, 17 be an example of an ID for a user.

14:55And similarly if we wanted to delete the user,

14:58we would specify this particular resource, again,

15:01specifying the ID of that user.

15:04So let's actually try to see some particular user.

15:08So we'll actually use this resource here.

15:10So let's just copy this and we'll go to Postman.

15:13So if I just hit the plus sign right here,

15:15what I'm going to do is to enter in the URL I want to target.

15:19So I'll just paste this in right here.

15:21And notice here, this is where we can actually

15:23specify the verb or the method that we want to use.

15:27So I can see a GET, a POST, a PUT.

15:29We actually have more methods such as PATCH request,

15:32but we don't have to worry about that quite just yet.

15:35And we can see here things like DELETE request.

15:37So right now we will send a GET request

15:39to this particular resource.

15:42Now within our headers, if you recall,

15:45we can specify particular pieces of information.

15:48We can say, for example, specify and accept header.

15:52That's the type of data we want to accept.

15:55And the value I want to specify here

15:57is I want to get my data in JSON form.

16:01So I will say application/json.

16:04Similarly, if I have to specify particular authorization

16:07to access this resource, I will go into the Authorization tab

16:12and then specify maybe an API key or basic authentication,

16:16but we will specify a username and password

16:18to log in to the server.

16:20And this case here with GO REST, we

16:22have no authentication or, no authorization should I say.

16:26It's just a free resource, so we don't actually

16:28have to worry about this.

16:29Similarly, if we wanted to send some type of POST request

16:32or PUT request to update the resource,

16:34we would want to do so by specifying a particular body.

16:37So again, we can specify the body here.

16:40We could put it in raw data, so on and so forth.

16:43But again, we'll keep things pretty simple.

16:45Right now we're just sending a basic GET request.

16:48So we don't actually have to send a body along with that

16:51because we're just retrieving information.

16:54So what I will do here is we can see we have a header,

16:57we have an authorization set to no.

16:59We have a resource and we have the actual verb we're using,

17:03a GET request.

17:04So if I just send right here, we're

17:06going to send off the response, notice here,

17:09we can actually see the status code 200 OK.

17:12That means that the request was indeed

17:15accepted as successful by the server

17:17and we have the actual response.

17:20So we can actually see here we have this data listing

17:23all of the users within the database

17:25and that's a specified in JSON format.

17:28You see this right here, this is all JSON.

17:30Let me actually just pull this up a little bit.

17:32And this is the type of data that we

17:34can work with programmatically.

17:36So that we can use particular programming

17:38languages such as the Python programming language.

17:42And we'll get to see how we can do this in a little skill.

17:45So if I go back and look at the documentation here,

17:48and I happen to change the resource

17:51the time targeting to target the comments resource.

17:54So if we look at the data we have right here,

17:56we see information relating to the users.

17:58If we change the actual resource here and paste this

18:01into comments and send off a new request,

18:04we can see we have the 200 status code.

18:07Now within the actual output, we can actually

18:10see the posts that were sent.

18:13So notice we're seeing the ID of the user, the name

18:16of the user, the user's email as well as what they have actually

18:19posted.

18:20So this as the comment that user happened to leave that looks

18:24like to be some type of Latin text, which

18:27is common for demonstration purposes.

18:30But the point remains the same.

18:32We send a request, we target the resource.

18:34So you can imagine if we happen to change that resource

18:37to maybe be, let's imagine 8.8.8.8/bgp-neighbors again,

18:43I'm totally making this up, we could get BGP neighbor

18:47information.

18:47Whereas if we happened to specify OSPF neighbors,

18:51we would actually get OSPF information.

18:54And if we wanted to delete a particular OSPF neighbor,

18:58we could send DELETE request and then specify maybe say,

19:01the router ID of that neighbor we want to delete.

19:05This is a type of procedure we would walk

19:08through when using REST APIs.

19:11So that's all for a REST API status codes on verbs.

19:15The next thing we have to talk about

19:17is the remote procedure of call.

19:19And that is what we're going to be talking

19:20about in the very next Nugget.

19:22So I hope it should been informative for you

19:24and I'd like to thank you for viewing.

0:12Hey, guys.

0:13And welcome back.

0:14So now what I want to do is I want

0:16to turn your attention to a different style of API.

0:20Previously we had talked about the REST syle of API.

0:25But now what we want to do is to look at what

0:28is called the RPC style of API.

0:31This is the Remote Procedure Call.

0:35Now, there are some striking similarities with respect

0:39to RPC and REST.

0:41RPC is going to also utilize this client server model.

0:46Now as the name suggests, RPC, the primary function of the RPC

0:52is so that you as a client can use the RPC to call processes

0:58on a remote system.

1:00That would be the target server you're actually

1:02connecting with.

1:04Now, the real interesting point here with respect to RPC

1:07is that when you make that remote procedure call,

1:11it's really like running the process on a remote system

1:15as if it was executed locally.

1:18Now RPC is similar to REST in the respect

1:22that we can get information and modify information

1:24on remote systems.

1:26But the big difference here, really,

1:28is that with RPC, everything is going

1:30to be much more lightweight.

1:32So we're going to get a performance benefit

1:35when utilizing RPC versus REST.

1:38Now as we progress throughout this course

1:41we will eventually come to a very big protocol that

1:43is known as NETCONF, which is the network Configuration

1:47Protocol.

1:48And NETCONF, as you're going to see,

1:50actually utilizes these RPC, these remote procedure calls.

1:54And we use the RPCs to get information from our devices,

1:58such as state data.

2:00That could be interface counters, statistics,

2:03or it can be, say, for example, BGP peering information.

2:07Or if we want to get configuration data,

2:11such as our BGP route reflector configuration,

2:15we can do so using these RPC.

2:17Similarly, if we want to modify the configuration,

2:21say, for example, we want to change an access control list,

2:24then as we can see here, we use the RPC with NETCONF

2:29to be able to make that modification as needed.

2:32Now, as we progress throughout this course,

2:34we're going to actually learn about something called gRPC.

2:38This is Google's take on the remote procedure call.

2:42And similar to using regular RPC,

2:45although at an even greater scale,

2:48this is going to provide us really

2:50great performance benefits.

2:52But, again, we'll get to look at this in a lot

2:54more detail a little bit later on within this course when

2:57we talk about gRPC, as well as something called gNMI,

3:02which actually utilizes gRPC.

3:05But, really, for the purposes of the examination,

3:07we want to have an awareness of RPC as an alternative to REST.

3:13We have a lot of similarities in that we have our client server

3:17model.

3:17We can make changes on remote systems

3:20as if we were executing that procedure locally

3:23on our local system.

3:24And like I say, the real driving factor when using RPCs

3:29is that lightweight overhead, the performance

3:32boost you get with that.

3:33But the reality is in the modern world,

3:36the REST API is much more common and becoming much more popular.

3:41So, really, that is all for our introduction into RPC.

3:44So for now, I hope this has been informative for you.

3:46And I'd like to thank you for viewing.

0:12Hey, guys.

0:12And welcome back.

0:13So now what I want to do is to turn your attention

0:16to what are called synchronous APIs, as well

0:19as asynchronous APIs.

0:22So the question actually is, what

0:24are the differences between synchronous and asynchronous

0:27APIs?

0:28When would you want to use one versus the other?

0:31So let's start by talking about what

0:33asynchronous API actually is.

0:35Now, the first thing to note here

0:37is that synchronous APIs are blocking,

0:40and they're not going to return until a process either

0:43finishes, or if that process happens to error out.

0:48Whereas when we are talking about an asynchronous API,

0:52this is one which is non-blocking.

0:55So, really, what this means is that when

0:57we happen to utilize an asynchronous API,

1:00we can wait while doing other things.

1:02Which means that asynchronous APIs are really, really good

1:06for handling lots and lots of requests.

1:09Because if we implemented synchronous APIs,

1:13we would otherwise be bogged down due

1:15to all of the waiting between those requests.

1:19So let me give you a little analogy

1:20to help you understand what is actually going on here.

1:23So the analogy I often use here with respect

1:26to being able to describe asynchronous connections

1:31is the concept of a chess grandmaster.

1:34So you may not be aware of this, but in chess,

1:37grandmasters sometimes as a kind of demonstration

1:40of their prowess, what they will do is they

1:43will play multiple different people at the same time.

1:47So what we can see here is my really good drawing

1:49of what are going to be tables.

1:51So you can imagine a grandmaster going on to, say, table 1,

1:55and then round 2, table 2, table 3, 4, 5, and 6.

2:01So each table has a different opponent,

2:04and the grandmaster has to play every single opponent.

2:08Now imagine this as the synchronous connection.

2:12This is how this would actually play out.

2:14What would happen as the chess grandmaster

2:18would engage table 1 and the first player.

2:21So we would make a move as the grandmaster,

2:24and then we would wait for the player one to make a response.

2:28However, the game is not finished.

2:31So because of this, we ultimately

2:33have this type of blocking condition.

2:35So the grandmaster can actually leave the table

2:38until the game is complete.

2:40So you can imagine that with all of the waiting

2:44and all of the deliberation of player 1 trying

2:46to decide what to do against this highly

2:48skilled grandmaster, let's maybe say this whole game

2:52takes 30 minutes.

2:53Now, once the inevitable happens,

2:55the grandmaster defeats the novice player,

2:58the grandmaster then moves on to table two.

3:01Because the game has complete, the grandmaster

3:04is now freed up to go elsewhere.

3:06So the same thing repeats.

3:08We go to table two, we make our move, table--

3:11or rather, player two makes their move.

3:13And, once again, we are engaged within a game,

3:15so we cannot move on until that game is complete.

3:19Same, again, that this game maybe

3:21takes 20 minutes before the inevitable happens once again.

3:24The grandmaster wins, and then is freed up to move on.

3:28So you can imagine this continually happening.

3:30This maybe takes 30 minutes, 20.

3:33Let's maybe say 30, again, for here, 20 here, whatever

3:36it may be, so on and so forth.

3:39So this whole process of playing all of the six players,

3:43handling all of these requests may end up

3:46taking multiple hours, four or five hours.

3:49Now, this really isn't a very efficient use

3:51of the grandmaster's time because the grandmaster

3:53are very, very skilled.

3:55As soon as they get their time to make a move,

3:58they know exactly what they're going to do.

4:00They're not having to wait and think,

4:01they just want to move on and complete the game.

4:03So imagine this as an asynchronous operation.

4:07Let me show you how that's what actually differ.

4:09So now we're going to be async.

4:12So here's how this game is going to happen.

4:14The grandmaster is going to play their first move.

4:17And then as soon as the grandmaster makes their move,

4:20they are freed up to do as they wish.

4:23So the grandmaster immediately goes to the second table

4:26and plays the next move.

4:29Meanwhile, player one here is still

4:31deliberating and trying to strategize

4:34about what they should do, but it doesn't actually matter.

4:36The grandmaster is not locked in,

4:38the grandmaster can just keep moving around.

4:40So, again, after playing table two,

4:44the grandmaster runs over to table 3, and then table 4.

4:48Meanwhile player one is beginning

4:50to make their move, as as player two.

4:53But the grandmaster is racing on row.

4:55If went to table 5 and table 6, and suddenly

4:59they're back at table 1 again.

5:01And now player one has made their move,

5:04so the grandmaster can make another move

5:07and then jump to the next table.

5:09Because, again, asynchronous is non-blocking,

5:12so the grandmaster is free to move on and do other things as

5:17opposed to waiting.

5:18So the reality is the grandmaster

5:20can just keep running around all of these tables,

5:23playing the move that they're going to play.

5:26And as opposed to waiting for every game to complete,

5:29and eventually we get this type of concurrency going on.

5:33And, ultimately, the grandmaster could potentially

5:36defeat all six opponents in around 30 minutes,

5:40as opposed to four or five hours.

5:42So that really is the big difference

5:44when we don't have to wait on an operation,

5:47returning until it either finishes or errors out.

5:50As soon as we get free time, we can go on and do other things.

5:53Now, when it comes to synchronous APIs,

5:57a very classic example to implement a synchronous API

6:02would be something like, say, a local news app.

6:04Basically this application is going

6:06to wait for you to give at some information, such

6:10as you provide your location, and then application

6:14is going to return news relating to that particular area.

6:18So this idea of the application waiting for us

6:22to give it some information before completing

6:24the operation, this is very typical of synchronous APIs.

6:29Whereas if you happen to be dealing with,

6:32let's maybe say, like a real time data such as data

6:35that you're going to stream in to the system that is not

6:39requiring you to continually update it on your end,

6:42you can just make the request initially, and just let it

6:46process.

6:46And as things are changing, the asynchronous API

6:50can just pull in that information

6:52continually, and feed it through.

6:54So this is really good, like I say,

6:56if you're dealing with real time data.

6:59So if you had some type of application that

7:00was continually monitoring traffic and telling you

7:04about particular traffic congestion,

7:06and it was just constantly updating

7:08based on the data coming in, this

7:10will be a good use case for an asynchronous API.

7:14Similarly, if you wanted to monitor

7:17particular financial information, such as trading

7:21information relating to the stock exchange which is forever

7:24constantly fluctuating, having that data just stream in

7:28and be handled by an asynchronous

7:30API is really very useful.

7:33Now, another very good use case of an asynchronous connection

7:38is relating to network interfaces

7:41where we actually have a lot of waiting.

7:43The waiting actually relates to the input, output.

7:47As we are sending the request over the wire,

7:50say, for example, we are making a remote connection

7:53from somewhere in the United States

7:55to maybe, say, somewhere in the United Kingdom.

7:58The actual distance that we've got

8:00to travel, all the different connections on that route, that

8:04is actually implementing or, rather, introducing some type

8:08of waiting.

8:08So when we have that waiting, we don't

8:11want to be in a blocking state, we

8:13want our API to be able to move on and do other things

8:18whilst we are waiting on that connection completing.

8:20As opposed to being held hostage to whatever network latency

8:24we have.

8:25Now, I will say, synchronous APIs, as it stands right now,

8:30are far more common and simpler to implement.

8:34Whereas asynchronous APIs, they are gradually

8:37becoming more and more popular.

8:39And, really, the big advantage here

8:41is with respect to performance.

8:44So being able to understand the differences

8:46between synchronous connections and asynchronous connections,

8:50and when you would use one versus the other,

8:52those really are the details that we

8:54want to understand to satisfy the criteria set out

8:58within the ASP Auto Examination.

9:01So that is all for our introduction

9:03into synchronous and asynchronous connections.

9:05I hope this has been informative for you,

9:07and I'd like to thank you for viewing.