Cisco CCNA 200-301 – Network Automation and Programmability Part 3

5. APIs – CRUD, REST and SOAP

You’ll learn about APIs with a specific focus on Soap and Restful APIs. API stands for application Programming Interface. It’s a way for a computer program to communicate directly with another computer programming. So in networking, if you’re using the command line to work on a network device, that’s not using an API because that is human to machine interaction, an API is used when it’s direct communication between software to other software.

APIs are typically used to perform Crud operations. Crud stands for create, Read, Update and Delete. I’ll talk about that more on the next slide. And the two main types of APIs for web services, meaning they can run over the Internet and typically use Http or Https are Soap and Rest. NETCONF and RESTCONF are other APIs which are specifically designed to work with network devices.

I’ll speak about those more in another lecture later in this section. So those Crud operations stands for create, Read, Update and Delete. This actually originates in the database world, which is why you can see the first example here is SQL, which is commonly used for databases. So if you are working with SQL database and you wanted to create a record, you would use an insert command for that.

If you wanted to read, you would use select to update would be Update and to delete would be delete. We can also use Http or Https for our Crud operations as well. So with Http, if you want to push some information to the server side, if you want to create something, you use Put or Post as the Http method. If you want to read information, you use Get.

If you want to update, that’s a Put, Post, or patch. And to delete, you use the delete method. So with these, because they’re doing words, you can also hear these being described as an Http verb. We are going to be called an Http verb or an Http method means the same thing. And if you’re wondering, well, if I want to push some information over Http, if I want to create something, do I use Put or post? Well, it depends on the particular application, the particular system that you’re working with.

So check the documentation and it will tell you there wherever it expects a poo or a post, it’s going to be one or the other. So we can use Http and Https to do these different operations on the system that we are interacting with. Okay, our first API that we’re going to look at here is Soap stands for Simple Object Access Protocol. It’s a standard communication protocol that permits processes using different operating systems like Linux and Windows to communicate.

The transport is typically http or https the data format is always XML. So with Soap it is a protocol, so it specifies exactly how it should work. It’s got strict standards to adhere to. One of those standards is that the data format has to be XML. The transport can be anything but typically it’s going to be Http or Https, which is used. The other API main one for web based services is Rest. This is super popular.

Now, Rest is an architecture, not a protocol. Unlike Soap, it gives guidelines for the structure and organization of an API. So because it’s an architecture, not a protocol, it doesn’t say you have to do it exactly like this. It’s got guidelines for how it should be done. Because it’s not as strict as Soap, it supports any transport and any data format as well. Http and Https are most commonly used for the transport, and JSON or possibly XML data formats are commonly used. It’s typically got faster performance and it’s easier to work with than Soap. So with modern web based APIs, you’ll see that Restful APIs are by far the most commonly used now. So it’s an architecture. It doesn’t say exactly how Rest should work for each particular application, but it does have guidelines, it does have constraints here service constraints about what qualifies as a Restful API.

First one is it should be a client server architecture. The client sends a request, the server sends a response. So if you’re using an API to interact with a network device, such as a router, then the router is the server and the client software is the client. It must have a uniform, standardized interface to provide simplicity. And it must be stateless, meaning that no client context is stored on the server between requests. So every time the client sends a request to the server, that is a completely independent, self contained request.

So some example implications of this if the client has to authenticate to the server for security, which is very common, it’s going to need to authenticate in every request. It’s not like the client first authenticates and then it can communicate after that using those credentials, because the server does not store that information, it’s stateless. So each command, each request has to be self contained. If you are using authentication, the credentials have to be sent each time in each request. Next constraint is cachability. Responses must define themselves as either cacheable or non cacheable. So the constraint is that it supports caching. So for example, if you were using a get request to get information about the interfaces on a router, well, that information is not likely to change very often.

Your physical interfaces on a router are pretty fixed, so the server could tell the client to cache that information. It doesn’t have to keep checking that it hasn’t changed frequently. More constraints must be a layered system. So any intermediary devices between the client and server, such as load balancers, must be transparent to the client and server. And it needs to support optionally supports code on demand, where servers can temporarily extend or customize the functionality of a client by transferring executable code. Okay, so those are the requirements for an API to be classified as a restful API. But as I was saying, Restful APIs are by far the most popular now.

So if a particular vendor has got an API which doesn’t actually comply with all of these constraints, you’ll still see them often describe it as a Restful API anyway as long as it complies with most of them looking at the format of a Rest request. So as I was saying, this is typically going to run over Http or Https. So for the client to communicate with the server, it needs to be able to get to the server. It gets to the server based on the server’s URL. So the format of the URL is going to be either Http or Https. And then there is a server of a target host that it wants to communicate with and then there’s going to be the resource that it is interacting with on the server. And it depends on the particular application what the exact format of this is going to be.

As an example API running AAA users. Neil So in this example I’m interacting with an authentication system for AAA and then optionally you can have a query string with parameters on the end. So in the example here, this would be used for example if I am putting some information on AAA server, if I’m altering the parameters, the characteristics for this triple A user of Neil. And here I’m using a parameter of dry run saying I’m just going to do a dry run here. Don’t actually make the changes, just check that it is going to work first. So we’ve got the URL that we are interacting with. Other information that has to be sent with the request includes the request method, the Http method. So is it a get, is it a post, et cetera. Also typically headers will be included as well. They’re optional but they’ll often be there. This is key value information about the request.

For example, headers here, except application JSON means that in response you’re expecting that to be formatted with JSON. Other things that could be included in the header are your authentication credentials. And if you are pushing information to the server with a post, a poo or a patch, then the information that is going to be getting pushed to the server is going to be included in the body of that request. Okay? So with our Restful API we are going to be sending requests to the server for those Crud operations. The server is then going to respond back with the response. It’s also going to have a header, a body very similar to the request. It’s also going to have a response code there. Anything that this is going to be a three digit code. Anything beginning with a one is an informational response. Anything beginning with a two indicates that the request was successful. So for example, it could be a 200 okay message if we were pushing some content on the server side it could respond back with 201, saying that, yes, it has been created successfully. If we deleted something, then we would get a response code back, typically of 204, meaning no content, meaning that, yes, it has been successfully deleted. The next response code, anything beginning with three, is redirection.

So for example, if you’re browsing something on the Internet, you’ll see that you sometimes get redirected to a different page. That has been done with 301 redirection response code. So those are good response codes. We can also have bad ones as well. So anything beginning with a four means there’s a client error. If you get a 400 response back, that means it was a bad request or malformed syntax in your request. A photo one is unauthorized. You didn’t send the valid credentials. Photo three would be forbidden. Again, this is rightly. You haven’t sent the correct credentials. A photo four message you’ve probably seen this before when you’ve been browsing the Internet means that the page has not been found. You’ve probably put in a typo in the URL there 500 response messages means that it’s a server error. Common one you would see here would be a 500 internal server error. So we’ve got the codes coming back with the responses.

Responses to get requests will typically include data in the body with the information that you requested, and headers can also be included in response as well. Okay, so that was soap and restful APIs. In the next lecture, I’ll cover the network specific APIs of NETCONF, RESTCONF and gRPC, and then I’ll give you a lab demo showing a Restful API in action. How we can make those cross requests using the postman.

6. Model Driven Programmability – YANG, NETCONF, RESTCONF and gRPC

You’ll learn about model driven programmability with Yang, NETCONF, Restcont and gRPC. So a data model is well understood and agreed upon method to describe something. You can also see this being described as a schema as well. So it’s a way that data is laid out and organized. In the example here, you can see how a car dealership would maybe have their database laid out. So the data model for that you can see here at the top level, we’ve got the make, which includes the ID for the make, which is an integer, meaning it’s a number, and the name which is variable length characters up to 45 characters. We’ve also got the model of car with the model ID, which is an integer. Again, then the Make ID and also the name for the model. And we’ve got the Trim, or specifications of the car which has got the trim ID, the model ID, the name and the year.

So a data model is just the recognized and agreed upon way that your data is going to be laid out and organized. Yang stands for yet another next generation. It was standardized by the IETF in 2010. It’s a data modeling language which provides a standardized way to represent the operational and configuration data of a network device. So for using remote devices to interact with our network devices, to be able to pull information from them and push information from them, the client, which is the API, which is working with the network device, and the server, which is the network device itself, they need to have a standardized format for that data to be laid out in. And Yang is commonly used for that. It’s an open standard, so it’s used by different network device vendors.

It can be used both internally on the device as a way of describing all its components and features, and also when packaged for transmission, for example, when interacting with an API. So, looking at the Yang format, at the top we’ve got the module name. And you can see here, this is a standard IETF module which describes the network devices interfaces. Then we’ve got a couple of containers under there, the first container describing the interfaces, it includes information like the name, the description, the type, whether it’s enabled or not. And then we’ve got another container for the state of the interface which includes information like the name again, the type, the admin and operational status, et cetera. So that is how the Yang format is laid out, the configuration and operational status of a network device’s, components and services can be remotely read or written to NETCONF, RESTCONF and gRPC are APIs which describe the protocols and methods for transport of that network management data. So, looking at the model driven programmability stack on our network devices, we’ve got things like its interfaces, also its features like BGP, QoS, etc.

And then we’ve got the modules there which can be standard, such as the IETF interfaces that you just saw. But it can also be vendor specific modules as well, because maybe you’ve got a particular network device which has got features on there that are specific to that device. Well, in that case, the vendor would have a vendor specific module and they’re going to be laid out into modules which describe the configuration and also the operational status as well. So we’ve got our Yang data models that resides on the device. And if we want to interact with that information, so if we’re using an API to pull the information to read it, or maybe we want to push information to that particular device, then we can use NETCONF, RESTCONF or gRPC to do that. So Netconfresconf and gRPC, those are our transports that we can use to interact with the Yang data. So looking@our. net configurations, we’ve got the Yang data that is encapsulated in XML, and then we’ve got the Net conf information which is further encapsulating that. And we can send and request information to the server, which is going to be our network device. So a NETCONF was designed as a replacement for SNMP.

The issues with SNMP is for security concerns there, particularly if it’s before SNMP version three. And SNMP is good for reading information, it’s not so good for pushing information to the devices. So Network was designed as a replacement, really is an upgrade for SNMP. Netcomp and Yang provide a standardized way to programmatically, inspect and modify the configuration of a network device. So Yang was standardized in 2010. It’s a data modeling language which provides a standardized way to represent the operational and configuration data of a network device. As you learned earlier, NETCONF was standardized with ITF in 2006, and it’s a protocol that remotely reads or applies changes to the data on the device. So that might seem like it’s the wrong way around where Yang actually came out after NETCONF, but that’s what happened. So the way to work with the data was actually designed first. So Net conf wasn’t really used back in 2006, it wasn’t really usable until Yang came out in 2010. And Yang was actually originally designed to work with NETCONF. With NETCONF, it’s mandated that XML coding has to be used and the transport is usually over SSH.

It can also run over TLS as well looking@the. net conf protocol stack. We’ve got the content which is the data to be inspected or changed operations, for example, getting the config or editing the config. This is initiated by RPC methods using XML encoding. Messages do use RPC. That stands for remote Procedure Call. RPC simply means it allows one system to request another system to execute code. And we’ve got the transport between the client and server. As I said earlier, supports SSH or TLS. So looking at the protocol stack with NETCONF, we’ve got the transport SSH. TLS is also supported. The messages are using RPC. We’ve got the operations which is the action to perform. This is the crud action that we’re going to be performing. And then we’ve got the actual content, we’ve got the body there as well. Okay, moving on, we’ve also got restaurants. Restaurants came out later in 2017 and it builds on NETCONF. It’s also an IETF draft. It describes how to map a Yang specification here to a Restful interface. It uses http verbs over a rest API. And RESTCONF is not intended to replace net comps. It doesn’t have quite as much functionality as NETCONF, but it is simpler to use.

And everything Rest based nowadays is very popular with our NETCONF. It was mandated that it always uses XML encoding. Restaurants can use XML or JSON. JSON is seen as easier to read and simpler to work with, and the transport is Http or Https. So looking at the restaurant protocol stack, we’ve got, the transport is Http or Https, we’ve got our actions to perform at our Crud operations, and it’s Http based, so it’s get Post boot, patch and delete, and the content is going to be XML or JSON. And looking back at that slide I showed you for netcont earlier, so if this was Restcond that we were using now, it would be Yang data encapsulated in XML or JSON and then the Restcon. Okay? So moving on from there, we’ve also got gRPC. This is Google RPC. That’s an open source remote procedure call system initially developed at Google in 2015. It’s well suited to collecting telemetry statistics. So if you’re in an Internet of Things environment, you’ve got a lot of devices and you want to collect a lot of telemetry information from them, then gRPC can be a good choice. GPP Google Buffer google protocol buffers encoding is used rather than XML or JSON, and Retransport is Http too. So for interacting with network devices, if you’re going to use these, it’s going to be most likely netcomp or Rest comp, but gRPC is also available. Again, last thing to talk about here is Postman.

Postman is a super popular tool to test the operation of Rest APIs, so it tests Rest APIs. RESTCONF is also testable with Postman because it’s based on the same protocols. Postman can be downloaded as a standalone application, or it can be run as a Chrome plugin with Postman. There’s a lot of features and functionality in here. In Postman, your collections and environment variables allow you to easily reuse requests, so it makes it very convenient to work with. Requests can be exported as code in multiple programming languages, so you can send your requests with Postman, a test that they’re working, you check that they are working as you desired directly from Postman. You can export that into code, which you can use in your scripts. Again, very convenient. As well as Postman, you could alternatively use Curl in Linux or the request module in Python to test APIs. But Postman, because it uses a Gui and it’s got a lot of added functionality is the most popular choice, and I’ll show you how to use it in the next lecture.

• Category: Uncategorized