All language subtitles for Free-CCNA-REST-APIs-Day-61-CCNA-200-301-Complete-Course_en

This is a free, complete course for the CCNA.

If you like these videos, please subscribe\n

Also, please like and leave a comment, and\n

In this video we will look at REST APIs.

APIs are used to allow programs to exchange\n

They are important for network automation\n

interact with network devices and controllers.

REST APIs specifically are commonly used for\n

I’ve already briefly introduced REST APIs\n

REST APIs in greater depth, and then in the\n

This video will cover exam topic 6.5, which\n

So, as with all of the exam topics in this\n

the use of REST APIs, they just expect you\n

Here’s what we’ll cover in this video.

Then I’ll introduce CRUD operations and\nHTTP.

CRUD stands for Create, Read, Update, and\n

we perform when using REST APIs.

HTTP also uses CRUD operations, and REST APIs\n

over the network, so it’s important to understand\nHTTP.

Then I’ll outline the characteristics of\n

to try out a couple basic REST API Calls,\n

Make sure to watch until the end of the video\n

ExSim, the best practice exams for the CCNA.

So, let’s quickly review what an API is.

An API, application programming interface,\n

to communicate with each other.

They are essential not just for network automation,\n

If you want other applications to be able\n

should design an API that allows them to access\nit.

Here’s that basic diagram of SDN architecture\n

In SDN architecture, APIs are used to communicate\n

northbound interface, and between the SDN\n

The NBI typically uses REST APIs, the topic\nof this video.

Some other examples of APIs that can be used\n

interface are NETCONF and RESTCONF, but we\n

You’ll have to learn more about those for\n

CRUD stands for Create, Read, Update, Delete,\n

But this CRUD framework isn’t just used\n

First let’s look at the definition of each\nof those operations.

Create operations are used to create new variables\n

For example, you could create a variable “ip_address”\n

Read operations are used to retrieve the value\n

ask ‘What is the value of variable “ip_address”?

Update operations are used to change the value\n

the value of the variable “ip_address”\nto “10.2.3.4”.

And finally delete operations are used to\n

So, those are the CRUD operations, now let’s\nlook at HTTP.

First, why should I talk about HTTP, even\n

First, HTTP uses ‘verbs’ or ‘methods’\n

CRUD operations match the actions we typically\n

When an HTTP client sends a request to an\n

For example, if the client is trying to access\n

verb to retrieve that web page, to get it,\nfrom the server.

And for this reason, among others, REST APIs\n

protocol to communicate over the network.

So, let’s compare these CRUD operations\nto HTTP verbs.

The HTTP verb POST is used to create a new\nvariable.

The equivalent of a read operation is GET.

There are two main options for the update\n

the delete operation is simply DELETE.

You don’t have to know the exact details\n

ones are used for which CRUD operation.

The flashcards will help with remembering\nthem.

There are other HTTP verbs too, and you can\n

Let’s look more at how those verbs are used.

When an HTTP client, or a REST client using\n

some information such as an HTTP verb, which\n

identifier, indicating the resource it is\ntrying to access.

So, here we have a server storing data as\n

The client sends a GET message, for example,\n

The server would then send a response, but\n

Here’s an example of a URI, and I’ll use\n

First is the scheme, which is basically the\nprotocol.

In this case HTTP, or more specifically HTTPS,\n

This is basically the address, or hostname,\n

After that is the path, this indicates the\n

Now, the Verb and URI are just part of the\n

The HTTP request can include additional headers\n

There is a great list at this page here from\nMozilla.

Here’s an example of an HTTP request message.

On the outside there is an IP header and a\n

by some additional headers and data.

An example header would be the Accept header,\n

types of data that can be sent back to the\nclient.

The client might say I accept JSON data or\n

There’s another list of standard HTTP headers\n

for each header so you can see what kind of\n

Now, before I continue I want to clarify once\n

about HTTP in a video that’s supposed to\nbe about REST APIs.

It’s because when a REST client makes an\n

send an HTTP request like the one above.

So, you have to understand some basics about\nHTTP.

Note that REST APIs don’t actually HAVE\n

For the purpose of the CCNA you can assume\n

mind that HTTP is a specific communication\n

They aren’t the same thing, and they aren’t\n

Now, after the client’s HTTP request the\n

Let’s look a bit at what is in that response.

The server’s response will include a status\n

failed, as well as other details.

You might not know it, but I’m sure you’ve\n

The first digit indicates the class, the type,\nof the response.

Here are the different classes.

If the response code begins with a 1, it is\n

This indicates that the server received the\n

depends on the remaining two digits of the\nresponse code.

We’ll look at an example in the next slide.

If the response code begins with a 2, the\nclass is ‘successful’.

This means the request was successfully received,\n

This is usually the class of response you\nwant from the server.

If the response code begins with a 3 the class\nis redirection.

It means that further action is required to\n

For example, if the URI of the resource has\n

to request the new URI to get the resource.

If the response code begins with a 4, the\n

This means there was some error in the request\n

a resource that doesn’t exist.

Let me show an example of that.

The client sends a GET request for the resource\n

So, it sends a response with response code\n

I think many of you will recognize the 404\n

For example, I tried to access google.com/jeremysitlab,\n

Notice the response code, 404, indicating\n

I got this error message because google.com/jeremysitlab\n

acquires my company for the low price of a\nbillion dollars.

If anyone from Google’s watching, I’m\nwaiting for your offer.

Anyway, there is one more class of response.

If the response code begins with a 5 the class\nis server error.

This means that the request was valid, but\n

For example, perhaps the server doesn’t\n

Here are some examples of each HTTP Response\nclass.

I’ll just give one or two examples for each.

For the informational class, you might see\n

This indicates that the server has received\n

response is not yet available.

For the successful class you might see code\n200, meaning OK.

This indicates that the request succeeded.

If this is in response to a GET request, for\n

it was successful, and in the message body\n

Another example is 201, created, which indicates\n

was created, for example in response to a\nPOST request.

Remember, POST is equivalent to the CRUD Create\noperation.

In the redirection class, 301, moved permanently,\n

been moved, and the server indicates its new\n

In the client error class we have 403, unauthorized.

This means that the client must authenticate\nto get a response.

Note that when talking about AAA in the security\n

The official name for code 403 is unauthorized,\n

because it indicates that the client needs\nto authenticate.

Another example is 404, indicating that the\n

Finally, an example of the server error class\n

the server encountered something unexpected\n

These are just a few examples, but there are\n

If you’re curious about the others, check\n

You can also check out this page for a summary\n

Okay, that’s enough about HTTP.

Let’s finally take a look at some characteristics\nof REST APIs.

REST stands for representational state transfer.

And REST APIs are also known as REST-based\nAPIs or RESTful APIs.

I usually just call them REST APIs.

Note that, as I’ve said before, REST isn’t\na specific API.

Rather, it describes a set of rules about\n

The six constraints, or rules, of RESTful\n

architecture, stateless operations, cacheable\n

and optionally something called code-on-demand.

If you’re curious to know more details about\n

but now I will explain just a few of them\n

REST APIs use a client-server architecture,\nlike HTTP.

The client uses API calls, basically that\n

the server, such as in the example below.

The separation between the client and server\n

independently of each other, they aren’t\n

And when the client application changes or\n

between them must not break, it should continue\nto function.

I think you’re fairly familiar with client-server\n

The next characteristic I want to cover is\n

I haven’t mentioned this term yet in the\n

Statelessness means that each API exchange\n

exchanges between the client and server.

So, the server does not store information\n

should respond to new requests.

Each new request is a totally separate event.

And if authentication is required, this means\n

server for each request it makes.

Although I haven’t used the term stateless,\n

some stateful and stateless protocols.

For example, TCP is stateful.

It establishes connections and uses sequence\n

UDP, on the other hand, is stateless.

No connection is set up and neither host keeps\n

The data is simply sent from host A to host\n

Now, I want to make a clarification.

Although REST APIs use HTTP, which uses TCP\n

Keep in mind that the functions of the layers\n

Just because a stateful Layer 4 protocol is\n

protocol must also be stateful.

The last rule of REST APIs that I’ll mention\n

REST APIs must support caching of data, basically\n

You might have heard this term before in reference\n

For example, your computer might cache many\n

have to retrieve the entire page every time\nyou visit it.

This improves performance for the client and\n

So, caching must be supported, but that doesn’t\n

Not all resources have to be cacheable, but\n

when the server sends them to the client,\n

As I said before, if you’re curious about\n

this link for restfulapi.net, but those three\n

And I’m repeating myself, but let me say\nthis again.

For applications to communicate over a network,\n

And for REST APIs, HTTP is the most common\n

That’s all we’ll cover for REST.

For the CCNA, Make sure you know the CRUD\n

response codes, and the basic characteristics\n

Now let’s move on to try some simple REST\n

I’ll let them describe it themselves.

Cisco DevNet is Cisco’s developer program\n

want to write applications and develop integrations\n

Basically, DevNet offers lots of free resources\n

documentation, etc. to learn about automation\n

It really is a great resource and it keeps\ngetting better.

Note that there is also a DevNet certification\n

If that’s the case for you, perhaps consider\n

Today we will use their Cisco DNA Center Sandbox\n

DNA Center is one of Cisco’s SDN controllers,\n

we go more in depth regarding SDN.

DevNet has various always-on sandboxes, which\n

time and look around to get familiar with\nthem.

In this case we’ll use their always-on DNA\nCenter sandbox.

And Postman, which we’ll use to send the\n

It’s also a great learning tool.

So, to start I want you to make an account\n

an account on postman.com and download the\ndesktop app.

You can use it directly in your browser too,\n

For this demonstration we will simply follow\n

Go to this link or just do a google search\n

Note that you don’t have to follow along,\n

But even if you’re just following what I’m\n

DevNet too because it will explain the reason\n

So, I’ve installed the Postman desktop app\nand opened it.

From the home screen, click on workspaces\n

If you don’t have a workspace you can create\n

Next you should click New here.

That will open this window, where you can\n

For example, you can create a new API, documentation\n

In this case, we want to create an HTTP request\n

After clicking on HTTP request, we can now\n

to send to DNA center’s REST API.

As explained in the DevNet tutorial, first\n

which we will use for our second HTTP request.

First, set the HTTP verb to POST, it is GET\nby default.

Then we have to specify the URL.

Just a quick note, the DevNet tutorial uses\n

I used the term URI, Uniform Resource Identifier,\n

Basically, a URL is just a type of URI.

You can google ‘URI vs URL’ for more info.

So, if we send a POST request to this URL,\n

However we have to specify a username and\n

To do that, click on authorization here, and\n

That will open this menu, where you should\n

Username devnetuser, password Cisco123! with\n

Okay, the POST is ready so now we can click\n

If the POST is successful you will get a response\n

The body of the response message will include\n

Make sure to copy the value of the token.

You don’t have to copy the quotation marks\n

Okay, now we’re ready to send the second\n

from the DNA center controller.

First, change the HTTP verb to GET.

We will also send this request to a different\n

And the next step is to add an additional\n

To do that, click on ‘headers’ here, enter\n

value field paste the authorization key you\n

Okay, now we’re ready for the second API\n

If the GET is successful, you will once again\n

And in the body we get the requested information,\n

of devices managed by the DNA center controller.

The output here is quite long, but let me\n

You should be familiar with the format, as\n

So, by looking at this output we can learn\n

For example, the device family is listed as\nswitches or hubs.

Since hubs aren’t really used anymore, it’s\n

The role is access, so it’s an access layer\nswitch.

The hostname is leaf1.abc.com.

Leaf1, perhaps that means this is a leaf switch\n

Here’s the platform ID, C9300-24U.

This is the device model, Catalyst 9300.

Here’s a picture of a C9300, by the way.

We can also get info like the uptime, how\n

So, that was a quick look at some basic REST\n

We retrieved data in a machine-readable format,\n

data like this, interact with it, tell DNA\n

We’ve barely scratched the surface, but\n

Here’s what we covered in this video.

We briefly reviewed what an API is, and then\n

Then we looked at the basic characteristics\n

API Calls to DNA Center using a Cisco DevNet\ntutorial.

As I mentioned earlier, make sure you know\n

HTTP server response codes, and the basic\n

I also gave various links to different resources\n

although they will go in much more depth than\nis required.

But check them out if you want a greater understanding.

And make sure to watch until the end of the\n

Software’s ExSim, the best practice exams\nfor the CCNA.

Okay, let’s go to quiz question 1.

What HTTP response code would you expect to\n

Pause the video now to select the best answer.

If the requested resource does not exist on\n

Which of the following is NOT a constraint\n

Pause the video now to select the best answer.

Okay, the answer is C, stateful.

REST APIs are stateless, meaning that each\n

not dependent on any previous requests.

In addition to these five constraints, there\n

which basically extends client functionality\n

Which category of HTTP response would you\n

Pause the video now to select the best answer.

Okay, the answer is B, you should expect a\n

This indicates a successful request, for example\n

HTTP verbs PUT and PATCH are equivalent to\nwhat CRUD operation?

Pause the video now to select the best answer.

Okay, the answer is C, U, which stands for\nupdate.

Note that you might also see PUT categorized\n

to create new variables, but usually it’s\n

Which of the following would you expect to\n

Pause the video now to select the best answer.

The scheme of a URI identifies the protocol\n

Okay, that’s all for the quiz.

Now let’s take a look at a bonus question\n