The REST Architectural Style

By Rishal Hurbans & Matt Van Der Westhuizen

In this era of digital technology, we find ourselves developing software that is required to be shared and utilised as far as possible in a manner that is as concise as possible. This is not a new concept, however, the need to refine and better these integrations have become more and more prevalent due to high demand for interoperability between different pieces of software.

An emerging trend is the use of RESTful APIs for both exposing data resources as well as consuming data resources from other sources. Within the development community, there exists some misunderstandings around what REST, and RESTful actually is. It is important to understand that REST is not a protocol, and it’s not a standard. REST is simply an architectural style achieved by combining a number of different well-known architectures.


There exist commonly used architectures in most distributed web-based software. It is important to understand the purpose of these patterns and where it is applicable. This will help in understanding the principles of a RESTful architecture.


Architectures - Client-Server

The client-server architecture is a fairly well-known and widely used architecture. Most network based applications work in this manner. The architecture consists of a server that acts as a central point that one or many clients may interact with. The idea behind a client-server architecture is that the server does the heavy lifting and orchestration required, whilst the client consumes the rich data and functionality by interacting with the server. When these computers communicate with each other, there’s a clear need for a common protocol that is understood and supported by both parties. The commonality required is the message format. Imagine the protocol being a channel of communication between two people such as speech which is common between the two, and the message format being the language that is understood between them.


Architectures - Layered

The layered architecture is utilised for a number of different factors. A layered approach allows developers to separate concerns and loosely couple components that interact with each other. The advantage of this approach when implemented optimally is that layers may change independently without impacting the rest of the application. There are also cases where a layered architecture may consist of a layer that is shared across multiple other layers. An example of this is a shared domain that is utilised throughout the application. The layered architecture implies that the various layers reside within the same application container.


Architectures - Tiered

The tiered architecture is very similar to the layered architecture. It consists of the same pattern and characteristics. The terminology “tier” is mapped to the terminology “layer”. The key difference between a layered architecture and a tiered architecture is that each tier resides on a different physical or virtual environment. This implies that tiers that interact with each other consist of different deployments and environments.


Architectures - Stateless

A vast majority of web applications make use of a server-side managed session to keep track of a specific client. These sessions are often used for auth (authentication and authorization), keeping track of context, and storing meta data in memory that may be useful for managing the user’s activity. This makes scaling difficult as additional technologies and development is required to create session management servers in a clustered environment. The stateless architecture removes the need for the server to create and hold sessions. In a stateless architecture, the state is managed by the client via some mechanism such as tokens, header data, etc. that are passed back and forth between the client and server.


Architectures - Cacheable

The cacheable architecture is the concept of cleverly caching data that is used often, and changed infrequently. Caching may occur in places like the client browser, and a caching server. Caching mechanisms are expected to be smart enough to serve cached data or resources until that piece of data or resource changes for the client requesting it. One of the advantages of caching is a reduced load on the network, this translates to reduction of unnecessary requests, lower data usage, and a more optimal performing application.

Uniform Interface

Architectures - Uniform Interface

The concept of a uniform interface includes creating a standard method of interacting with a system. The uniform interface architecture also promotes abstraction of the implementation from the interface definition. This allows for clients to interact with all services in the same way, using a standard protocol and message format with a well defined set of operations.

REST Architectural Style

The REST architectural style was documented by Roy Fielding in his dissertation in the year 2000 in an effort to provide a documented architecture that could be used to guide the development and design of the modern web. The first part of this paper characterised a large number of existing architectural constraints of which the ones covered above are only a subset.

In the second part of the paper REST is defined by composing a number of these architectural constraints into a cohesive whole. The patterns used are:
1. Client Server: This constraint provides separation of concerns, improves scalability and improves the portability of the interface.
2. Stateless: This constraint requires that each request contains sufficient state for the server to understand what to do… this provides visibility, readability and scalability.
3. Cacheable: This constraint requires that all responses from the service to its clients are explicitly labelled as cacheable or non-cacheable so that intermediary servers or components can cache responses. This improves efficiency, scalability and user-perceived performance.
4. Uniform Interface: This constraint defines a simple standard for working with a REST service. It includes identification of resources by URI, manipulation of resources through representation, self-descriptive message and HATEOAS.
5. Layered System: This constraint requires that a client should not be able to tell if it is connected to the end server or to an intermediary. Layered systems cause a reduction in performance, but this should be counteracted by caching.
6. Code On Demand (optional): This optional constraint allows client functionality to be extended by downloading and executing code from the server.

Fundamental Concepts


A logical resource is any concept that can be addressed and referenced using a global identifier, for example a car, dog, etc. URIs are used as the global identifier when implementing REST over HTTP.


A logical server where resources are located, together with any corresponding data storage features.


Logical clients make requests to logical servers to perform operations on their resources.

Request & Response

The client sends a request consisting of headers and optionally a representation. The server responds with a status code, headers and optionally a representation.


The representation contains some or all information about a resources and allows modification of the resource on the server by modifying the representation and sending it back to the server.

Richardson Maturity Model

The Richardson Maturity Model was first introduced by Leonard Richardson in a 2008 conference talk as a way to judge the quality of a RESTful web API. It assumes that most of the RESTful constraints are met by using web technologies and looks at how an API uses HTTP, URIs and HyperMedia to determine its quality.

Richardson Maturity Model

Level 0 – The swamp of POX

The swamp of Plain Old XML describes an API that is not RESTful at all. An example would be a SOAP-like web service using HTTP as transport, but not using any of the web mechanisms to its advantage. In the example below the API user will always POST a request to the same URI. What action is performed is controlled by the contents of the request.

The scenario used in the code examples in this section references the idea of having a conference where attendees have questions for presenters on a specific talk. Given this; talk and question, are resources that we would like to interact with.

Create a question
POST /createQuestionService HTTP/1.1
<createQuestion talk="Robust REST Architectures" question="Do you guys even REST?"  name="HelloPieter" />

HTTP/1.1 200 OK
        <question talk="Robust REST Architectures" question="Do you guys even REST?" username="HelloPieter" />
        <question talk="Robust REST Architectures" question="What is HATEOAS?" username="CodeWarrior" />

What’s bad about the above example is that the service is essentially a black box. Without documentation it’s pretty much impossible to figure out what you can do with the service.

Level 1 – Resources

The first level of RESTfulness begins to get rid of the black box by introducing the concept of resources. Instead of having a single URI for everything our API does we have a URI for each resource that can be manipulated with the API. This simplifies interaction with the API to working with a number of smaller, simpler boxes.

List talks
# Request
POST /talks HTTP/1.1

Create a talk
POST /talks/create HTTP/1.1
<talk name="Robust REST Architectures" />

HTTP/1.1 200 OK
<talk id="1" name="Robust REST Architectures">
Create a question
POST /talks/1/questions/create HTTP/1.1
<question question="Do you guys even REST?" username="HelloPieter" />

HTTP/1.1 200 OK
<talk id="1" name="Robust REST Architectures">
        <question id="1" question="Do you guys even REST?" username="HelloPieter" />

Level 2 – HTTP Verbs

The second level of RESTfulness is attained by using HTTP verbs to implement the uniform interface constraint. That is instead of using URIs to specify what action is being taken as in the previous example, URIs only specify the resource that is being acted on and the verb specifies the operation.

List talks

GET /talks HTTP/1.1

HTTP/1.1 200 OK


Create a talk

POST /talks HTTP/1.1
<talk name="Robust REST Architectures" />

HTTP/1.1 200 OK
<talk id="1" name="Robust REST Architectures">
        <question id="1" question="Do you guys even REST?" username="HelloPieter" />

Add a question

POST /talks/1/questions HTTP/1.1
<question question="Do you guys even REST?" username="HelloPieter" />

HTTP/1.1 201 Created
Location: /talks/1/questions/1

Update the question

PUT /talks/1/questions/1 HTTP/1.1
<question username="PieterMan" />

HTTP/1.1 200 OK
<question id="1" talk="1" question="Do you guys even REST?" username="PieterMan" />

View the talk

GET /talks/1 HTTP/1.1

HTTP/1.1 200 OK
<talk id="1" name="Robust REST Architectures">
        <question id="1" question="Do you guys even REST?" username="PieterMan" />

Delete the question

DELETE /talks/1/questions/1 HTTP/1.1

HTTP/1.1 200 OK
<talk id="1" name="Robust REST Architectures">
        <question id="1" question="Do you guys even REST?" username="PieterMan" />

Level 3 – HATEOAS

The acronym HATEAOS means Hypermedia As The Engine Of Application State. In essence it involves adding links to your representations to make your API explorable, similar to how links in HTML documents make web sites explorable.

List available API resources

GET /api HTTP/1.1

HTTP/1.1 200 OK

List all talk resources

GET /api/talks HTTP/1.1

HTTP/1.1 200 OK

        <name>Robust REST Architectures</name>

The Glory Of Rest

So in summary the ideal REST API is a self-documented interactive service:
* GET /api gives a list of all resources with their links
* Following those links allow you to explore all of the resources
* Using HTTP verbs on those resource URIs allow you to perform CRUD operations

Overview of HTTP

The most popular protocol used for RESTful implementations is HTTP. HTTP (Hypertext Transfer Protocol) is an application protocol for distributed hypermedia information systems. HTTP is widely used in networked computing, it is hugely prevalent in how the internet works. This section describes the basic concepts of the protocol.

URLs (Universal Resource Locators)

Architectures - HTTP URLs

HTTP URLs consist of several components including:
* Protocol: The protocol that the request is being made on. Typically HTTP or HTTPS. HTTPS is a secured version of HTTP. It requires a certificate to validate the authenticity of the server in relation to the domain.
* Domain: The domain includes the address of the server. Typically this is represented by a sub-domain, a domain name, and a top level domain. In the example, www is the sub-domain, this is the default sub-domain for the world wide web. is the registered domain name.
* Port: Different applications can communicate via different ports on a computer. Typically, port 80 is the default port for HTTP web application servers.
* Resource: The resource being requested by the client. This could be any media including virtual objects. An example is the /user resource gives the client data about users.
* Query: Queries are used to provide parameters for the resource being requested. An example is the /user?name=bob specifies that the client wants a user with the name “bob”.


HTTP provides several well known, widely used verbs for operations on resources, including:
* GET: Read data or resources. This verb should never be used to modify data.
* POST: Create data or resource. This verb should be used to create new data.
* PUT: Update data or resources. This verb should work on existing resources. The same PUT request should be able to be repeated with the same end result.
* DELETE: Delete data or resources. Similarly to PUT, a DELETE request should be able to be repeated with the same end result.

HTTP provides operations that are less known, but still useful:
* PATCH: Patch is used to update data or resources similarly to PUT. The difference is that PATCH requests should be used to update parts of a resource instead of updating a resource in its entirety. PATCH reduces the need to update complete objects by updating only the properties that require an update.
* HEAD: Head is similar to GET requests, however, the request should not contain a body. This request is useful to validate data or resources.
* TRACE: Trace invokes a remote, application-layer, loop-back. The TRACE request reflects the message that the final recipient server receives. This is useful to determine the final message after a request is proxied along a chain of servers. The TRACE request is useful for diagnostics on applications.

Status Codes

  • 1xx: Information. The request was received by the server, continue processing.
  • 2xx: Successful. The request was received, understood, accepted, and processed by the server.
  • 3xx: Redirection. Additional action is required to complete the request.
  • 4xx: Client Error. There was a problem with the request received by the server.
  • 5xx: Server Error. The request was received, understood, and accepted by the server, however, a server error occurred in processing the request.

Many applications tend to use the 200 OK status code for all responses to the client. In the case of errors, additional information is stored in the response message body. This should be avoided. The HTTP status codes should be leveraged and used correctly in the given context. An example being, a POST request should yield a 201 Created status code in the response rather than just a 200 OK.


Architectures - Layered

HTTP/2 is a new faster version of HTTP. The aim of HTTP/2 is to make applications quicker and more robust. HTTP/2 was spawned from Google’s SPDY protocol (SPDY is not an acronym, Google just thought is sounded cool). The biggest change is the method of transporting data. Data is being transported using binary rather than using text as HTTP/1 does. Binary data is smaller than text and therefore makes it more efficiently transported over a network. Nothing changes in terms of the semantics of the protocol. The same operations and standards exist when using it. This change shouldn’t affect the average web application developer. Developers that build browsers, application servers, or applications that work directly with the network layer will be impacted by the changes of HTTP/2.

Message Formats

REST is not tied to a specific message format. Initially XML was used, but in recent years JSON has become more popular as many clients are easily able to interpret JSON messages. In theory there’s nothing preventing you from creating a RESTful service that uses images as representations.

Message Formats: XML

Extensible Markup Language was introduced in 1996 and forms the basis for SOAP-WS standards. Here’s an example of a valid XML document:

<?xml version="1.0" encoding="UTF-8"?>

    <Surname>Van Der Westhuizen</Surname>

As you can see the syntax is quite verbose and perhaps a bit ugly. Some of the good features of XML are that you can create customised mark-up and there is versatile standards and tooling around XML (e.g. XSD, XSLT, XPath / XQuery, etc). The main downsides are the verbosity and the complexity of the standards leading to slower more complex parsing code.

Message Formats: JSON

JavaScript Object Notation was first publicised in 2002 (based on the date the website was launched). It supports only three primitive types:
* Scalar values
* Arrays
* Objects

Here is an example of a valid JSON document:

    "name": "Matt",
    "surname": "Van Der Westhuizen",
    "hobbies": [
    "phoneNumbers": [
        {"type": "home", "number": "1234567890"},
        {"type": "cell", "number": "0821234567"}

JSON is very easy to consume on web clients thanks to being a subset of JavaScript. The limited number of concepts make parsing the data on non-web platforms quite easy to implement. JSON has less data overhead thanks to the lack of closing tags enclosing each item and no envelopes as are typically the case with SOAP services built on XML. Thanks to this simplicity there is little to no need for complex tooling.

The one downside of JSON is that it is not as rigorous as XML, but there are some efforts underway such as JSON-HAL which defines a conventional REST message format and JSON Schema which is similar to XSD for XML and can be used to define the structure of JSON resources.

Message Formats: HAL

Hypertext Application Language defines a structure for Resource representations. You still have your resource state as the root of the object as you used to, but it requires you to add a links section and specifies how to embed resources inside another resource. This diagram illustrates the concept quite nicely:

HAL Resource

Here is an example showing a collection of users containing some embedded user resources:

    "_links": {
        "self": { "href": "/users" },
        "next": { "href": "/users?page=2" },
        "find": { "href": "/users{?surname}", "templated": true }
    "_embedded": {
        "users": [
                "_links": { "self": "/users/1" },
                "id": 1,
                "name": "Rishal",
                "surname": "Hurbans",
    "page": 1,
    "pages": 4

One of the benefits of HAL is that it can work with either JSON or XML, but the downside is that there is no agreed upon way to specify validation rules.

Message Formats: JSON Schema

JSON Schema is similar to XSD for XML, but only works for JSON resources. It provides a format for providing schema meta-data about resources that can be used for validation. It also has an extension for defining resource hypermedia which works similarly to HAL’s _links.

Here’s an example of JSON Schema for a person which would allow us to validate that person’s name is a string and that they should have at least 1 hobby:

    "$schema": "",
    "title": "Person Schema",
    "type": "object",
    "properties": {
        "name": {
            "type": "string"
        "hobbies": {
            "type": "array",
            "minItems": 1,
            "items": { "type": "string"}
    "required": ["name", "hobbies"]


The REST Architectural style is comprised of a combination of well known architectures. It leverages the benefits of each architecture to provide a consistent, yet flexible pattern for building interactive services. The Richardson maturity model is useful as a yardstick to determine ease of use and extensibility of your RESTful implementation. Although typical RESTful implementations operate over HTTP using JSON as a message format; one could potentially use any protocol and message format. In theory one could create an API that conforms to the principals of the REST architectural style that uses the FTP protocol with images as the message format – it’s just questionable if that would be useful? Bottom line, is that the REST architectural style is a guideline, it’s open to creativity (and abuse). A truly elegant RESTful API is a combination of following these guidelines as well as designing resources and interactions that solve real-world problems in a sensible way.


Building a HTML5 Space Invaders Visualiser


Space Invaders is a classic game that most of us have enjoyed as a child. I needed to build a basic “Space Invaders” visualiser for the Entelect R100K Challenge. The challenge this year prompts contestants to develop a bot program to play the game versus another bot program. Each player has a turn to move their space ship, shoot, or build a booster building. To find out more details about the challenge and the details behind the mechanics, check out the rules. In essence, each iteration (or turn) of the game is recorded in a text based map. This map is pretty readable but doesn’t really embrace the atmosphere of the game. The aim of this visualiser is to give the contestants a tangible way to visualize their matches and provide some inspiration to contestants that are making their own visualisers for the Gooey Challenge. You can download the code on GitHub.


The visualiser needs to be accessible to everyone, so it made sense that it should run in a modern browser. This means that it needed to be developed using JavaScript. Plain old JavaScript would be a mission, and since time wasn’t on my side, making use of a rending engine or game engine made sense. So from past experiences playing with HTML5 game engines, I decided to use Phaser. It’s easy to use, provides the required features and is open source.

Since each game state is recorded in a different text file, it’s pretty obvious that the minimum requirement of the visualiser is to read each game state in sequence and play them back. To make it visually appealing, each character that represents a game item should be rendered as a sprite that’s a bit more interesting.

Making Some Artwork

The first thing I decided to do is create some artwork that would represent the game. I didn’t have much time, so making low detailed sprites was the only way to go, furthermore, the low detailed sprites gives the visualiser a retro feel to it which fits in really well with the spirit of the challenge.

The game objects are represented below. Most objects are 1×1 characters in size, while some are 3×1 – this includes space ships and buildings only.

AAA: Your Ship
VVV: Opponent's Ship
XXX: Alien Factory
MMM: Missile Controller
#: Wall
-: Shield
x: Alien
|: Alien Bullet
!: Your Missiles
i: Opponent's Missiles

So here’s the artwork for each of these objects:

AAA: Your Ship


VVV: Opponent’s Ship


XXX: Alien Factory


MMM: Missile Factory


#: Wall


: Shield


x: Alien


|: Alien Bullet


!: Your Missile


i: Opponent Missile


Developing the Visualiser

Now that there’s some artwork to use as sprites in the visualiser, it’s time to put everything together. Again, we have a sequence of text files that represent a game state, and some images that will represent each character in a specific game state. So the following image depicts the goal for each game state.


The Phaser game engine allows for initialisation with a canvas width, canvas height, the type of renderer, and a name for the object. Furthermore, Phaser allows for a preload function and an update function. This is useful since the assets and game states can be loaded in the preload function, and the update function is just responsible for rendering each text-based game state.

The Phaser Game is initialised with the following. It’s telling Phaser to make a new canvas named “phaser” with the correct width and height. It’s also specifying the functions that should be used for preloading and updating.

var game = new Phaser.Game(SPRITE_SIZE * COLUMNS, SPRITE_SIZE * ROWS, Phaser.CANVAS, 'phaser', {
 preload: preload,
 update: update

The preload function needs to load the game state text files, as well as the images for the sprites. Phaser conveniently handles this by allowing various types of assets to be loaded, this includes images and strings – which works out perfectly for this purpose.

In the preload function, a helper function named loadMaps(replayPath, iterations) is used to load all the maps, and the game.load.image(name, filepath) function is used to load all the images into the game.

function preload() {

 loadMaps('example-replay', 52);
 game.load.image('alien', 'images/alien.png');
 game.load.image('factory-missile', 'images/factory-missile.png');
 game.load.image('factory-alien', 'images/factory-alien.png');
 game.load.image('missile-alien', 'images/missile-alien.png');
 game.load.image('missile-opponent', 'images/missile-opponent.png');
 game.load.image('missile-player', 'images/missile-player.png');
 game.load.image('shield', 'images/shield.png');
 game.load.image('ship-opponent', 'images/ship-opponent.png');
 game.load.image('ship-player', 'images/ship-player.png');
 game.load.image('wall', 'images/wall.png');

Here’s the loadMaps function. It simply iterates for the number of game state files and loads them into the game as text strings.

function loadMaps(replayPath, iterations) {

 for (var i = 0; i < iterations; i++) {
  game.load.text('maptext' + i, replayPath + '/' + zeroFill(i, 3) + '/map.txt');


You may notice the zeroFill() function. There exists a directory for each iteration of the game state, it is named with the iteration number and padded with zeros to make up a three character name. E.g. 1 becomes 001. The zeroFill() function is required to correctly pad the zeros for the correct game state path.

Now that the game sprites are loaded and the game states are loaded, they need to be replayed. The Phaser update function is important to accomplish this. Since Phaser handles the update rate, I needed to do some clever checks to achieve the frame rate that I wanted.

function update() {
 if ( - timeCheck > FRAME_RATE_DELAY_MS) {;
  var map = game.cache.getText('maptext' + iteration);
  iteration += 1;
  timeCheck =;

The initial condition determines if the right amount of time has passed, if it has, then we can update the game and objects being rendered. Phaser doesn’t allow for user defined ticks, so this is necessary to delay the iterations of the game state.

Next, all the elements of the game’s world are remove, this is to prevent old objects from sticking around and obscuring the current game state.

A map string then gets populated with the current iteration’s game state from the cache that was populated in the preload function.

The generateMap(map) function uses the game state text, iterates over the string and adds the correct sprite based on the respective character. Some logic is needed for when 3 block objects and new line characters. To find out more about this, have a look at the code on GitHub.

Finally, the iteration number is incremented and the time of rendering is recorded for use in the next iteration.

And it’s that easy to create a simple but effective visualiser using Phaser and JavaScript.

Adding Juice

Part of what sets a game or visualiser apart from the rest is the subtle detail and effort put into it. Here are some ideas for improving the above visualiser:

  • Tweening transitions between each game state: As you can see, the visualiser is very jittery, this fits for the retro style of this visualiser but a differently styled visualiser will be greatly improved by simply tweening the iterations.
  • Particle effects for collisions.
  • Animations when destroying and rendering interactions between sprites.
  • Sound effects for shooting, collisions, and spawning buildings.
  • A menu system for loading different matches.