1 00:00:07,000 --> 00:00:09,440 - As you learn from the previous lessons, you know, 2 00:00:09,440 --> 00:00:11,594 APIs are used everywhere these days. 3 00:00:11,594 --> 00:00:13,826 A large number of modern applications 4 00:00:13,826 --> 00:00:15,617 use some type of APIs 5 00:00:15,617 --> 00:00:19,820 because they can make access available to other systems, 6 00:00:19,820 --> 00:00:22,570 and to interact with other applications. 7 00:00:22,570 --> 00:00:27,570 You saw them at least, we briefed them in other lessons 8 00:00:27,630 --> 00:00:32,230 whenever we talked about DNA center, we talked about ACI, 9 00:00:32,230 --> 00:00:37,230 and many other technologies that take advantage of APIs 10 00:00:37,230 --> 00:00:41,490 for provisioning and to interact with network devices 11 00:00:41,490 --> 00:00:42,593 and applications as well. 12 00:00:42,593 --> 00:00:46,310 Now there are a few methods or technologies 13 00:00:46,310 --> 00:00:48,550 behind modern APIs. 14 00:00:48,550 --> 00:00:50,420 The first one is actually a standards based 15 00:00:50,420 --> 00:00:52,480 Web Access Control protocol 16 00:00:52,480 --> 00:00:55,010 that was originally developed by Microsoft. 17 00:00:55,010 --> 00:00:56,010 And it was actually used 18 00:00:56,010 --> 00:00:58,434 by numerous legacy applications for many years. 19 00:00:58,434 --> 00:01:03,434 And this is SOAP or the Simple Object Access Protocol. 20 00:01:05,114 --> 00:01:07,980 Now SOAP is exclusively related to XML. 21 00:01:07,980 --> 00:01:11,648 So it actually uses XML to provide API services. 22 00:01:11,648 --> 00:01:15,050 And the XML basic specifications are actually governed 23 00:01:15,050 --> 00:01:18,761 by the XML Schema definitions or excess D documents. 24 00:01:18,761 --> 00:01:22,061 And SOAP was originally created to replace older solutions 25 00:01:22,061 --> 00:01:26,521 like the Distributor Component Object Model or DCOM 26 00:01:26,521 --> 00:01:30,510 and also the Common Object Request Broker Architecture 27 00:01:30,510 --> 00:01:31,710 CORBA, right? 28 00:01:31,710 --> 00:01:34,480 You can find a lot of information about the latest soap 29 00:01:34,480 --> 00:01:37,860 specification at the W3 website that I'm actually 30 00:01:37,860 --> 00:01:39,170 sharing in the screen. 31 00:01:39,170 --> 00:01:43,410 However, there are many different APIs in modern times. 32 00:01:43,410 --> 00:01:47,540 They use restful APIs and restful or REST, stands 33 00:01:47,540 --> 00:01:50,018 for Representational State Transfer. 34 00:01:50,018 --> 00:01:53,190 And you know, many folks actually refer to them 35 00:01:53,190 --> 00:01:58,190 as restful APIs, but a REST API, a standard is a little bit 36 00:01:58,628 --> 00:02:03,628 easier than SOAP and it actually uses JSON instead of XML. 37 00:02:04,430 --> 00:02:06,940 And it also uses standards like SWAGGER 38 00:02:06,940 --> 00:02:10,674 and the open API specification for the ease 39 00:02:10,674 --> 00:02:13,770 of documentation, actually, to help with adoption. 40 00:02:13,770 --> 00:02:16,270 As a matter of fact, by using things 41 00:02:16,270 --> 00:02:19,510 like the SWAGGER editor, you can actually export 42 00:02:19,510 --> 00:02:23,061 or automatically create even code to interact 43 00:02:23,061 --> 00:02:26,240 with the underlying API that is being documented. 44 00:02:26,240 --> 00:02:29,750 So because of that, and many other benefits 45 00:02:29,750 --> 00:02:33,220 restful APIs are actually used nowadays, pretty 46 00:02:33,220 --> 00:02:34,053 much everywhere. 47 00:02:34,053 --> 00:02:36,590 And a lot of the Cisco devices that you're gonna 48 00:02:36,590 --> 00:02:41,590 be learning later in the course, they use restful APIs. 49 00:02:41,920 --> 00:02:46,090 Now there's another query language for APIs that provides 50 00:02:46,090 --> 00:02:49,550 many developer tools and that's actually called GraphQL 51 00:02:49,550 --> 00:02:51,490 and queryable APIs. 52 00:02:51,490 --> 00:02:54,437 Now, GraphQL is now used for many mobile applications 53 00:02:54,437 --> 00:02:59,437 and online dashboards. Many languages support GraphQL. 54 00:03:00,032 --> 00:03:02,640 It's not used in networking infrastructure devices 55 00:03:02,640 --> 00:03:06,870 that often but you can actually learn more about GraphQL 56 00:03:06,870 --> 00:03:09,173 at the link that I'm sharing in the screen. 57 00:03:10,180 --> 00:03:13,740 Now, SOAP and REST share similarities over the HDP protocol. 58 00:03:13,740 --> 00:03:17,133 However, SOAP, it's a little bit more strict than 59 00:03:17,133 --> 00:03:21,410 restful APIs, and a restful APIs are considered to be a 60 00:03:21,410 --> 00:03:23,893 little bit more flexible. 61 00:03:23,893 --> 00:03:26,133 Now, in this example, I'm actually showing 62 00:03:26,133 --> 00:03:29,504 a quick interaction with the restful API 63 00:03:29,504 --> 00:03:33,790 and this is extremely simple, using just cURL. 64 00:03:33,790 --> 00:03:35,970 And basically you're actually getting back 65 00:03:35,970 --> 00:03:38,332 you know, information about, you know, 66 00:03:38,332 --> 00:03:42,840 an application that you can actually perform several tests 67 00:03:42,840 --> 00:03:46,360 for free that is called Deck of Cards API, right? 68 00:03:46,360 --> 00:03:49,070 So if you're new to APIs, as a matter of fact 69 00:03:49,070 --> 00:03:51,630 many people actually use this website to actually 70 00:03:51,630 --> 00:03:54,090 create quick Python scripts 71 00:03:54,090 --> 00:03:56,290 or just using cURL as I'm actually showing 72 00:03:56,290 --> 00:03:58,830 in the screen and actually interact with that, right? 73 00:03:58,830 --> 00:04:01,210 So the API basically, you know, 74 00:04:01,210 --> 00:04:03,570 allows you to do things like shuffling a 75 00:04:03,570 --> 00:04:05,928 a Deck of Cards for you and, and many others. 76 00:04:05,928 --> 00:04:08,960 So if you have never played with any APIs before 77 00:04:08,960 --> 00:04:11,650 this actually may be a very quick, you know, dry run. 78 00:04:11,650 --> 00:04:16,350 However, I also mentioned to you that DEVNET provides tons 79 00:04:16,350 --> 00:04:20,070 of documentation on how to actually interact with devices. 80 00:04:20,070 --> 00:04:21,510 So for the test, you actually 81 00:04:21,510 --> 00:04:25,180 at least have to interpret basic Python scripts 82 00:04:25,180 --> 00:04:28,710 or at least know the structure of, you know 83 00:04:28,710 --> 00:04:30,800 Python script and probably, you know, 84 00:04:30,800 --> 00:04:34,310 recognize that it's actually interacting with a restful API. 85 00:04:34,310 --> 00:04:38,003 For example, using requests and many other capabilities. 86 00:04:39,020 --> 00:04:42,910 Now, modern networking devices also support programmable 87 00:04:42,910 --> 00:04:47,910 capabilities, like NETCONF, RESTCONF and YANG models. 88 00:04:48,220 --> 00:04:50,290 And here I'm actually gonna provide details 89 00:04:50,290 --> 00:04:52,350 about these technologies. 90 00:04:52,350 --> 00:04:54,670 Now, YANG is an API contract language 91 00:04:54,670 --> 00:04:57,340 used in many networking devices. 92 00:04:57,340 --> 00:04:59,151 In other words, you can actually use YANG to 93 00:04:59,151 --> 00:05:02,780 write a specification for what the interface 94 00:05:02,780 --> 00:05:04,849 between a client and networking devices, 95 00:05:04,849 --> 00:05:09,390 or a server, should be on a particular topic. 96 00:05:09,390 --> 00:05:13,970 Now, YANG is also an industry wide standard, and is defined 97 00:05:13,970 --> 00:05:16,600 on RFC 6020. 98 00:05:16,600 --> 00:05:19,809 A specification written in YANG is actually often referred 99 00:05:19,809 --> 00:05:22,580 to as a YANG module. 100 00:05:22,580 --> 00:05:27,115 Now a collection or a set of YANG modules is often 101 00:05:27,115 --> 00:05:30,270 called a YANG model, right? 102 00:05:30,270 --> 00:05:33,566 So a YANG model actually typically concentrates on 103 00:05:33,566 --> 00:05:35,890 the data that a client processes using 104 00:05:35,890 --> 00:05:37,820 standardized operations. 105 00:05:37,820 --> 00:05:41,065 Now keep in mind that in NETCONF, and also 106 00:05:41,065 --> 00:05:43,135 in RESTCONF implementation, 107 00:05:43,135 --> 00:05:47,600 the YANG controller is the client and the network elements 108 00:05:47,600 --> 00:05:49,086 are actually the server. 109 00:05:49,086 --> 00:05:51,870 Now the following are a few examples 110 00:05:51,870 --> 00:05:54,820 of what a client can do using different YANG models. 111 00:05:54,820 --> 00:05:58,090 You can configure, and of course, enable writing Protocols 112 00:05:58,090 --> 00:06:00,580 or enable different features, 113 00:06:00,580 --> 00:06:02,900 in a network infrastructure device 114 00:06:02,900 --> 00:06:04,311 or receive notifications. 115 00:06:04,311 --> 00:06:07,451 You can also monitor status, invoke different actions, 116 00:06:07,451 --> 00:06:09,950 like resetting packet counters 117 00:06:09,950 --> 00:06:12,485 rebooting the system and many other, you know 118 00:06:12,485 --> 00:06:16,340 applications as well, right, or implementations. 119 00:06:16,340 --> 00:06:21,340 Now the YANG model of a device is often called Schema 120 00:06:21,750 --> 00:06:24,050 and that Schema defines the structure 121 00:06:24,050 --> 00:06:26,920 and the content of messages that are exchanged 122 00:06:26,920 --> 00:06:30,470 between the applications, and the device itself. 123 00:06:30,470 --> 00:06:32,980 Now, the cool thing is that the YANG language 124 00:06:32,980 --> 00:06:35,833 provides flexibility and extensibility that are not present 125 00:06:35,833 --> 00:06:38,175 in other model languages. 126 00:06:38,175 --> 00:06:40,505 Whenever you create a new YANG module 127 00:06:40,505 --> 00:06:43,655 you can leverage the data hierarchies defined 128 00:06:43,655 --> 00:06:44,880 in other modules. 129 00:06:44,880 --> 00:06:48,453 So that makes it a little bit more flexible and extensible. 130 00:06:50,074 --> 00:06:54,760 Now YANG is also allow or allows you to expand, you know 131 00:06:54,760 --> 00:06:57,800 on a scale in a very consistent manner as well. 132 00:06:57,800 --> 00:07:02,130 DEVNET, just like, you know, I mentioned to you, has tons 133 00:07:02,130 --> 00:07:04,540 of different videos and demonstration, but they 134 00:07:04,540 --> 00:07:07,080 actually have a video course that demonstrate how 135 00:07:07,080 --> 00:07:10,323 YANG module works at the following link. 136 00:07:11,220 --> 00:07:15,810 Now I mentioned NETCONF and NETCONF is a, it's a standard 137 00:07:15,810 --> 00:07:20,810 that is actually defined on RFC 6241 and 6242, 138 00:07:20,890 --> 00:07:24,350 and was created to overcome the challenges of the SNMP. 139 00:07:24,350 --> 00:07:27,200 So the Simple Network Management protocol. 140 00:07:27,200 --> 00:07:30,160 NETCONF has a concept of a client and a server 141 00:07:30,160 --> 00:07:32,042 and a NETCONF client typically has the role 142 00:07:32,042 --> 00:07:34,940 of a network management application, 143 00:07:34,940 --> 00:07:39,664 and the NETCON server or the NETCONF server is a managed 144 00:07:39,664 --> 00:07:43,350 network device, like a router, a switch, a firewall 145 00:07:43,350 --> 00:07:44,510 and so on. 146 00:07:44,510 --> 00:07:48,500 So you also can have intermediate systems that are 147 00:07:48,500 --> 00:07:50,044 are often called controllers. 148 00:07:50,044 --> 00:07:53,760 And that controls the particular aspects of a domain 149 00:07:53,760 --> 00:07:58,040 and controllers act as a server to its managers, and 150 00:07:58,040 --> 00:08:01,530 as a client to the networking devices, as I'm actually 151 00:08:01,530 --> 00:08:03,320 sharing in the screen. 152 00:08:03,320 --> 00:08:06,148 Now, a quick thing behind the scenes is that NETCONF was 153 00:08:06,148 --> 00:08:09,850 created before YANG; other languages were you actually use 154 00:08:09,850 --> 00:08:11,280 for NETCONF operations. 155 00:08:11,280 --> 00:08:16,280 However, nowadays YANG is the only language widely supported 156 00:08:16,290 --> 00:08:19,910 and used for NETCONF now in present time. 157 00:08:19,910 --> 00:08:22,632 now NETCONF sessions establish 158 00:08:22,632 --> 00:08:27,632 from a NETCONF client, to a server, consists of a sequence 159 00:08:27,810 --> 00:08:29,150 of messages. 160 00:08:29,150 --> 00:08:32,580 Both of the parties send a hello message. 161 00:08:32,580 --> 00:08:34,740 And then, you know, whenever they actually try to connect 162 00:08:34,740 --> 00:08:39,261 and all messages exchanges are initiated by the client 163 00:08:39,261 --> 00:08:43,210 and then the hello messages include which NETCONF 164 00:08:43,210 --> 00:08:46,710 Protocol version, the device actually support. 165 00:08:46,710 --> 00:08:50,330 Then the server also state which optional capabilities 166 00:08:50,330 --> 00:08:51,730 it also supports as well. 167 00:08:51,730 --> 00:08:55,480 So, you know, it, there's a hello messages for 168 00:08:55,480 --> 00:08:57,800 this type of negotiation. 169 00:08:57,800 --> 00:09:02,011 Now NETCONF messages are encoded in XML and it, 170 00:09:02,011 --> 00:09:05,600 of course, they're defined on the NETCONF standard. 171 00:09:05,600 --> 00:09:07,550 Now NETCOMF communication is actually done 172 00:09:07,550 --> 00:09:10,920 over secure SSH or secure shell SSH 173 00:09:12,178 --> 00:09:15,600 but using a default port of eight 3 0, 174 00:09:15,600 --> 00:09:17,280 so 830. 175 00:09:17,280 --> 00:09:21,770 It, um, doesn't use the default port for, um, SSH, 176 00:09:21,770 --> 00:09:24,270 but this actually can be configured to a different port 177 00:09:24,270 --> 00:09:26,650 you know, depending on the implementation. 178 00:09:26,650 --> 00:09:28,760 Now, the other cool thing that I actually like is 179 00:09:28,760 --> 00:09:31,190 that DEVNET has several sandboxes where 180 00:09:31,190 --> 00:09:34,590 you can actually practice this concept in more detail. 181 00:09:34,590 --> 00:09:36,500 And by the way there's actually an open source 182 00:09:36,500 --> 00:09:41,030 Python library for NETCONF called the NC client. 183 00:09:41,030 --> 00:09:42,820 And it's actually available in GitHub 184 00:09:42,820 --> 00:09:45,590 at the link that I'm actually sharing in the screen. 185 00:09:45,590 --> 00:09:47,960 You basically can install, you know, 186 00:09:47,960 --> 00:09:52,080 this client or the NC client Python module using PIP 187 00:09:52,080 --> 00:09:54,310 right with a PIP installed NC client. 188 00:09:54,310 --> 00:09:57,150 And this is actually an example of it. 189 00:09:57,150 --> 00:09:59,490 Now, the last topic that I want to cover in this lesson 190 00:09:59,490 --> 00:10:02,909 is RESTCONF, and you already learned that REST 191 00:10:02,909 --> 00:10:05,420 is a type of modern API, while RESTCONF 192 00:10:05,420 --> 00:10:08,730 is actually, you know, the merging of the 193 00:10:08,730 --> 00:10:13,730 capabilities of NETCONF, but over a REST API, right? 194 00:10:13,800 --> 00:10:16,370 And this is why rest based a variant 195 00:10:16,370 --> 00:10:19,210 of NETCOMF is actually just called RESTCONF, right? 196 00:10:19,210 --> 00:10:22,280 And it's now supported in many networking devices 197 00:10:22,280 --> 00:10:26,510 and in the industry, and it's defined in RFC 8040 198 00:10:26,510 --> 00:10:31,020 and the following are the REST, you know 199 00:10:31,020 --> 00:10:32,830 RESTCONF principles, right? 200 00:10:32,830 --> 00:10:37,070 The RESTCONF interface is built around a small number 201 00:10:37,070 --> 00:10:40,200 of standardized requests that you already learned. 202 00:10:40,200 --> 00:10:42,721 Things like get, put, post, patch, delete, 203 00:10:42,721 --> 00:10:44,800 and many others, right? 204 00:10:44,800 --> 00:10:48,570 And there's several REST principles that are similar 205 00:10:48,570 --> 00:10:53,060 to NETCOMF. For example, the Client Server Model, 206 00:10:53,060 --> 00:10:55,540 you also have the Layer System Principle 207 00:10:55,540 --> 00:10:59,880 and the first two uniform interface principles as well. 208 00:10:59,880 --> 00:11:03,120 So there's a lot of similarity in there. 209 00:11:03,120 --> 00:11:06,450 Now, RESTCONF requires the server to keep some 210 00:11:06,450 --> 00:11:10,940 client state, at any request, the RESTCONF client 211 00:11:10,940 --> 00:11:13,650 sense is acted upon the server immediately. 212 00:11:13,650 --> 00:11:16,750 You can actually not send any transactions 213 00:11:16,750 --> 00:11:19,890 that span multiple RESTCONF message. 214 00:11:19,890 --> 00:11:22,180 So, subsequently some of the key features 215 00:11:22,180 --> 00:11:25,130 of NETCONF, including network wide transactions 216 00:11:25,130 --> 00:11:28,013 are not possible in RESTCONF.