- [Instructor] When software programs running
on different systems want to communicate,
they generally do so via Application Programming Interfaces
or APIs.
This allows one system to read, write, or delete
variables or information from another system.
Rather than re-inventing the wheel,
many developers integrate
some standardized API into their applications
so they don't have to spend all the time and money
developing something custom.
It's also a good idea to use a standard API
as it will be easier for other vendors to interact
with an application.
Cisco specifically mentions
the REpresentational State Transfer, REST, API.
REST defines six specific attributes.
Uniform interface, layered, clear statement
of cacheable or uncacheable, client server architecture,
stateless operation, and code on demand.
Client server architecture should seem fairly familiar.
It operates like any other client server product.
The client makes a request.
The server computes what it should return,
then the server delivers the information back.
While REST almost always utilizes HTTP
as its transport method,
it's not mandatory.
It could also use SNMP, SMTP, or other methods if desired.
The stateless operation means that each request
is independent from another.
One transaction can't impact another.
Another clever function of REST in the cacheable option,
for any resource that is requested,
the server can inform the client
that this information is cacheable,
and if it is, for how long it can safely be cached.
In short, if the information is something
that's not likely to change,
it's safe to simply cache it on the clients side
to speed up performance.
While REST clients make request,
they perform one of four primary actions
known affectionately as CRUD.
Create allows a client to create new data structures
or variable instances
and set their initial value.
Read empowers a client to query the server
for the value of variables.
Update allows a client to update the contents
of the variable on the server.
Delete allows a client
to delete an instant of data variables.
Standard web server HTTP is similar to REST API
in many ways,
even down to how it interacts client and server wise.
HTTP uses similar verbs,
the following chart shows the CRUD term
with its equivalent HTTP verb.
REST APIs use Uniform Resource Identifiers or URIs
to access resources.
URIs in REST act much like a URI in an HTTP request.
If I access gregso.com/files/bgp-prepending.pdf,
then I'm accessing a specific resource,
and in this case, it happens to be the
/files/bgp-prepending.pdf
that is accessed via HTTP at gregso.com.
While REST request a DNA center,
may look something like this.
In this instance, it's everything after /API
that's the resource.
The details on making rest calls to the DNA center
can be found in developer.cisco.com under
"cisco dna center api documentation."
In fact, cisco has some publicly available sandbox
DNA servers I'll be using in my example below.
One example they list for the above URI
is making a request to DNA center
for the devise with management IP 10.10.22.253.
The request would look a lot like this.
Looking at the request, you see that I'm
simply passing variables to the REST API
with specific criteria filled out.
In fact, everything from the question mark on
is considered the query portion of the URI.
I'm using SoapUI, an open source tool
that can be used to test APIs.
Making my request, I see in raw format
that I'm getting a HTTP 200 OK response
which is what I'm looking for.
The data return is in Java Script Object Notation,
better known as JSON.
If I switched SoapUI over to JSON,
the data formats itself in a much easier to read form.
With all the DNA center's sandbox options
available for free, there's really no reason
you shouldn't have a little hands on experience
prior to the exam.