- As you learn from the previous lessons, you know,
APIs are used everywhere these days.
A large number of modern applications
use some type of APIs
because they can make access available to other systems,
and to interact with other applications.
You saw them at least, we briefed them in other lessons
whenever we talked about DNA center, we talked about ACI,
and many other technologies that take advantage of APIs
for provisioning and to interact with network devices
and applications as well.
Now there are a few methods or technologies
behind modern APIs.
The first one is actually a standards based
Web Access Control protocol
that was originally developed by Microsoft.
And it was actually used
by numerous legacy applications for many years.
And this is SOAP or the Simple Object Access Protocol.
Now SOAP is exclusively related to XML.
So it actually uses XML to provide API services.
And the XML basic specifications are actually governed
by the XML Schema definitions or excess D documents.
And SOAP was originally created to replace older solutions
like the Distributor Component Object Model or DCOM
and also the Common Object Request Broker Architecture
CORBA, right?
You can find a lot of information about the latest soap
specification at the W3 website that I'm actually
sharing in the screen.
However, there are many different APIs in modern times.
They use restful APIs and restful or REST, stands
for Representational State Transfer.
And you know, many folks actually refer to them
as restful APIs, but a REST API, a standard is a little bit
easier than SOAP and it actually uses JSON instead of XML.
And it also uses standards like SWAGGER
and the open API specification for the ease
of documentation, actually, to help with adoption.
As a matter of fact, by using things
like the SWAGGER editor, you can actually export
or automatically create even code to interact
with the underlying API that is being documented.
So because of that, and many other benefits
restful APIs are actually used nowadays, pretty
much everywhere.
And a lot of the Cisco devices that you're gonna
be learning later in the course, they use restful APIs.
Now there's another query language for APIs that provides
many developer tools and that's actually called GraphQL
and queryable APIs.
Now, GraphQL is now used for many mobile applications
and online dashboards. Many languages support GraphQL.
It's not used in networking infrastructure devices
that often but you can actually learn more about GraphQL
at the link that I'm sharing in the screen.
Now, SOAP and REST share similarities over the HDP protocol.
However, SOAP, it's a little bit more strict than
restful APIs, and a restful APIs are considered to be a
little bit more flexible.
Now, in this example, I'm actually showing
a quick interaction with the restful API
and this is extremely simple, using just cURL.
And basically you're actually getting back
you know, information about, you know,
an application that you can actually perform several tests
for free that is called Deck of Cards API, right?
So if you're new to APIs, as a matter of fact
many people actually use this website to actually
create quick Python scripts
or just using cURL as I'm actually showing
in the screen and actually interact with that, right?
So the API basically, you know,
allows you to do things like shuffling a
a Deck of Cards for you and, and many others.
So if you have never played with any APIs before
this actually may be a very quick, you know, dry run.
However, I also mentioned to you that DEVNET provides tons
of documentation on how to actually interact with devices.
So for the test, you actually
at least have to interpret basic Python scripts
or at least know the structure of, you know
Python script and probably, you know,
recognize that it's actually interacting with a restful API.
For example, using requests and many other capabilities.
Now, modern networking devices also support programmable
capabilities, like NETCONF, RESTCONF and YANG models.
And here I'm actually gonna provide details
about these technologies.
Now, YANG is an API contract language
used in many networking devices.
In other words, you can actually use YANG to
write a specification for what the interface
between a client and networking devices,
or a server, should be on a particular topic.
Now, YANG is also an industry wide standard, and is defined
on RFC 6020.
A specification written in YANG is actually often referred
to as a YANG module.
Now a collection or a set of YANG modules is often
called a YANG model, right?
So a YANG model actually typically concentrates on
the data that a client processes using
standardized operations.
Now keep in mind that in NETCONF, and also
in RESTCONF implementation,
the YANG controller is the client and the network elements
are actually the server.
Now the following are a few examples
of what a client can do using different YANG models.
You can configure, and of course, enable writing Protocols
or enable different features,
in a network infrastructure device
or receive notifications.
You can also monitor status, invoke different actions,
like resetting packet counters
rebooting the system and many other, you know
applications as well, right, or implementations.
Now the YANG model of a device is often called Schema
and that Schema defines the structure
and the content of messages that are exchanged
between the applications, and the device itself.
Now, the cool thing is that the YANG language
provides flexibility and extensibility that are not present
in other model languages.
Whenever you create a new YANG module
you can leverage the data hierarchies defined
in other modules.
So that makes it a little bit more flexible and extensible.
Now YANG is also allow or allows you to expand, you know
on a scale in a very consistent manner as well.
DEVNET, just like, you know, I mentioned to you, has tons
of different videos and demonstration, but they
actually have a video course that demonstrate how
YANG module works at the following link.
Now I mentioned NETCONF and NETCONF is a, it's a standard
that is actually defined on RFC 6241 and 6242,
and was created to overcome the challenges of the SNMP.
So the Simple Network Management protocol.
NETCONF has a concept of a client and a server
and a NETCONF client typically has the role
of a network management application,
and the NETCON server or the NETCONF server is a managed
network device, like a router, a switch, a firewall
and so on.
So you also can have intermediate systems that are
are often called controllers.
And that controls the particular aspects of a domain
and controllers act as a server to its managers, and
as a client to the networking devices, as I'm actually
sharing in the screen.
Now, a quick thing behind the scenes is that NETCONF was
created before YANG; other languages were you actually use
for NETCONF operations.
However, nowadays YANG is the only language widely supported
and used for NETCONF now in present time.
now NETCONF sessions establish
from a NETCONF client, to a server, consists of a sequence
of messages.
Both of the parties send a hello message.
And then, you know, whenever they actually try to connect
and all messages exchanges are initiated by the client
and then the hello messages include which NETCONF
Protocol version, the device actually support.
Then the server also state which optional capabilities
it also supports as well.
So, you know, it, there's a hello messages for
this type of negotiation.
Now NETCONF messages are encoded in XML and it,
of course, they're defined on the NETCONF standard.
Now NETCOMF communication is actually done
over secure SSH or secure shell SSH
but using a default port of eight 3 0,
so 830.
It, um, doesn't use the default port for, um, SSH,
but this actually can be configured to a different port
you know, depending on the implementation.
Now, the other cool thing that I actually like is
that DEVNET has several sandboxes where
you can actually practice this concept in more detail.
And by the way there's actually an open source
Python library for NETCONF called the NC client.
And it's actually available in GitHub
at the link that I'm actually sharing in the screen.
You basically can install, you know,
this client or the NC client Python module using PIP
right with a PIP installed NC client.
And this is actually an example of it.
Now, the last topic that I want to cover in this lesson
is RESTCONF, and you already learned that REST
is a type of modern API, while RESTCONF
is actually, you know, the merging of the
capabilities of NETCONF, but over a REST API, right?
And this is why rest based a variant
of NETCOMF is actually just called RESTCONF, right?
And it's now supported in many networking devices
and in the industry, and it's defined in RFC 8040
and the following are the REST, you know
RESTCONF principles, right?
The RESTCONF interface is built around a small number
of standardized requests that you already learned.
Things like get, put, post, patch, delete,
and many others, right?
And there's several REST principles that are similar
to NETCOMF. For example, the Client Server Model,
you also have the Layer System Principle
and the first two uniform interface principles as well.
So there's a lot of similarity in there.
Now, RESTCONF requires the server to keep some
client state, at any request, the RESTCONF client
sense is acted upon the server immediately.
You can actually not send any transactions
that span multiple RESTCONF message.
So, subsequently some of the key features
of NETCONF, including network wide transactions
are not possible in RESTCONF.