WEBVTT 0:00:03.180000 --> 0:00:07.780000 Hello and welcome to this video, which is titled Characteristics of Rest 0:00:07.780000 --> 0:00:12.160000 -based APIs. In this video, I'm going to talk about, I'm going to start 0:00:12.160000 --> 0:00:14.860000 with a definition of what is an API. 0:00:14.860000 --> 0:00:19.240000 We're going to talk about certain types of APIs called Web Service APIs. 0:00:19.240000 --> 0:00:23.900000 We're going to look at some types and similarities among Web Service APIs 0:00:23.900000 --> 0:00:26.140000 and then we're going to dig into REST APIs. 0:00:26.140000 --> 0:00:31.360000 I'm going to expand on what does that acronym REST stand for? 0:00:31.360000 --> 0:00:34.860000 Or the architectural constraints of a REST API? 0:00:34.860000 --> 0:00:37.420000 In other words, if you were going to build one, what would be the rules 0:00:37.420000 --> 0:00:38.840000 you'd have to follow? 0:00:38.840000 --> 0:00:43.020000 We're going to talk about something called HTTP verbs and CRUD, which 0:00:43.020000 --> 0:00:44.900000 will make more sense when we get to that section. 0:00:44.900000 --> 0:00:49.860000 We'll also look at REST API data encoding. 0:00:49.860000 --> 0:00:55.800000 Now, if you're like me, if you're the typical network engineer, you've 0:00:55.800000 --> 0:00:58.340000 been working on networks for a while and for the longest time, there's 0:00:58.340000 --> 0:01:01.580000 been a definite dividing line or distinction between the network engineer 0:01:01.580000 --> 0:01:04.140000 and the software developer. 0:01:04.140000 --> 0:01:07.500000 There were just terms, acronyms, things that you could throw out there 0:01:07.500000 --> 0:01:10.260000 and they fell on either side of the fence. 0:01:10.260000 --> 0:01:14.340000 This term here, API was something that typically fell squarely in the 0:01:14.340000 --> 0:01:16.460000 software developer's realm. 0:01:16.460000 --> 0:01:19.800000 So if you were a network engineer such as I am, when you heard this term 0:01:19.800000 --> 0:01:24.280000 API, if you ever heard it at all, you'd think, I don't have to know about 0:01:24.280000 --> 0:01:27.320000 that. That's nothing that I deal with when I log into my Cisco router 0:01:27.320000 --> 0:01:30.160000 or switch or ASA firewall or something. 0:01:30.160000 --> 0:01:33.120000 That's the software developers that deal with APIs. 0:01:33.120000 --> 0:01:37.180000 Well, now that we're starting to move more and more into this world of 0:01:37.180000 --> 0:01:41.380000 network programmability and automation and software defined networking, 0:01:41.380000 --> 0:01:45.480000 it is becoming more and more important for the average network engineer 0:01:45.480000 --> 0:01:48.260000 to know what an API is. 0:01:48.260000 --> 0:01:52.400000 Now, as a network engineer, this isn't to say, all of a sudden you have 0:01:52.400000 --> 0:01:58.420000 to learn JavaScript or C++ programming and create an API from scratch. 0:01:58.420000 --> 0:02:02.220000 No, as of right now, that's still pretty much the job of the software 0:02:02.220000 --> 0:02:04.940000 developer to do that kind of thing. 0:02:04.940000 --> 0:02:08.240000 So why do we as network engineers even need to know anything about APIs 0:02:08.240000 --> 0:02:11.220000 at all? Well, here's why. 0:02:11.220000 --> 0:02:14.740000 Like I said, if you're getting into the world of software defined networking, 0:02:14.740000 --> 0:02:18.360000 either you're moving into that in your own organization or it's something 0:02:18.360000 --> 0:02:21.240000 you're studying or let's be frank, maybe it's something you just need 0:02:21.240000 --> 0:02:23.380000 to learn to pass a certification. 0:02:23.380000 --> 0:02:25.780000 Well, in software defined networking, we know there's this controller, 0:02:25.780000 --> 0:02:29.760000 which is supposed to control everything in the network. 0:02:29.760000 --> 0:02:36.960000 Well, an API is the thing that connects the controller to the network, 0:02:36.960000 --> 0:02:39.460000 how the controller talks to the network. 0:02:39.460000 --> 0:02:42.140000 It uses this thing called an API. 0:02:42.140000 --> 0:02:46.120000 And if you have applications out there and you want those applications 0:02:46.120000 --> 0:02:49.940000 to talk to the controller, you want an application to say, hey, tell me 0:02:49.940000 --> 0:02:53.960000 what the network looks like or report back to me some network statistics. 0:02:53.960000 --> 0:02:58.160000 Or maybe the application says, hey, I need you to change the network to 0:02:58.160000 --> 0:03:02.120000 make it fit these parameters so that my application will work nicely. 0:03:02.120000 --> 0:03:07.300000 The way the application talks to the controller is via an API. 0:03:07.300000 --> 0:03:12.380000 So although you don't have to know how to create an API from scratch, 0:03:12.380000 --> 0:03:16.400000 you will more and more need to learn things like, okay, based on the controller, 0:03:16.400000 --> 0:03:20.700000 I just purchased what kinds of APIs does it use? 0:03:20.700000 --> 0:03:25.060000 Because the type of API it uses will dictate what languages or protocols 0:03:25.060000 --> 0:03:28.120000 does it use to speak to things? 0:03:28.120000 --> 0:03:33.200000 Some APIs will just send CLI over SSH. 0:03:33.200000 --> 0:03:34.680000 There are APIs that do that. 0:03:34.680000 --> 0:03:39.260000 Some APIs utilize HTTP to talk to devices. 0:03:39.260000 --> 0:03:43.220000 So you'd have to know what kind of language the API speaks so that you 0:03:43.220000 --> 0:03:48.040000 will know if your supporting devices can talk using that API that's built 0:03:48.040000 --> 0:03:50.660000 into controller and other things. 0:03:50.660000 --> 0:03:53.160000 So let's talk a little bit more just at a high level. 0:03:53.160000 --> 0:03:54.920000 First of all, about what is an API. 0:03:54.920000 --> 0:04:00.220000 So that acronym stands for application programming interface, application 0:04:00.220000 --> 0:04:02.040000 programming interface. 0:04:02.040000 --> 0:04:05.680000 And really at a high level, it's just a piece of code that somebody wrote 0:04:05.680000 --> 0:04:08.940000 that allows different applications to talk to each other. 0:04:08.940000 --> 0:04:14.340000 So there's two different kinds of APIs, generically at a really high level. 0:04:14.340000 --> 0:04:17.940000 There's those that allow internal applications in your local system to 0:04:17.940000 --> 0:04:20.140000 exchange data. What does that mean? 0:04:20.140000 --> 0:04:21.320000 Well, think about this. 0:04:21.320000 --> 0:04:24.260000 Imagine you're doing something really simple like you've got a web page 0:04:24.260000 --> 0:04:28.500000 you're looking at and using your mouse, you highlight some of the text, 0:04:28.500000 --> 0:04:32.580000 you right click, you select copy, and then you bring up some other application 0:04:32.580000 --> 0:04:36.980000 like notepad or Wordpad or whatever text editor you've got, you right 0:04:36.980000 --> 0:04:39.660000 click in there and you do paste. 0:04:39.660000 --> 0:04:44.520000 Well, what you've just done is you've just transferred data from one application, 0:04:44.520000 --> 0:04:48.320000 the web browser in this case, over into another application, your text 0:04:48.320000 --> 0:04:51.880000 editor, and those two applications weren't built to talk to each other. 0:04:51.880000 --> 0:04:56.700000 The text editor has no idea what a web browser is and vice versa. 0:04:56.700000 --> 0:04:58.740000 So you need something to connect those two. 0:04:58.740000 --> 0:05:00.860000 And that's what the API is. 0:05:00.860000 --> 0:05:03.400000 So when you're right clicking and doing copy and paste from one device 0:05:03.400000 --> 0:05:07.780000 to another, from one application to another in your local laptop or tablet, 0:05:07.780000 --> 0:05:12.520000 you are actually making use of one or more APIs to allow those applications 0:05:12.520000 --> 0:05:16.760000 to talk. It all happens in the background, you have no idea what the name 0:05:16.760000 --> 0:05:21.080000 of the API is or what functions are being called, but that's what an API 0:05:21.080000 --> 0:05:25.860000 does. It allows one application to exchange data with another application. 0:05:25.860000 --> 0:05:27.960000 It's a connector between the two. 0:05:27.960000 --> 0:05:33.280000 So like I mentioned, one type of API has no networking function whatsoever, 0:05:33.280000 --> 0:05:35.980000 like the one I just described where you're copying text from your web 0:05:35.980000 --> 0:05:37.600000 browser into notepad. 0:05:37.600000 --> 0:05:42.240000 There's nothing to do with networking or IP involved in that kind of API. 0:05:42.240000 --> 0:05:46.320000 That kind of API is meant to work only within your local system. 0:05:46.320000 --> 0:05:49.160000 Now in the world of software defined networking and network automation 0:05:49.160000 --> 0:05:53.140000 configuration, that's not really the type of APIs we're concerned about. 0:05:53.140000 --> 0:05:57.260000 We're concerned about the other type, which is the type that allows devices 0:05:57.260000 --> 0:06:02.540000 that are separated across an IP network, or I should say applications, 0:06:02.540000 --> 0:06:05.820000 that are separated across an IP network to exchange data with each other 0:06:05.820000 --> 0:06:11.440000 using IP. We call those web service APIs, and there are other ones as 0:06:11.440000 --> 0:06:15.380000 well. So that's really the type of API we're talking about in this world 0:06:15.380000 --> 0:06:17.020000 that we're dealing with here. 0:06:17.020000 --> 0:06:23.140000 So in the world of software defined networks, there are two primary uses 0:06:23.140000 --> 0:06:26.360000 of application programming interfaces. 0:06:26.360000 --> 0:06:30.580000 Number one, like I said, applications connecting to controllers. 0:06:30.580000 --> 0:06:34.140000 So someone's got a server somewhere and they're writing some application, 0:06:34.140000 --> 0:06:38.000000 maybe they're writing their own network automation application, or they're 0:06:38.000000 --> 0:06:41.820000 writing who knows what it is, but that application on that server needs 0:06:41.820000 --> 0:06:44.620000 to communicate with the controller. 0:06:44.620000 --> 0:06:47.960000 It needs to send requests to that controller, get data back. 0:06:47.960000 --> 0:06:49.780000 Well, an API is going to be used for that. 0:06:49.780000 --> 0:06:54.580000 And for the controller to communicate downstream, what we would call southbound, 0:06:54.580000 --> 0:06:56.640000 to your network devices. 0:06:56.640000 --> 0:06:59.540000 So however the controller chooses to communicate with your routers and 0:06:59.540000 --> 0:07:04.020000 switches and firewalls, and APIs used for that too. 0:07:04.020000 --> 0:07:08.320000 So both of these types of communications take place over the Internet 0:07:08.320000 --> 0:07:15.860000 protocol and very frequently utilize HTTP or HTTPS as a transport mechanism. 0:07:15.860000 --> 0:07:19.360000 Now another thing that makes APIs consistent is that all APIs utilize 0:07:19.360000 --> 0:07:21.280000 a client server model. 0:07:21.280000 --> 0:07:26.340000 So that when an API is making requests saying, hey, tell me what you have, 0:07:26.340000 --> 0:07:28.580000 or hey, I'd like to change something on you. 0:07:28.580000 --> 0:07:31.460000 That device that's sort of initiating their request would be considered 0:07:31.460000 --> 0:07:35.520000 the API client, and the device that actually has the data that's being 0:07:35.520000 --> 0:07:38.700000 acted upon would be the API server. 0:07:38.700000 --> 0:07:42.320000 So in the terms of networking and SDNs, what we're looking at is when 0:07:42.320000 --> 0:07:47.420000 an application is communicating with an SDN controller, the application 0:07:47.420000 --> 0:07:51.040000 would be considered the client, the SDN controller would be considered 0:07:51.040000 --> 0:07:55.040000 the server from the perspective of the API. 0:07:55.040000 --> 0:08:00.280000 Now if that same controller is now invoking API to talk to a router or 0:08:00.280000 --> 0:08:03.720000 a switch or a firewall, now the roles are reversed. 0:08:03.720000 --> 0:08:08.900000 The controller is considered the API client and the router or switch or 0:08:08.900000 --> 0:08:12.380000 firewall or whatever it happens to be, maybe a server in a virtualized 0:08:12.380000 --> 0:08:16.500000 environment, that would be considered your API server. 0:08:16.500000 --> 0:08:21.120000 So the APIs we're talking about here that operate over an IP network are 0:08:21.120000 --> 0:08:24.100000 considered web service APIs. 0:08:24.100000 --> 0:08:29.380000 So the data within that API, so now we have to think about this here for 0:08:29.380000 --> 0:08:33.460000 a second. So let's narrow it down to an API that's existing so that a 0:08:33.460000 --> 0:08:37.600000 controller can talk to, let's say, a router to make it simple. 0:08:37.600000 --> 0:08:43.700000 Well, if you were developing an API like that, one of the things you would 0:08:43.700000 --> 0:08:49.160000 have to sort of think about is when my controller sends a request to that 0:08:49.160000 --> 0:08:53.360000 router, maybe request to get information about the routing protocol that's 0:08:53.360000 --> 0:08:57.620000 running, or maybe a request to change the routing protocol. 0:08:57.620000 --> 0:09:04.880000 So how do I format that in a way the router will understand? 0:09:04.880000 --> 0:09:08.900000 I mean, routers typically understand Cisco, iOS, command line, or Junos, 0:09:08.900000 --> 0:09:10.820000 or whatever it is you're dealing with. 0:09:10.820000 --> 0:09:13.320000 So an API could certainly do that. 0:09:13.320000 --> 0:09:17.140000 An API could send just the regular old CLI command that you type on the 0:09:17.140000 --> 0:09:21.460000 keyboard, it could encapsulate that and send that down to router switch. 0:09:21.460000 --> 0:09:26.060000 But there are other ways as well to send the same data without it actually 0:09:26.060000 --> 0:09:27.960000 being an iOS command line. 0:09:27.960000 --> 0:09:32.840000 So in web service APIs that messes that you're sending down, whether it 0:09:32.840000 --> 0:09:37.300000 be, please give me the contents of your routing table, or please configure 0:09:37.300000 --> 0:09:42.280000 this VLAN. In a web service API, the format of that request, what that 0:09:42.280000 --> 0:09:47.980000 request looks like, is usually formatted as either a URI or a URL. 0:09:47.980000 --> 0:09:55.300000 URI being Uniform Resource Indicator, URL being Uniform Resource Locator. 0:09:55.300000 --> 0:09:59.020000 So URIs and URLs look very similar. 0:09:59.020000 --> 0:10:00.060000 They look like a web page. 0:10:00.060000 --> 0:10:04.840000 Like when you go to www .iony.com, that is a URL. 0:10:04.840000 --> 0:10:11.880000 Now a URI looks very similar to a Uniform Resource Identifier. 0:10:11.880000 --> 0:10:13.980000 Looks very similar to a URL. 0:10:13.980000 --> 0:10:18.320000 String of characters used to identify a resource on a computer network. 0:10:18.320000 --> 0:10:22.800000 So a URL is an example of a URI. 0:10:22.800000 --> 0:10:25.640000 For example, here is a URI. 0:10:25.640000 --> 0:10:30.720000 This is actually URI taken directly from one of the APIs that runs within 0:10:30.720000 --> 0:10:35.260000 a Cisco controller to talk to devices like a Cisco router switch. 0:10:35.260000 --> 0:10:40.640000 This particular URI is where you would send down to get back from the 0:10:40.640000 --> 0:10:42.820000 switch a list of its VLANs. 0:10:42.820000 --> 0:10:44.420000 Tell me what VLANs you have. 0:10:44.420000 --> 0:10:54.960000 Now, notice the format of it looks very similar to a web page, right? 0:10:54.960000 --> 0:10:58.180000 It's something you could put into a browser and it would give you back 0:10:58.180000 --> 0:11:02.400000 a web page. This URI here, it's not meant to give you a web page. 0:11:02.400000 --> 0:11:08.580000 It's just a structure of formatted data that you can send down to a switch 0:11:08.580000 --> 0:11:13.900000 in this case saying, Hey, switch, I am DNA center. 0:11:13.900000 --> 0:11:18.220000 That's the DNA. I am using the intent API. 0:11:18.220000 --> 0:11:21.640000 That's the name of one of their APIs, the intent API. 0:11:21.640000 --> 0:11:23.000000 That's the intent here. 0:11:23.000000 --> 0:11:26.280000 API, I am using version one of the API. 0:11:26.280000 --> 0:11:30.320000 Network device number 502, right? 0:11:30.320000 --> 0:11:34.060000 So the switch has been assigned a network device ID. 0:11:34.060000 --> 0:11:40.360000 DNA center knows what that ID is. 0:11:40.360000 --> 0:11:42.660000 So it's a 500-1 VLAN. 0:11:42.660000 --> 0:11:43.940000 Give me your VLANs. 0:11:43.940000 --> 0:11:47.600000 So you can see it's sort of a structured query that's being sent down 0:11:47.600000 --> 0:11:53.180000 to the switch. So in web service APIs, the format of the data looks very 0:11:53.180000 --> 0:11:53.880000 similar to this. 0:11:53.880000 --> 0:11:56.400000 It looks very similar to a web page that you would bring up in your URL 0:11:56.400000 --> 0:12:03.440000 bar. So what can web service APIs do with regards to data? 0:12:03.440000 --> 0:12:05.160000 Well, they can create it. 0:12:05.160000 --> 0:12:07.080000 They can add new data. 0:12:07.080000 --> 0:12:08.540000 They can ask for data. 0:12:08.540000 --> 0:12:11.160000 They can read it from the server. 0:12:11.160000 --> 0:12:13.500000 They can modify the data. 0:12:13.500000 --> 0:12:17.620000 And of course, they can delete or destroy the data. 0:12:17.620000 --> 0:12:20.080000 So what are some common web service APIs? 0:12:20.080000 --> 0:12:23.540000 If you start getting more and more into the world of web service APIs, 0:12:23.540000 --> 0:12:25.680000 I'm not going to go into the details of each one of these. 0:12:25.680000 --> 0:12:29.460000 This is just to give you an idea that there are some variations out there. 0:12:29.460000 --> 0:12:35.960000 The simple object access protocol, XML, RPC, JSON, RPC, and REST. 0:12:35.960000 --> 0:12:39.160000 In this video, we're primarily going to be concerned with REST APIs. 0:12:39.160000 --> 0:12:41.180000 I just wanted to call your attention to the fact that there are other 0:12:41.180000 --> 0:12:43.540000 types of APIs out there. 0:12:43.540000 --> 0:12:46.700000 Each one formats the data a little bit differently. 0:12:46.700000 --> 0:12:49.400000 You know, how the data looks like and how it structures a little bit different 0:12:49.400000 --> 0:12:50.920000 in each one of these things. 0:12:50.920000 --> 0:12:54.020000 So, you know, if you're working in the world of SDN controllers, whatever, 0:12:54.020000 --> 0:12:58.220000 that's the first question is, which type of API is my controller using 0:12:58.220000 --> 0:13:02.460000 to talk to my devices and for applications to talk to my controller? 0:13:02.460000 --> 0:13:05.660000 You need to sort of be able to conceptualize that and visualize that in 0:13:05.660000 --> 0:13:08.940000 your head to get a better idea of what's happening in the background. 0:13:08.940000 --> 0:13:13.020000 Now, whether you're dealing with soap or REST or any of the other ones, 0:13:13.020000 --> 0:13:16.440000 there are some similarities among all these web service APIs. 0:13:16.440000 --> 0:13:18.280000 So, what do they all have in common? 0:13:18.280000 --> 0:13:22.680000 Well, number one, they're all designed to basically do the same thing, 0:13:22.680000 --> 0:13:28.220000 allow different applications to share data residing across an IP network. 0:13:28.220000 --> 0:13:31.860000 Number two, design operate across an IP network. 0:13:31.860000 --> 0:13:34.120000 Now, how are they different from each other? 0:13:34.120000 --> 0:13:40.340000 Okay, well, some of those APIs, like the simple object access protocol, 0:13:40.340000 --> 0:13:44.060000 are protocols with very distinct rules to follow. 0:13:44.060000 --> 0:13:48.120000 Very distinct rules about how it operates, the format of the data, how 0:13:48.120000 --> 0:13:52.220000 big the fields are, what it can do, what it can't do, whereas other APIs 0:13:52.220000 --> 0:13:58.060000 like the REST API are more general architectural guidelines about how 0:13:58.060000 --> 0:13:59.700000 the API should function. 0:13:59.700000 --> 0:14:00.820000 What does that mean? 0:14:00.820000 --> 0:14:03.020000 Well, let me give you two different examples. 0:14:03.020000 --> 0:14:07.140000 Soap would be like the OSPF protocol. 0:14:07.140000 --> 0:14:11.620000 If you open up the document, the ROC for the OSPF protocol is very specific 0:14:11.620000 --> 0:14:14.360000 on this event triggers this. 0:14:14.360000 --> 0:14:17.360000 This has to happen within this amount of seconds. 0:14:17.360000 --> 0:14:20.840000 The data has to look this much, it has to be this size. 0:14:20.840000 --> 0:14:23.680000 OSPF is very specific about how it works. 0:14:23.680000 --> 0:14:28.260000 Everything is identified, everything is quantified and notated about how 0:14:28.260000 --> 0:14:30.680000 OSPF does its thing. 0:14:30.680000 --> 0:14:32.280000 So that would be like soap. 0:14:32.280000 --> 0:14:36.140000 Rest is more like the OSI model, right? 0:14:36.140000 --> 0:14:40.240000 In the seven layer OSI model, you've got your seven layers, the application, 0:14:40.240000 --> 0:14:41.920000 the physical, the network layer. 0:14:41.920000 --> 0:14:46.540000 Each layer gives you a general representation about what's happening at 0:14:46.540000 --> 0:14:50.340000 that layer, but it doesn't go into the specifics about you have to use 0:14:50.340000 --> 0:14:53.460000 this protocol. This is what the data field has to look like. 0:14:53.460000 --> 0:14:54.520000 It has to be this big. 0:14:54.520000 --> 0:14:56.280000 It has to go every 30 seconds. 0:14:56.280000 --> 0:14:58.320000 It's not real specific like OSPF. 0:14:58.320000 --> 0:15:01.200000 It's more of an architectural guideline. 0:15:01.200000 --> 0:15:02.600000 So that's what REST is like. 0:15:02.600000 --> 0:15:05.620000 So that's sort of the difference between those two APIs. 0:15:05.620000 --> 0:15:10.520000 So let's go into REST a little bit. 0:15:10.520000 --> 0:15:16.160000 Now, so REST stands for Representational State Transfer. 0:15:16.160000 --> 0:15:21.800000 And this is a type or a model of APIs that was developed by Roy Fielding 0:15:21.800000 --> 0:15:25.160000 way back in 2000, as you can see here. 0:15:25.160000 --> 0:15:27.900000 Why are we focusing on REST APIs? 0:15:27.900000 --> 0:15:32.240000 Well, because from the standpoint of software defined networking and network 0:15:32.240000 --> 0:15:37.560000 automation and network programmability, this is by far the most common 0:15:37.560000 --> 0:15:41.160000 type of web service API you're going to find. 0:15:41.160000 --> 0:15:45.360000 So the vast majority of controllers out there, the vast majority of network 0:15:45.360000 --> 0:15:51.240000 automation tools, they use REST APIs to talk to each other and to exchange 0:15:51.240000 --> 0:15:55.240000 data. So we don't really have to know too much about those other ones. 0:15:55.240000 --> 0:15:58.420000 I just showed you this is the main one that's in use today. 0:15:58.420000 --> 0:16:02.640000 So REST APIs act on resources. 0:16:02.640000 --> 0:16:04.200000 What the heck is a resource? 0:16:04.200000 --> 0:16:10.500000 This is just a general term for whatever type of data that REST API is 0:16:10.500000 --> 0:16:14.480000 asking for, trying to change, trying to delete. 0:16:14.480000 --> 0:16:17.900000 We just call that a resource. 0:16:17.900000 --> 0:16:21.000000 So that's just another way of saying this is what REST is designed to 0:16:21.000000 --> 0:16:23.980000 work with, resources. 0:16:23.980000 --> 0:16:29.620000 Now, REST API, because it is a web service API, it operates across an 0:16:29.620000 --> 0:16:34.620000 IP network. And higher than that, REST APIs, one thing they all have in 0:16:34.620000 --> 0:16:37.380000 common is that they utilize HTTP. 0:16:37.380000 --> 0:16:40.680000 So if you're already a little bit familiar with how web browsing works 0:16:40.680000 --> 0:16:44.360000 and how HTTP works, if you know, okay, well, when I want to pull down 0:16:44.360000 --> 0:16:47.380000 a website, I go there and I say, get. 0:16:47.380000 --> 0:16:50.300000 Get.iony.com. That's retrieving something. 0:16:50.300000 --> 0:16:51.360000 Well, guess what? 0:16:51.360000 --> 0:16:55.660000 That's how a REST API retrieves information from a server. 0:16:55.660000 --> 0:17:01.760000 So if my software defined controller is the client and a router is a server, 0:17:01.760000 --> 0:17:05.360000 and I'm using a REST API between them, let's say the router natively supports 0:17:05.360000 --> 0:17:06.460000 REST APIs, and then you can see that the server is a server. 0:17:06.460000 --> 0:17:09.140000 And then some network devices do. 0:17:09.140000 --> 0:17:13.120000 Then I would send an HTTP get to that device saying, get me your routing 0:17:13.120000 --> 0:17:16.160000 table, get me your interface statistics. 0:17:16.160000 --> 0:17:21.060000 Now, as of now when we're doing this recording here, in context of software 0:17:21.060000 --> 0:17:26.560000 defined networking, REST APIs are typically not used in the southbound 0:17:26.560000 --> 0:17:30.520000 direction. Remember, the controllers right here, applications are right 0:17:30.520000 --> 0:17:33.660000 here, networking devices are down in the middle. 0:17:33.660000 --> 0:17:37.940000 So a northbound API is from the controller to the application. 0:17:37.940000 --> 0:17:40.680000 However, the application is utilizing the controller. 0:17:40.680000 --> 0:17:43.040000 That's a northbound API. 0:17:43.040000 --> 0:17:48.180000 A southbound API is from the controller down to the networking device. 0:17:48.180000 --> 0:17:53.120000 Now, REST APIs can be used in the southbound direction, but not a lot 0:17:53.120000 --> 0:17:58.000000 of networking divorces, not a lot of networking devices. 0:17:58.000000 --> 0:17:59.800000 Mayively support REST APIs. 0:17:59.800000 --> 0:18:03.360000 Normally you would find them up here in the northbound direction. 0:18:03.360000 --> 0:18:06.940000 So if an application wants to communicate with a controller, and the application 0:18:06.940000 --> 0:18:11.440000 says, hey, controller, talk to the network for me, and tell me what VLANs 0:18:11.440000 --> 0:18:13.020000 exist on the switch. 0:18:13.020000 --> 0:18:16.040000 Talk to the network for me and program this route for me. 0:18:16.040000 --> 0:18:19.100000 The REST API would be used between the application and the controller 0:18:19.100000 --> 0:18:25.480000 to do that. And REST APIs, because it's all based on HTTP, utilize standard 0:18:25.480000 --> 0:18:31.860000 HTTP verbs. That's just another way of saying the same HTTP actions that 0:18:31.860000 --> 0:18:36.000000 you're familiar with, like get, put, post, and delete. 0:18:36.000000 --> 0:18:40.120000 Now, for an API to be considered RESTful, remember how I talked about 0:18:40.120000 --> 0:18:43.860000 REST with an architecture, like, hey, I'm going to give you sort of the 0:18:43.860000 --> 0:18:51.040000 generic behaviors of an API, and if something is built, if an API is built 0:18:51.040000 --> 0:18:55.840000 to follow these behaviors, then we can safely call it REST. 0:18:55.840000 --> 0:18:57.820000 Well, that's what we're going to talk about next. 0:18:57.820000 --> 0:19:01.500000 So a REST API number one has to operate across an IP network. 0:19:01.500000 --> 0:19:05.200000 It's not designed to operate within your laptop to exchange data from 0:19:05.200000 --> 0:19:08.080000 one application to another within your hard drive. 0:19:08.080000 --> 0:19:10.400000 That's not the purpose of a REST API. 0:19:10.400000 --> 0:19:15.860000 And REST APIs utilize HTTP, or possibly HTTPS. 0:19:15.860000 --> 0:19:21.080000 But there are also six other guiding constraints that if all of these 0:19:21.080000 --> 0:19:26.260000 are made true, the person who wrote the API can say, here it is. 0:19:26.260000 --> 0:19:28.960000 Here's a REST API I have created. 0:19:28.960000 --> 0:19:33.680000 So let's talk about those guiding constraints, those architectural constraints 0:19:33.680000 --> 0:19:38.980000 of REST APIs. So number one, in order to be characterized as a REST API, 0:19:38.980000 --> 0:19:40.920000 it must have a uniform interface. 0:19:40.920000 --> 0:19:44.880000 This means that every resource, remember, resource is just the type of 0:19:44.880000 --> 0:19:50.000000 data it's acting on, every resource the API can reach should have a consistent 0:19:50.000000 --> 0:19:53.620000 naming convention, typically URIs. 0:19:53.620000 --> 0:19:58.880000 And it should be accessible via a common approach, like an HTTP get. 0:19:58.880000 --> 0:20:04.160000 Number two, REST APIs are built to be client server models. 0:20:04.160000 --> 0:20:07.740000 Number three, they're meant to be stateless. 0:20:07.740000 --> 0:20:09.180000 What does this mean? 0:20:09.180000 --> 0:20:15.200000 What this means is that if I am the SDN controller and you are the A, 0:20:15.200000 --> 0:20:21.100000 so let's say I am the REST client, I'm the SDN controller, you are a router. 0:20:21.100000 --> 0:20:23.600000 And so you happen to be running a REST API. 0:20:23.600000 --> 0:20:27.900000 You're one of these new fancy routers that actually can support natively 0:20:27.900000 --> 0:20:30.180000 a REST API within your own code. 0:20:30.180000 --> 0:20:31.720000 Let's say you can do that. 0:20:31.720000 --> 0:20:36.020000 Okay, so I'm the API client, you are the API server because the data is 0:20:36.020000 --> 0:20:39.420000 on you. The data I'm trying to retrieve, the data I'm trying to modify 0:20:39.420000 --> 0:20:42.740000 is on you. So you are the API server. 0:20:42.740000 --> 0:20:48.840000 So statelessness means that, okay, I can ask you for something, you know, 0:20:48.840000 --> 0:20:53.080000 HTTP get your routing table, your interface statistics. 0:20:53.080000 --> 0:20:54.800000 You will serve up that information. 0:20:54.800000 --> 0:20:57.060000 You'll give it back to me. 0:20:57.060000 --> 0:20:59.380000 But then you forget about me. 0:20:59.380000 --> 0:21:03.200000 Okay, you know, one half of a second later, you forget I even made that 0:21:03.200000 --> 0:21:07.920000 request. So you're not keeping track of the requests and responses and 0:21:07.920000 --> 0:21:09.540000 stuff that's going on between us. 0:21:09.540000 --> 0:21:10.820000 It's like a one and done. 0:21:10.820000 --> 0:21:14.140000 I ask you for something, I ask you to do something, you do it, you give 0:21:14.140000 --> 0:21:15.560000 it, and then it's over. 0:21:15.560000 --> 0:21:17.460000 You totally forget that it even happened. 0:21:17.460000 --> 0:21:20.160000 So that's what we mean by stateless. 0:21:20.160000 --> 0:21:26.460000 The REST server is not keeping a state information about all the clients 0:21:26.460000 --> 0:21:29.580000 that have talked to it and what they've done so far. 0:21:29.580000 --> 0:21:33.820000 That would be state full, this is stateless. 0:21:33.820000 --> 0:21:38.760000 Another architectural constraint is cacheable. 0:21:38.760000 --> 0:21:45.360000 Now what this means in simple terms is that the resources may or may not 0:21:45.360000 --> 0:21:46.840000 be cacheable, it's optional. 0:21:46.840000 --> 0:21:49.800000 On either the client or the server side. 0:21:49.800000 --> 0:21:54.200000 But if they are, the resource must declare itself as cacheable. 0:21:54.200000 --> 0:21:58.000000 This isn't really used a whole lot in the world of networking and software 0:21:58.000000 --> 0:21:59.380000 defined networking. 0:21:59.380000 --> 0:22:04.000000 Remember that a lot of these APIs were originally written, not really 0:22:04.000000 --> 0:22:10.300000 to talk to networking devices, but to communicate with servers for applications 0:22:10.300000 --> 0:22:14.760000 within servers like server A, talking to server B, or maybe we're creating 0:22:14.760000 --> 0:22:16.200000 a virtual server or something. 0:22:16.200000 --> 0:22:20.360000 So some of these terms like cache, cache ability here is really meant 0:22:20.360000 --> 0:22:25.640000 when the API is dealing with server applications, not so much with a networking 0:22:25.640000 --> 0:22:33.240000 device. Fifth architectural constraint is a, it's a layered system. 0:22:33.240000 --> 0:22:37.460000 In other words, REST allows you to use a layered system architecture where 0:22:37.460000 --> 0:22:42.640000 possibly you could deploy the API on server A, maybe store the data on 0:22:42.640000 --> 0:22:46.480000 server B, and authenticate the request in server C. 0:22:46.480000 --> 0:22:48.780000 So that's possible. 0:22:48.780000 --> 0:22:51.920000 And code on demand, what does this mean? 0:22:51.920000 --> 0:22:57.360000 That means that most of the time, the API server will be sending data 0:22:57.360000 --> 0:23:02.160000 back to the API client is like just the static representation of a resource 0:23:02.160000 --> 0:23:05.160000 in the form of XML or JSON data. 0:23:05.160000 --> 0:23:07.960000 Say, hey, here's the interface statistics you wanted. 0:23:07.960000 --> 0:23:12.720000 Here's my routing table right now, snapshot of it that you wanted to get. 0:23:12.720000 --> 0:23:17.400000 But what this says is that REST APIs could optionally be used to actually 0:23:17.400000 --> 0:23:21.540000 return executable code to support a part of your application. 0:23:21.540000 --> 0:23:27.560000 For example, an API client could call the API server to actually get a 0:23:27.560000 --> 0:23:31.080000 user interface widget that's rendering code or something like that. 0:23:31.080000 --> 0:23:32.160000 That's permitted. 0:23:32.160000 --> 0:23:34.800000 If you're concerned about more of this stuff, you want to learn more, 0:23:34.800000 --> 0:23:37.400000 here's a great website that you can go into it. 0:23:37.400000 --> 0:23:46.060000 Now, we've already talked about how REST -based APIs utilize HTTP as their 0:23:46.060000 --> 0:23:50.480000 transport mechanism, and that it uses HTTP verbs. 0:23:50.480000 --> 0:23:57.080000 Well, HTTP verbs also map up to something called CRUD. 0:23:57.080000 --> 0:24:01.920000 So if you ever were a software developer, or you know someone who's a 0:24:01.920000 --> 0:24:05.700000 software developer, and what they specialize in is databases. 0:24:05.700000 --> 0:24:10.640000 Writing code, writing software to build databases, modify databases, well 0:24:10.640000 --> 0:24:15.800000 then the way the APIs deal with databases uses something called a CRUD 0:24:15.800000 --> 0:24:19.840000 model, which is create, read, update, and delete. 0:24:19.840000 --> 0:24:24.400000 These are all things you can do on a database and on items in a database. 0:24:24.400000 --> 0:24:27.620000 Well, HTTP verbs sort of map over to that. 0:24:27.620000 --> 0:24:30.820000 So a lot of times people will go back and forth and they'll say, oh, my 0:24:30.820000 --> 0:24:33.240000 REST API uses the CRUD model. 0:24:33.240000 --> 0:24:36.800000 Or my REST API utilizes HTTP verbs. 0:24:36.800000 --> 0:24:40.120000 In the context of a REST API, they're pretty much the same. 0:24:40.120000 --> 0:24:44.220000 You can see here in this chart the HTTP verbs on the left and how they 0:24:44.220000 --> 0:24:55.960000 map quite nicely to the CRUD actions on the right. 0:24:55.960000 --> 0:24:59.460000 Okay, so as far as a REST API is concerned, there has to be some sort 0:24:59.460000 --> 0:25:04.800000 of standard encoding required for objects and resources. 0:25:04.800000 --> 0:25:11.300000 In other words, if I'm creating an API, let's say I've created a software 0:25:11.300000 --> 0:25:17.160000 -defined controller, an SDN controller, and I want to create an API that 0:25:17.160000 --> 0:25:20.540000 runs in this controller, that runs in the CPU of this controller, that 0:25:20.540000 --> 0:25:24.060000 application developers out there, they can create their own applications, 0:25:24.060000 --> 0:25:28.460000 whatever their application does, network automation, network programming, 0:25:28.460000 --> 0:25:30.600000 maybe some sort of network monitoring tool. 0:25:30.600000 --> 0:25:33.700000 They're free to create their applications, and I want to be able to tell 0:25:33.700000 --> 0:25:39.560000 them, hey, your application can talk to my controller using a REST API. 0:25:39.560000 --> 0:25:42.480000 Well, part of what I have to do, remember we said that a REST API has 0:25:42.480000 --> 0:25:44.480000 to have a uniform interface? 0:25:44.480000 --> 0:25:48.620000 That means that if I tell a software developer, you can communicate with 0:25:48.620000 --> 0:25:54.460000 my controller via a REST API, I also have to tell them two things. 0:25:54.460000 --> 0:25:59.760000 Number one, I have to say the exact format of the HTTP verb. 0:25:59.760000 --> 0:26:04.460000 For example, if you want to send an HTTP get to me, what does the body 0:26:04.460000 --> 0:26:08.920000 of that get have to look like? 0:26:08.920000 --> 0:26:13.440000 It has to look like a URI, a uniform resource identifier. 0:26:13.440000 --> 0:26:16.520000 You have to basically look like a website, something slash, something 0:26:16.520000 --> 0:26:20.920000 slash, something that drills down into the specifics of the resource you're 0:26:20.920000 --> 0:26:22.940000 looking for. Well, I have to tell you what that is. 0:26:22.940000 --> 0:26:26.600000 I have to tell you, here's all the resources you can get, or the resources 0:26:26.600000 --> 0:26:30.600000 you can modify, or even the resources you can delete, and here's the specific 0:26:30.600000 --> 0:26:35.640000 string, here's the specific URI that you need to send to me if you want 0:26:35.640000 --> 0:26:36.640000 to act on that resource. 0:26:36.640000 --> 0:26:40.160000 So I need to make that very clear and consistent. 0:26:40.160000 --> 0:26:45.240000 Now secondly, let's say that you ask me, let's say that you are the application, 0:26:45.240000 --> 0:26:51.820000 I am the SDN controller, and you send me an HTTP get in the REST API that 0:26:51.820000 --> 0:26:57.280000 says, hey, Keith, or controller, get me the routing table from router 0:26:57.280000 --> 0:26:59.920000 number one, that you control, Keith. 0:26:59.920000 --> 0:27:02.940000 I say, okay, that URI is very clear. 0:27:02.940000 --> 0:27:05.220000 I can see exactly the machine identifier. 0:27:05.220000 --> 0:27:06.400000 He wants the routing table. 0:27:06.400000 --> 0:27:08.520000 It's a get. I know what he wants. 0:27:08.520000 --> 0:27:13.540000 So now my controller somehow I obtain access to that routing table. 0:27:13.540000 --> 0:27:15.660000 Now, here's the question. 0:27:15.660000 --> 0:27:19.880000 When I send that data back to you, what format is it going to take? 0:27:19.880000 --> 0:27:23.600000 Am I just going to send you a string of binary digits, of hexadecimal 0:27:23.600000 --> 0:27:28.160000 digits? You and I have to agree on what the encoding is of that routing 0:27:28.160000 --> 0:27:31.980000 table so you can make heads or tails of it when you receive it. 0:27:31.980000 --> 0:27:36.560000 If I didn't tell you in advance what sort of data encoding mechanism I 0:27:36.560000 --> 0:27:41.200000 was using, how would you know how to interpret what I sent you? 0:27:41.200000 --> 0:27:47.100000 So REST APIs in order to encode the data strive for a few things, for 0:27:47.100000 --> 0:27:48.100000 consistency purposes. 0:27:48.100000 --> 0:27:53.280000 Number one, quick serialization and deserialization of objects, which 0:27:53.280000 --> 0:27:56.560000 means that whatever I send you, I have to be able to get it onto the wire 0:27:56.560000 --> 0:27:58.380000 really quickly and let it go. 0:27:58.380000 --> 0:28:01.020000 You have to be able to pick it up off the wire real quickly and then read 0:28:01.020000 --> 0:28:04.640000 it. It should be compact, right? 0:28:04.640000 --> 0:28:07.520000 If I'm sending you something that the data is only like eight bytes long, 0:28:07.520000 --> 0:28:11.000000 it would kind of defeat the purpose if I put in front of that like 200 0:28:11.000000 --> 0:28:12.360000 bytes of additional headers. 0:28:12.360000 --> 0:28:14.240000 So it should be compact. 0:28:14.240000 --> 0:28:19.320000 And I should minimize the data transfer required and offer broad language 0:28:19.320000 --> 0:28:23.280000 support. So let's bring it all down to practical reality. 0:28:23.280000 --> 0:28:28.840000 REST APIs typically take your data and encode it in one of two forms, 0:28:28.840000 --> 0:28:32.200000 in either JSON format or XML format. 0:28:32.200000 --> 0:28:36.920000 Now if you're not familiar with either JSON or XML, I would recommend 0:28:36.920000 --> 0:28:43.720000 that you research that. 0:28:43.720000 --> 0:28:47.860000 There are a lot of ways of encoding data, what data should look like so 0:28:47.860000 --> 0:28:50.560000 that you can read it and I can send it to you. 0:28:50.560000 --> 0:28:56.040000 Now let's bring this home here with REST APIs and Cisco DNA Center. 0:28:56.040000 --> 0:28:58.000000 How do the two interact? 0:28:58.000000 --> 0:29:02.820000 So Cisco DNA or Cisco has created their own special API, REST API, and 0:29:02.820000 --> 0:29:05.600000 they gave it the name of the intent API. 0:29:05.600000 --> 0:29:07.660000 So this is their REST API. 0:29:07.660000 --> 0:29:11.200000 Now they have other ones as well, but this is the big one that's running 0:29:11.200000 --> 0:29:13.700000 on Cisco DNA Center so that applications are running on Cisco DNA Center. 0:29:13.700000 --> 0:29:18.000000 Can talk to DNA Center and get information back or send messages telling 0:29:18.000000 --> 0:29:20.340000 DNA Center, hey, control the network. 0:29:20.340000 --> 0:29:21.760000 Here's what I want you to do. 0:29:21.760000 --> 0:29:27.260000 So they're going to use a REST API between them called the intent API. 0:29:27.260000 --> 0:29:30.120000 And developers, you know, if you're a software developer, they can use 0:29:30.120000 --> 0:29:34.700000 this API to create custom applications that interact with DNA Center. 0:29:34.700000 --> 0:29:38.360000 And like I mentioned, this would be considered a northbound API. 0:29:38.360000 --> 0:29:43.100000 Anytime a controller is talking to an application, the API that talks 0:29:43.100000 --> 0:29:46.820000 between them is considered a northbound controller. 0:29:46.820000 --> 0:29:48.500000 Here's some more information about it. 0:29:48.500000 --> 0:29:49.920000 I just want to show you something as well. 0:29:49.920000 --> 0:29:52.600000 Let me make this full screen here. 0:29:52.600000 --> 0:29:57.940000 If you go to, let's see here. 0:29:57.940000 --> 0:30:00.960000 Let me get out of this for just a moment. 0:30:00.960000 --> 0:30:07.300000 All right, so if you go to this website right here, this will allow you 0:30:07.300000 --> 0:30:09.760000 to see what I'm about to show you. 0:30:09.760000 --> 0:30:12.300000 So you could pause the video at this point and just type that website 0:30:12.300000 --> 0:30:15.620000 into your browser if you wish. 0:30:15.620000 --> 0:30:21.940000 But this will get you into the details of the Cisco intent REST API. 0:30:21.940000 --> 0:30:25.620000 And here we can see, so what you see on the left are all the different 0:30:25.620000 --> 0:30:31.300000 URIs and whether they're meant to be used in an HTTP GET request, like 0:30:31.300000 --> 0:30:38.420000 to get information, or an HTTP post or put, which is used to program information 0:30:38.420000 --> 0:30:41.620000 or update or change information or delete. 0:30:41.620000 --> 0:30:47.100000 So on the left you see the HTTP verbs, then you see the URI specifically, 0:30:47.100000 --> 0:30:50.740000 and then you see on the right what that URIs meant to do. 0:30:50.740000 --> 0:30:53.840000 Now if you're a network engineer like me, a lot of stuff is not going 0:30:53.840000 --> 0:30:57.100000 to make any sense, but if you scroll down a little bit, there's a section 0:30:57.100000 --> 0:31:00.760000 of this page that does make sense. 0:31:00.760000 --> 0:31:04.960000 If you go down to, where is it? 0:31:04.960000 --> 0:31:13.340000 Right here, so this section of the API is meant for managing network devices. 0:31:13.340000 --> 0:31:15.960000 And we're all familiar with how to use iOS commands to manage network 0:31:15.960000 --> 0:31:22.580000 devices, so what type of REST API command could be sent from some sort 0:31:22.580000 --> 0:31:28.100000 of application running on a server over to the SDN controller to tell 0:31:28.100000 --> 0:31:30.900000 the controller to manage a network device? 0:31:30.900000 --> 0:31:33.320000 Well, there's all sorts of interesting stuff here. 0:31:33.320000 --> 0:31:36.960000 So for example, I'll look at this one. 0:31:36.960000 --> 0:31:44.860000 This URI here, which is a GET, can be used to obtain or get device interface 0:31:44.860000 --> 0:31:49.120000 count. So you'd have to know the device ID, so you'd have to use another 0:31:49.120000 --> 0:31:52.900000 URI in advance of this, or before this, to get the various device IDs. 0:31:52.900000 --> 0:31:56.660000 And then once you plug the device ID in there for like a router switch, 0:31:56.660000 --> 0:32:01.420000 using this format of the URI, you would get the interfaces that are on 0:32:01.420000 --> 0:32:06.320000 that device. You can see here, we saw this one already. 0:32:06.320000 --> 0:32:11.180000 Here's the URI you would use to obtain the VLANs to get the VLANs from 0:32:11.180000 --> 0:32:12.700000 a particular switch. 0:32:12.700000 --> 0:32:17.480000 So you can see, so as a network engineer, why would you say Keith, I'm 0:32:17.480000 --> 0:32:21.260000 not going to write code, I'm not going to create a URI from scratch. 0:32:21.260000 --> 0:32:23.120000 Why do I care about this stuff? 0:32:23.120000 --> 0:32:28.280000 Well, because if you're getting into the world of SDN, you might have 0:32:28.280000 --> 0:32:33.020000 all these grandiose thoughts about what a controller can do. 0:32:33.020000 --> 0:32:36.180000 You might have all sorts of thoughts about, oh, I can use a controller 0:32:36.180000 --> 0:32:41.860000 to modify my BGP or create OSPF or to strip off an access list or something. 0:32:41.860000 --> 0:32:44.240000 Well, maybe, maybe not. 0:32:44.240000 --> 0:32:47.880000 First thing you need to do is you need to go into the API like this and 0:32:47.880000 --> 0:32:50.560000 take a look at what does this API support. 0:32:50.560000 --> 0:32:54.840000 If the API supports a GET or a PUT or a POST command that does what you're 0:32:54.840000 --> 0:32:57.480000 looking for, great, you can use that. 0:32:57.480000 --> 0:32:59.720000 But you could scroll through here and guess what? 0:32:59.720000 --> 0:33:04.160000 If none of these things mention BGP as an example, well, then that means 0:33:04.160000 --> 0:33:08.200000 that your application is not going to be able to do anything BGP related 0:33:08.200000 --> 0:33:13.600000 with the controller, because the API doesn't support any URI that has 0:33:13.600000 --> 0:33:15.280000 anything to do with BGP. 0:33:15.280000 --> 0:33:18.500000 So you might not need to structure or create these yourself. 0:33:18.500000 --> 0:33:22.080000 You might not have to write the code, but being able to look through these 0:33:22.080000 --> 0:33:25.140000 URIs and see what is supported, what's not. 0:33:25.140000 --> 0:33:26.900000 Was this API allow me to do? 0:33:26.900000 --> 0:33:28.760000 What does it not allow me to do? 0:33:28.760000 --> 0:33:32.160000 That's very useful if you're going to implement an SDN environment, especially 0:33:32.160000 --> 0:33:35.800000 when choosing this controller as opposed to this other controller by another 0:33:35.800000 --> 0:33:37.660000 vendor over here. 0:33:37.660000 --> 0:33:41.140000 And just to finish it up here in this video, I just want to show you where 0:33:41.140000 --> 0:33:45.560000 these APIs sort of fit in the scheme of DNA center. 0:33:45.560000 --> 0:33:52.080000 You can see in this particular case that the REST APIs are used for, for 0:33:52.080000 --> 0:33:54.660000 example, Cisco ICE to talk to DNA center. 0:33:54.660000 --> 0:33:58.140000 That uses a REST API for the network data platform. 0:33:58.140000 --> 0:34:02.020000 That's the part that collects all the statistics and information about 0:34:02.020000 --> 0:34:06.420000 the network. That communicates to DNA center via the REST API. 0:34:06.420000 --> 0:34:11.980000 So the ones down here in black, those are your southbound APIs that communicate 0:34:11.980000 --> 0:34:13.760000 with your network devices. 0:34:13.760000 --> 0:34:18.000000 The ones in red, those would be considered your northbound APIs, and that 0:34:18.000000 --> 0:34:21.620000 is where REST takes place. 0:34:21.620000 --> 0:34:25.980000 So that concludes this particular presentation on an introduction to REST 0:34:25.980000 --> 0:34:28.480000 APIs. I hope you found it useful.