The ReST API

Typically, your back-end data will be accessible through a ReST API which will expose CRUD functionality.

We decided upon a small data model of something which had images, then built an entity relationship model, and then built the ReST API.

For the purposes of this guide, we chose to utilise one of the many cloud database vendors which provide both storage and a ReST API.

Data Model

We chose to model data which was freely available in the public domain and had no licensing restrictions. We decided upon a small part of the football (soccer) industry which had images. The model will have to support all data CRUD operations.

Entity Relationship Diagram

We chose to model this as a simple ER diagram using Lucidchart:

restdb.io

We selected restdb.io because it was simple to configure, at a reasonable price.

Security

restdb.io prevents public access to data by supplying an API Key which must be used when accessing data via the ReST API. This is where we copied our generated key from when we setup data sources to this ReST API.

Tables/Entities/Documents/Collections

Typically, relational/SQL database systems store data in tables. No-SQL database systems such as restdb.io use the term 'document' or 'collection' to describe the same thing i.e. a table of data with rows/records and columns/fields. Whilst the former are abstractions, entity is more of a real-world description e.g. a product or a person.

We will refer to this in data storage terminology as a table.

This is how we created the Players table.

Media

restdb.io handles media files such as images in its own media archive:

This is an important consideration when using or creating a ReST API which supports media files.

Importing Data

You can manually create data to get started in restdb.io and this is good for creating the first small set of records to prove that the data model is correct.

If however you already have a large JSON data set, you can import that directly into your restdb.io table so that you can test performance if necessary. Be aware that if your data model has foreign keys, importing data will not create records in linked tables.

Of course the goal is to integrate your ReST API with Flexiva to create CRUD forms where end-users can create and maintain your data, so this is preferrable to importing data.

Viewing Data

When we are logged into restdb.io, we can view raw data using the URL for each table:

We can see that this is a hierarchical JSON data set which we can consume in our data source requests, however a ReST API does far more than display raw data.

Views

Typically back-end databases comprise dozens if not hundreds of tables, all connected via foreign keys and primary keys.

Client-side applications do not need, or indeed wish, to know about the internal details of the data model in the back-end.

By adopting 'separation of concerns' or 'abstraction' it means that the server can send two dimensional tables sourced form multiple tables. It does this by creating 'views' of data by joining tables together.

The client-side app only gets this 2D table which is both efficient and easy to understand.

Typically, relational databases have SQL Views which join tables together declaratively. No-SQL databases such as restdb.io require programming to create views.

The benefit of restdb.io views however is that they can be remoted as a ReST API automatically, whereas a relational database SQL view will need an additional API layer in order to remote that data.

The swings and arrows of outrageous fortune.

Building the restdb.io Views

We utilised 'vibe-coding' with an AI LLM to get the basics of the views in place, however this was arguably no more efficient in terms of time than manually coding these views.

A GET/DELETE ReST API will typically have URL arguments which are used to filter the data e.g.

https://api.domain.com?name=fred&position=goalkeeper&club=arsenal

These arguments need to be manually coded in the restdb.io view.

A POST/PUT/PATCH ReST API will typically have a body containing data e.g.

{
    "ClubID": "abcdefgh123",
    "Club": "Norwich City",
    "PlayerID": "12345678",
    "Photo": "....."
}

These body fields need to be manually handled for CRUD operations in the restdb.io view.

The List of ReST API CRUD Views

This is the list of ReST API views which we will be using in the following pages all located at one of these two end-points:

https://restdb.trisys.co.uk

https://www-football-891b.restdb.io/views/

Postman

It is recommended that all of these ReST API's are thoroughly tested in a tool like Postman before integration into Flexiva.