WEBVTT 0:00:03.080000 --> 0:00:06.460000 Hello and welcome this video, which we're going to be doing a refresher 0:00:06.460000 --> 0:00:11.220000 for our CCN Bootcamp of REST-based APIs. 0:00:11.220000 --> 0:00:17.160000 This slide here, just a review, we've already talked about this in the 0:00:17.160000 --> 0:00:22.600000 previous video, that APIs come as either Northbound or Southbound. 0:00:22.600000 --> 0:00:27.860000 Northbound APIs connect applications to controllers, Southbound APIs allow 0:00:27.860000 --> 0:00:30.240000 controllers to connect to your networking devices. 0:00:30.240000 --> 0:00:35.600000 Both types of APIs rely on the Internet protocol to transfer IP packets 0:00:35.600000 --> 0:00:37.480000 back and forth between devices. 0:00:37.480000 --> 0:00:43.900000 Frequently, behind the IP protocol, we have TCP followed by HTTP, and 0:00:43.900000 --> 0:00:48.300000 then HTTP will actually carry the commands or the queries that we need 0:00:48.300000 --> 0:00:53.760000 to send. We already talked about APIs using client server models, so we're 0:00:53.760000 --> 0:00:57.700000 not going to cover that again. 0:00:57.700000 --> 0:01:10.260000 Okay, so of the types of APIs that utilize IP to send data back and forth 0:01:10.260000 --> 0:01:16.900000 between two devices across an IP network, the most common flavor of that 0:01:16.900000 --> 0:01:21.520000 is a web-based API, which means it's using HTTP. 0:01:21.520000 --> 0:01:23.620000 It's using HTTPS. 0:01:23.620000 --> 0:01:27.860000 There are other types of APIs that also use IP to communicate, but they 0:01:27.860000 --> 0:01:29.780000 are less common. 0:01:29.780000 --> 0:01:37.520000 So when you're using a web-based API, the way the data is asked for, the 0:01:37.520000 --> 0:01:42.640000 way the data comes back is referenced in the API by a universal resource 0:01:42.640000 --> 0:01:50.880000 locator, or a uniform resource locator, a URI or a URL, so it looks very 0:01:50.880000 --> 0:01:54.300000 similar to a URL in your browser. 0:01:54.300000 --> 0:01:59.100000 Like for example, when you go to www .iony.com forward slash schedules 0:01:59.100000 --> 0:02:02.960000 forward slash whatever, that's your common URL, right? 0:02:02.960000 --> 0:02:12.060000 So we are used to URLs being used to reference a website or a sub-website, 0:02:12.060000 --> 0:02:18.200000 but with a web-based API, something like that that looks just like a URL 0:02:18.200000 --> 0:02:24.000000 can actually reference an object like, I want to read your routing table. 0:02:24.000000 --> 0:02:26.420000 I want to read your interface statistics. 0:02:26.420000 --> 0:02:28.940000 I want a program and access list. 0:02:28.940000 --> 0:02:32.960000 All that stuff is referenced by URIs. 0:02:32.960000 --> 0:02:40.780000 For example, right here, here's a URI where the REST API is doing it, 0:02:40.780000 --> 0:02:48.580000 and it's allowing the DNA center to actually query a device and find out 0:02:48.580000 --> 0:02:50.880000 what VLANs are on that device. 0:02:50.880000 --> 0:02:55.720000 It looks very similar to a URL. 0:02:55.720000 --> 0:03:03.000000 So web service APIs, by the use of these URIs, can add new data so they 0:03:03.000000 --> 0:03:08.040000 can create things, they can create an access list, they can possibly populate 0:03:08.040000 --> 0:03:12.560000 a route in the routing table, and they can read data, they can ask for 0:03:12.560000 --> 0:03:15.900000 data, or they can modify existing data. 0:03:15.900000 --> 0:03:19.780000 They'll change an IP address from one thing to another thing, or they 0:03:19.780000 --> 0:03:23.340000 can completely destroy or erase data. 0:03:23.340000 --> 0:03:28.220000 So notice, if we put these letters together, create, read, update, and 0:03:28.220000 --> 0:03:31.700000 delete, they spell CRUD. 0:03:31.700000 --> 0:03:36.920000 And for people who develop web-based APIs and use web-based APIs a lot, 0:03:36.920000 --> 0:03:39.780000 that acronym CRUD is very familiar. 0:03:39.780000 --> 0:03:43.400000 That is basically an acronym that can describe all the things that a web 0:03:43.400000 --> 0:03:48.280000 -based API can do, create, read, update, and delete. 0:03:48.280000 --> 0:03:51.080000 Now, what does this have to do with REST? 0:03:51.080000 --> 0:03:56.860000 So REST stands for the Representational State Transfer, and I'll let you 0:03:56.860000 --> 0:04:00.020000 read this right here. 0:04:00.020000 --> 0:04:02.700000 So REST APIs act on resources. 0:04:02.700000 --> 0:04:11.360000 So in REST terminology, a resource is anything that REST can apply CRUD 0:04:11.360000 --> 0:04:13.780000 to, which sounds kind of weird. 0:04:13.780000 --> 0:04:18.700000 But if you think about it, if I'm using a REST API to create something, 0:04:18.700000 --> 0:04:20.700000 I'm creating a resource. 0:04:20.700000 --> 0:04:25.000000 If I'm using it to delete something, like delete an IP address, that IP 0:04:25.000000 --> 0:04:27.860000 address would be considered a resource. 0:04:27.860000 --> 0:04:34.740000 So all the things that REST can act upon are created resources. 0:04:34.740000 --> 0:04:42.780000 So REST APIs, in order to do what they do, utilize standard HTTP verbs. 0:04:42.780000 --> 0:04:45.920000 You've probably seen, if you've ever learned anything about HTTP before, 0:04:45.920000 --> 0:04:47.920000 you've probably seen these before. 0:04:47.920000 --> 0:04:50.640000 Get, put, post, and delete. 0:04:50.640000 --> 0:04:57.300000 So in API land, an API terminology, we're familiar with CRUD, create, 0:04:57.300000 --> 0:04:58.600000 read, update, and delete. 0:04:58.600000 --> 0:05:04.840000 Those exact same things can map over to these HTTP verbs, and we'll see 0:05:04.840000 --> 0:05:06.620000 that in just a second. 0:05:06.620000 --> 0:05:14.000000 So if somebody's creating a REST-based API, they say, okay, here's what 0:05:14.000000 --> 0:05:19.120000 I want to do. I want to create an API so that my controller can speak 0:05:19.120000 --> 0:05:22.720000 to my router, or speak to my switch. 0:05:22.720000 --> 0:05:25.240000 So I know it's got to be IP-based, okay? 0:05:25.240000 --> 0:05:29.640000 And it's probably going to be a web API, because it's going to use HTTP, 0:05:29.640000 --> 0:05:31.580000 all right? Great. 0:05:31.580000 --> 0:05:33.340000 And I want to be a REST API. 0:05:33.340000 --> 0:05:36.080000 I want to actually be categorized as that. 0:05:36.080000 --> 0:05:40.680000 Well, in order for something to be a REST API, it has to actually follow 0:05:40.680000 --> 0:05:44.720000 these, what's called architectural constraints. 0:05:44.720000 --> 0:05:48.380000 What I would recommend, I don't have it in here, because this is really 0:05:48.380000 --> 0:05:51.520000 just a review and a refresher of what we've been talking about. 0:05:51.520000 --> 0:05:57.900000 But there are about five things that a REST API needs to be able to accomplish 0:05:57.900000 --> 0:06:03.840000 in order to actually be classified or categorized as a REST API. 0:06:03.840000 --> 0:06:12.680000 For example, when a REST API reaches into something with an API call to 0:06:12.680000 --> 0:06:17.520000 a router or switch, and then performs some operation, at that point, when 0:06:17.520000 --> 0:06:22.580000 that's done, the REST API does not keep a record or any state information 0:06:22.580000 --> 0:06:24.480000 about, this is what I did. 0:06:24.480000 --> 0:06:27.660000 Over the last 10 minutes, I've done this, this, this, and this. 0:06:27.660000 --> 0:06:32.440000 It's stateless. That's one of the characteristics of a REST-based API, 0:06:32.440000 --> 0:06:37.140000 is that whatever it's doing, whatever it's asking for, whatever operation 0:06:37.140000 --> 0:06:42.220000 it's performing, has to be independent of any previous operations, because 0:06:42.220000 --> 0:06:44.900000 it doesn't remember the previous operations. 0:06:44.900000 --> 0:06:47.760000 REST is a stateless API. 0:06:47.760000 --> 0:06:52.400000 That's one of about five different characteristics of REST-based APIs. 0:06:52.400000 --> 0:06:56.360000 And I would encourage you to just look up what the other remaining characteristics 0:06:56.360000 --> 0:07:02.020000 are in my network automation and programmability course, or just googling 0:07:02.020000 --> 0:07:08.440000 REST APIs. As I previously mentioned, REST APIs communicate using HTTP 0:07:08.440000 --> 0:07:11.440000 as a transport protocol. 0:07:11.440000 --> 0:07:17.540000 They use HTTP verbs, which pretty much map to CRUD that we've been looking 0:07:17.540000 --> 0:07:23.700000 at. So for certification purposes, you do want to know which HTTP verb 0:07:23.700000 --> 0:07:27.420000 matches up with which CRUD database command. 0:07:27.420000 --> 0:07:30.380000 You should know that POST is the same as CREATE. 0:07:30.380000 --> 0:07:34.080000 GET is the same as READ, and so on and so forth. 0:07:34.080000 --> 0:07:37.720000 So you'll definitely want to memorize this chart. 0:07:37.720000 --> 0:07:46.480000 The last thing I want to say about REST APIs is that we have to use some 0:07:46.480000 --> 0:07:48.160000 sort of standard encoding. 0:07:48.160000 --> 0:07:54.300000 In other words, I can't create a REST API and say that the things I'm 0:07:54.300000 --> 0:07:58.920000 asking for and the commands I'm sending are different, that they're structured 0:07:58.920000 --> 0:08:01.700000 differently. They have different minimum lengths. 0:08:01.700000 --> 0:08:05.660000 They use commas or semicolons different than what you do in your REST 0:08:05.660000 --> 0:08:10.480000 API. No, the REST API has to use a standard encoding to do what's going 0:08:10.480000 --> 0:08:16.380000 to do. So REST APIs strive for these are the goals, the objectives of 0:08:16.380000 --> 0:08:21.860000 REST API. Quick serialization and deserialization of objects. 0:08:21.860000 --> 0:08:27.540000 Basically what that means is when I'm asking for something, what I'm asking 0:08:27.540000 --> 0:08:31.500000 for should be able to very quickly be retrieved and sent to me. 0:08:31.500000 --> 0:08:35.020000 It shouldn't take a long time to get what I'm asking for, or find programming 0:08:35.020000 --> 0:08:37.840000 something. It should be able to happen very quickly. 0:08:37.840000 --> 0:08:40.720000 Quick serialization and deserialization of objects. 0:08:40.720000 --> 0:08:43.880000 A compact format for accessing data. 0:08:43.880000 --> 0:08:49.500000 Minimize the data transfer required and offer broad language support. 0:08:49.500000 --> 0:08:56.480000 Now I mentioned that REST APIs act on resources. 0:08:56.480000 --> 0:08:59.260000 So whatever you're trying to read from that router switch, whatever you're 0:08:59.260000 --> 0:09:03.020000 trying to configure or program in that router switch is considered a resource. 0:09:03.020000 --> 0:09:14.400000 All right. So the next thing is that resource, how do we describe an interface 0:09:14.400000 --> 0:09:15.820000 and its IP address? 0:09:15.820000 --> 0:09:18.940000 How do we describe a route in its subnet mask? 0:09:18.940000 --> 0:09:21.380000 Do we use uppercase letters, lowercase letters? 0:09:21.380000 --> 0:09:24.340000 Do we differentiate those things with a colon in the middle, a common 0:09:24.340000 --> 0:09:28.600000 in the middle? How do I, if I'm getting a list of stuff back, like a list 0:09:28.600000 --> 0:09:31.940000 of several different routes, how do I differentiate one route from the 0:09:31.940000 --> 0:09:37.100000 next? Well, we have to use a standard encoding method that can recognize 0:09:37.100000 --> 0:09:39.640000 all that. So it's not variable. 0:09:39.640000 --> 0:09:45.780000 Well, REST APIs use standard encoding messages of JSON or XML in order 0:09:45.780000 --> 0:09:48.340000 to accomplish their mission. 0:09:48.340000 --> 0:09:51.260000 And coming up here, we're going to look at some quick highlights and differences 0:09:51.260000 --> 0:09:54.320000 between JSON and XML.