REST, JSON and CRUD

 
Understanding REST and JSON 

REST-Based APIs

Applications use application programming interfaces (APIs) to communicate. To do so,

one program can learn the variables and data structures used by another program, making

logic choices based on those values, changing the values of those variables, creating new

variables, and deleting variables. APIs allow programs running on different computers to

work cooperatively, exchanging data to achieve some goal.

In an API software world, some applications create an API, with many other applications

using (consuming) the API. Software developers add APIs to their software so other application

software can make use of the first application’s features.

When writing an application, the developer will write some code, but often the developer

may do a lot of work by looking for APIs that can provide the data and functions, reducing

the amount of new code that must be written. As a result, much of modern software development

centers on understanding and learning new APIs, along with the available libraries

(prebuilt software that can be used to accomplish tasks rather than writing the equivalent

from scratch).

Several types of APIs exist, each with a different set of conventions to meet different needs.

The CCNA blueprint mentions one type of API—REpresentational State Transfer

(REST)—because of its popularity as a type of API in networking automation applications.

This first major section of the chapter takes a closer look at REST-based APIs.

REST-Based (RESTful) APIs

REST APIs follow a set of foundational rules about what makes a REST API and what does

not. First, from a literal perspective, REST APIs include the six attributes defined a few

decades back by its creator, Roy Fielding. (You can find a good summary at https://

restfulapi.net). Those six attributes are

 Client/server architecture

 Stateless operation

 Clear statement of cacheable/uncacheable

 Uniform interface

 Layered

 Code-on-demand

The first three of these attributes get at the heart of how a REST API works. You can more

easily see these first three features at work with networking REST APIs, so the next few

paragraphs further explain those first three points.

Client/Server Architecture

Like many applications, REST applications use a client/server architectural model. First, an

application developer creates a REST API, and that application, when executing, acts as a REST

server. Any other application can make a REST API call (the REST client) by executing some

code that causes a request to flow from the client to the server. 

1. The REST client on the left executes a REST API call, which generates a message sent

to the REST server.

2. The REST server on the right has API code that considers the request and decides how

to reply.

3. The REST server sends back the response message with the appropriate data variables.

REST & JSON (CCNA-Level)

1) REST — What You MUST Know

REST = Representational State Transfer

It’s a style of API (not a protocol) used for network automation.

REST works over:

• HTTP or HTTPS (almost always HTTPS)

REST uses standard HTTP verbs:

HTTP Verb	CRUD Action	Used For
GET	Read	Retrieve data
POST	Create	Add new data
PUT	Replace	Replace an entire object
PATCH	Modify	Partial update
DELETE	Delete	Remove data

CCNA commonly tests:
GET retrieves information.
POST creates something new.

---

2) REST Uses URLs (Endpoints)

Example endpoint:

https://dna-center/api/v1/network-device

REST endpoints point to:

• a resource

• or a collection of resources

You don’t need to memorize how DNA-C structures them.
You just need to understand the concept.

---

3) Authentication — CCNA angle

Almost always:

✔ Token-based (Bearer tokens)
✔ Provided after a login request
✔ Then included in headers for future calls

You might see:

X-Auth-Token: 9vk392kj-3829ac

---

⭐ 4) JSON (JavaScript Object Notation)

REST APIs commonly send/receive JSON.

You MUST be able to recognize a valid JSON structure.

JSON basics:

• Key-value pairs

• Keys in quotes

• Values can be strings, numbers, booleans, arrays, objects

• Commas between entries

• Entire structure wrapped in { } for an object or [ ] for a list

Example:

{
  "hostname": "SW1",
  "ip": "10.1.1.10",
  "vlans": [10, 20, 30],
  "enabled": true
}

The exam may ask:

• What type is “vlans”? → Array

• What type is “enabled”? → Boolean

• What delimiter surrounds JSON objects? → { }

---

5) JSON Array vs Object (Guaranteed Question)

Object = key-value pairs

Surrounded by curly braces:

{ "hostname": "SW1" }

Array = ordered list

Surrounded by square brackets:

[10, 20, 30]

---

⭐ 6) Describing Data Structure (Blueprint Verb: DESCRIBE)

You must understand:

• JSON = structured, machine-readable

• Human-readable

• Used for network automation

• Passed inside REST API messages

NO CLI required.

---

⭐ 7) REST vs SOAP

CCNA loves this compare:

REST	SOAP
Lightweight	Heavy
Human readable	Verbose, XML-only
JSON or XML	XML only
Uses HTTP verbs	Uses its own RPC-style calls
Modern automation	Legacy systems

REST wins for automation — that’s the exam message.