REST APIs – A Brief Overview

-----------------------------------

Affected Roles: Administrator, Power Users

Related Digital Watchdog VMS Apps: DW Spectrum

Last Edit: April 28, 2025

-----------------------------------

 

REST API

A REST API (Representational State Transfer Application Programming Interface) is a type of API that follows the principles of REST, a style for designing networked applications. It uses standard HTTP methods like GET, POST, PUT, and DELETE to communicate between clients and servers, making it a popular choice for building web services. REST APIs are known for being stateless, meaning each request contains all the necessary information, and typically return data in formats like JSON or XML.

This article will outline what an API is, what makes an API a REST API, and why REST APIs are important for creating interoperability and integrations between software systems.

 

What is an API?

API (Application Programming Interface) is a set of functions and procedures that allow the creation of applications that access features or the data of an operating system, application, or other service.

Popular websites and web-based services, such as Facebook, Twitter, YouTube, online news services, etc., have published APIs that expose their information (posts, likes, videos, etc.) so that developers can create new ways to visualize or interact with information and services contained within each site.

 

Defining API

 

REST (REpresentational State Transfer) is an API architectural style for distributed hypermedia systems. REST APIs are almost always accessed through HTTP or HTTPS protocols – used to form the foundation of data communication on the Internet. Being that REST is one of the most common standards that drives the Internet, it is a technology that is understood by most developers.

REST clients “request” information from REST servers (ex., Facebook’s backend servers), and the servers “serve” data back to the clients which then decode and display the requested information (e.g. a web page) to a user.

Many programs act as REST clients. For example, cURL, Postman, and Insomnia. Custom developed middleware created specifically to link two systems together can also act as a REST client and there are many web automation platforms out there right now like Zapier that act as both REST clients and servers to enable integration of web-based services.

Another one of REST API’s greatest strengths is simplicity. Existing integration tools like SOAP, XML-RPC and others were very flexible and powerful, but difficult to work with as they were not supported by browsers.

 

Three General Rules

Learning from the shortcomings of older technologies, REST APIs adopted three general rules:

1. Use standard protocols and methods (HTTP/S, along with different methods (GET, PUT, DELETE, etc.) each giving context and meaning).
2. Requests should not interfere with each other, should not require serial requests to achieve a result, and previous requests should not interfere with each other. This is known as a “statelessness” condition.
3. Requests should be uniform.

 

Six Guiding Architectural Constraints

Building on the three basic rules, REST API formed six guiding architectural constraints that separate REST API from other types of programming interfaces. These constraints limit the methods that can be used by a server to process and respond to client requests and were designed to ensure that any interface bult with a REST API will have good performance, be scalable, simple, malleable, portable, and reliable.

• Client-Server Architecture – separates the user interface (Client) from data processing and storage (Server) so that a system has improved portability, scalability, and ability to modify at will.
• Statelessness – calls for no required continuous connection between the Client and the Server between requests. All requests from a Client contain all information needed to execute the request. This makes the interface between Clients and Servers reliable.
• Cacheability – caching is all about making information available at the right place at the right time. Your web browser caches data from websites (assets like images, colors, types, fonts, etc.) so that it can reload them faster the next time that they are viewed. Caching, if implemented properly, can improve the scalability and performance of an application significantly.
• Layered System – Clients do not know what Server they are connected to. Layered Systems also mean that a Server can call other Servers in a System to generate a response to a request from any connected Client. This approach can improve system scalability by enabling load balancing and shared caches.
• Code On-Demand – Servers can temporarily extend or customize the functionality of a Client by transferring executional code. This increases the malleability of an application built on a REST API.
• Uniform Interface – fundamental to the design of any RESTful system. It simplifies and decouples the architecture, enabling each part of a system (e.g., the Client or the Server) to evolve independently, making a system flexible and easier to maintain.

 

The History of REST

REST APIs rose into a dominant tool in the field of software engineering in the early 2000s.

 

REST Beginnings

The first mentions of REST come from the works of Dr. Roy Fielding, a researcher in computer science, in his dissertation entitled “Architectural Styles and the Design of Network Based Software Architectures”. Dr. Fielding introduced the basic concepts of REST and additional complimentary details. The paper went over how software developers could use existing technology to make robust and powerful tools while keeping things simple. This paper laid the foundation that led to the formation and evolution of simpler APIs – including REST.

 

REST on the Rise

The earliest adopters of simplified APIs were ecommerce platforms. The first major and publicly available REST API was put out by eBay on November 20, 2000. Limited to a few partners originally it set the benchmark for any future APIs to come out. Amazon.com published their own API in 2002. Then came social networks, with first Flickr (2004), then Facebook (2006), and Twitter (2006).

These APIs served multiple purposes. First – they allowed the creation of complimentary platforms. Suddenly eBay was no longer just the website eBay. It became a data repository for anyone with the ability utilize the API, spreading eBay’s reach far around the Internets, giving birth to more online shops, all depending on eBay. This, in turn, increased the value of eBay, generating more sales for eBay, advertising spending, and a continual stream of people joining to build their own tools and shops on top of their API. Although eBay’s popularity has declined in the past years, their API was a revolution and changed the way e-commerce worked forever. 

Second – they allowed more control over a company’s data and with lower costs. Scraping (using a robot to go collect information on a web page) was a costly thing for eBay – and for most companies. By introducing an API, they could greatly reduce the amount of robots (software programs that searched, indexed, and stored metadata about their site) they needed to use, lower costs, and programmatically control access to their data. Through the use of API keys or tokens bad actors (people abusing the API) could quickly be evicted, while people with good business cases saw a standardization in how a company’s data could be accessed dependably.

While more companies were building their own APIs to give access to their own services – e.g. Cloud Computing – one saw more potential in that – Amazon. Amazon originally built Amazon Web Services (AWS) to guarantee access to their online shops. Over time Amazon began reorganizing itself into smaller entities, all connected by APIs. At first, this gave them greater flexibility, allowing teams to perform changes rapidly, if they didn’t change the outside-facing API.

Then, in March 2006, Amazon changed everything. They launched AWS with a new purpose: providing a cloud-based computing platform that could be used to rapidly build and grow web-based services (like Dropbox). AWS services were no longer restricted to Amazon’s internal use. The first service launched, Amazon S3, is a mass storage service. By making it accessible through a REST API and selling access to computing resources, people could now start building not just tools around platforms, but platforms themselves. Amazon EC2 would provide computing resources in the cloud, allowing people to run servers, and move to more powerful machines when needed.

Gone were the days of needing to rent space in a server room and buying your own hardware. You could now launch new servers in the span of seconds, get reliable backups and content delivery, all accessible through simple APIs. Today, Amazon is the biggest cloud provider in the world, showing that their strategy worked. While not responsible for the rise of cloud computing, REST APIs, through their ease of use, certainly contributed to a faster growth of it.

 

No Rest for REST APIs

Platforms would donce again take the spotlight a few years later, with the rise of smartphones. Applications were no longer only available via a web browser on a computer – they exploded across Google’s Android and Apple’s iOS as both companies introduced online marketplaces that made downloading and installing smart phone apps simple and straightforward.  These apps would need back-end dependable, scalable computing resources as they experienced rapid growth – and AWS was there to answer the call. Many apps today are not only built using REST APIs but have their own REST APIs as well.

Today, REST APIs are everywhere. To say they have won the API war is not an understatement. And while they may one day be dethroned themselves by newcomers (gRPC, GraphQL, etc.), they currently stand at the top of the API game and – because of their ubiquity – will likely stay there for a long time.

Today having a strong understanding of REST APIs is expected of any software developer as most SaaS (Software as a Service) tools are built with their own REST APIs. And REST APIs are everywhere. As of 2018, an estimated 85% of APIs online were REST APIs (or a close variant). Billions of requests are made to these APIs every day – and they drive interoperability not only on the web, but with offline products like DW Spectrum.

 

REST API in DW Spectrum

The DW Spectrum Server API is a RESTful API that can be used to integrate 3rd party devices and systems with DW Spectrum Systems.

The diagram at the beginning of the article and above shows a simplified process that outlines how 3rd party products can integrate with DW Spectrum VMS using the DW Spectrum Server API and the Do HTTP Request action in the DW Spectrum VMS Rules Engine. DW Spectrum can act as both a REST Client and a REST Server, allowing developers to use DW Spectrum VMS as a situational awareness platform that integrates with all their existing complimentary systems.

Common use cases for the API and Do HTTP Request action include:

• Sending Events from 3rd party devices and systems to DW Spectrum to create system automation in the DW Spectrum Rules Engine.
• Pulling live or recorded video from a DW Spectrum System for playback in a 3rd party interface.
• Sending API calls to 3rd party devices (e.g. Access Control locks, IoT devices) and systems (e.g. Access Control, Fire, and Alarm) to extend the control capabilities of a system operator using DW Spectrum.

 

Accessing the Server API

The DW Spectrum API documentation is available on the Server web page, built into DW Spectrum. To view the API documentation:

1. Install DW Spectrum and create a System.
2. After logging in, right-click on the Server in the Resource Panel (left panel) and select “Server Web Page”.
3. After logging in to the Server Web Page, select the “For Developers” and navigate until you find the API Documentation link (under Server API).
4. Do not forget to check out he Generic Event Generator Tool, which helps format how data can be quickly sent to DW Spectrum.

 

 

 

For More Information or Technical Support

DW Technical Support:  866.446.3595 (option 4)

https://www.digital-watchdog.com/contact-tech-support/

______________________________________________________________________________

DW Sales:  866.446.3595                   [email protected]        www.digital-watchdog.com