Overview
This document gives a basic introduction to the structure and design of the novem api.
Structure
The novem API resembles a regular hierarchical file system, which consists of
folders
that contain files
or other folders.
The user interacts with the novem API much like they would a regular filesystem, creating, deleting or modifying files. These interactions are done over HTTP, using the following verbs:
GET
- read a file or folderDELETE
- remove a file or folderOPTIONS
- get valid operations on the file or folderPUT
- Create a file or folderPOST
- Overwrite the content of a filePATCH
- Modify the content of a file
In addition, each HTTP endpoint has a set of permissions similar to a unix filesystem:
r - read
w - write
x - execute
d - delete
When using the OPTIONS
verb or viewing the GET
content of a folder, novem
also provides a list of available HTTP verbs that can be used on the endpoint,
mostly matching the intention of read, write or delete.
The novem api is located at https://api.novem.io/v1/
. For the rest of this
document we use the shorthand /
to mean the base of the API, so that e.g
/whoami
corresponds to https://api.novem.io/v1/whoami
.
Since novem emulates a basic file system, most paths expect plain text (text/plain
).
N.B. PUT
is never used to update files that already exist, only to create new files and folders
Hierarchy
The overall structure of the novem API is divided into 5 main parts /vis
, /admin
, /devs
, /groups
and /orgs
.
- the
/vis
endpoints used to create our primary products:plots
,mails
,docs
,grids
, andviews
- the
/admin
endpoints used to control your profile, groups, devices and organisations. - the
/groups
and/orgs
endpoints list the groups and organisations your’re currently a member of
When creating a new folder the underlying structure is already populated. for
example, creating a plot in the /vis/plots
folder will automatically create a
folder structure beneath with files
such as data
, url
, shortname
and folders such as config
and share
.
Interacting with the API
The GET
request issued on a folder will return the content of the folder as a
list of json objects. Here name
represents the resource and uri
the path to
the resource, permissions
represents the “file” permissions and actions
the
valid HTTP verbs.
When using GET
on a file the content of the file will be returned directly.
PUT
can be used on folders to create sub-folders, such as PUT /v1/vis/plots/en_letter_freq
to create a new plot
visualisation named
en_letter_freq
. These names can only be lowercase alphanumeric characters with
optional underscores.
POST
is used to write or update the contents of a file. To turn the
visualisation above into a bar chart one would bar
to
/vis/plots/en_letter_freq/config/type
.
If you no longer have any need for the chart then you can issue a DELETE
request such as DELETE /v1/vis/plots/en_letter_freq
.
Content-Type
When interacting with the novem API, you will come across two kinds of content types:
application/json
text/plain
Most of the system will expect input as plain text, but the output is a bit more context dependant.
Viewing the output
All novem visualisation generations happens on our servers, and the output is made available to the user in many formats. via
The easiest one is to view the visualisation online by following the url which can be found by using GET
on the url
endpoint that can be found in the root of all visualisation folders.
We also provide pre-rendered outputs which are located in the files/
folder under each
visualisation. Here you have access to both png
, pdf
, txt
and ansi
versions.
Sharing novem visuals
Novem plots are private to the owner by default, but they can be shared with other user, groups and the world.
The shared/
folder contains an entity for each entity the plot is shared with:
@smith
- the plot is shared with the usersmith
.@smith~plots
- the plot is shared with theplots
group created bysmith
.+company~plots
- the plot is shared with theplots
group created by the organizationcompany
.public
- the plot is shared with the world.
Members of the respective user and organisation groups that are created in the
shared
folder can then view the plot online.
To remove access simply DELETE the corresponding files in the shared/
folder.
More details on sharing can be found here.
Examples
Throughout these pages you’ll find the below layout used multiple times. The structure is used to illustrate how the api is structured and which folders and files belong at what level in the hierarchy.
Plot
For illustrative purposes, below is the structure of an individual plot endpoint representing a chart of type bar
.
All the below underlying structure will be created as soon as you create the initial /vis/plots/
folder.
en_letter_frequency => Name
├── config => Configuration options
│ ├── caption => Caption below chart
│ ├── title => Title of chart
│ └── type => bar, sbar, gbar etc...
├── data => data to chart
├── description => Description
├── name => Name
└── shared => Sharing information
├── +org~group => Shared with an org group
├── @username~group => Shared with a user group
└── public => Shared with everyone
The above hierarchy contains three folders: en_letter_frequency
which is the
name of the plot, a configuration folder called config
, and the shared
folder.
Below is a partial structure for an individual mail endpoint.
All the below underlying structure will be created as soon as you create the initial /vis/mails/
folder.
Daily summary
├── config/
│ ├── reply_to => Should the e-mail include reply_to header
│ ├── size => The width of the e-mail: xs, s, m, l
│ ├── subject => Subject
│ ├── theme => E-mail theme, layout and color
│ └── type => Type of e-mail, currently only `simple` is supported
├── files/ => Different mail outputs
├── recipients/ => Mail recipients, either @usernames, groups or full mail address
│ ├── bcc
│ ├── cc
│ └── to
├── shared/ => Who is the mail shared with
├── content => Markdown body of e-mail
├── description => Description
├── name => Name
├── status => Write sent to send, write test to test
└── url