Exon is what can be called a “mess manager”. By "mess" I mean "A situation when an undefined number of objects are lying around and not scrupulously documented, in their purpose or their current state of existence". Exon is therefore an item recording system that aims to provide a unified interface (API) for people who would like to fetch informations about those abovementionned objects.
Exon's API is based on UTF-8-encoded character strings above TCP/IP.
You can talk to the API by sending messages
that are made of commands
, subcommands
, keys
and values
.
The separator between commands
, subcommands
and key/value
blocks is a space, whereas key=value blocks are separated with ::
There are for the moment a limited number of possible commands
and subcommands
:
id
which takes an ID enclosed in double quotes as an argumentadd
which takes the following argumentname="Name of the item"
comments="Comments about the item"
comment
which takes the following arguments:id="ID"
with ID being a natural integer strictly greater than 0 between two double quotescomments="Another comment"
.
auth
which takes the following arguments:username="USER"
containing the usernamepasswd="password"
← quite explicit, imo.
del
which takes th
For instance, a message
requesting informations about a particular ID uses the id
commandwill say:
id <ID>
A
message
adding a new item to the database will say:add name="Fusion engine"::comments="Could explode at any time."
A
message
adding a new comment to a particular item will say:comment id="1"::comments="this is another comment"
Now it's getting a bit more funky. Due to an obvious will of interoperability with the rest of the world, the API response is UTF-8-encoded and in JSON. Yes, it uses JSON for the server-client protocol.
The fields of the JSON document are the following: name
, id
, date
and comments
.:
{ "status": "success", "message": "Item is available.", "data": { "name": "Engine", "id": 1, "date": "2015-12-29 00:12:04", "comments": "May explode.", "author": "anon" } }
As you can see in the abovementionned example, most of the values are character strings, except for id
which returns an integer. The date
field will return a
the date as it is returned by the command date "+%G-%m-%d %H:%M:%S"
on UNIX-like systems.
When registering a new item with the add
message, Exon will send this response:
{ "status": "success", "message": "New item registered", "data": <ID> }
When deleting an item, you'll receive the following response:
{ "status": "success", "message": "Item successfully deleted", "data:" ID }
When adding a new comment to an ID, Exon will send the following JSON document::
{ "status": "success", "message": "New comment added.", "data": <ID> }
Or if it fails, this:
{ "status": "error", "message": "Could not add new comment.", "data": <ID> }
The typical successful auth answer is:
{ "status": "success" "message": "Successful authentication" "data": "username" }
If you request a wrong item number, let's say 5, Exon will answer with the following JSON document::
{ "status": "error", "message": "Item not found.", "data": "" }
If you try to register an item with the same name as a previous one, the following JSON document will be sent:
{ "status": "error", "message": "Item already exists", "data": "1" }
If the authentication fails, you'll receive this message:
{ "status": "error", "message": "Authentication failed", "data": "username" }
If an item suppression had to fail, the following message would be returned:
{ "status": "error", "message": ERROR_MSG, "data": "id" }
ERROR_MSG
being either "Unauthorized action - User not logged in"
or "Non-existing item"
If Exon didn't understand the message
, it will send the following following JSON document:
{ "status": "error", "message": "Protocol error, please refer to the documentation", "data": null }
And in the worst case, the server crashes and you are invited to open an issue on GitHub.