Internet of Plants (IoP)

So what exactly changed?

To be honest, nothing you can really see. The frontend and mesh-network now support RESTv4, which increased the speed up to 100%.

In other news /responsible/ got removed and / added. The new path now returns a JSON object full of every endpoint and the possible data you can input. That's a quite important and visible addition to the REST-API. /discover now no longer uses a PUT request for execution but rather a POST boolean input called execute. The attribute dict is now also deprecated and should not be used anymore.

Also in the backend of the backend (REST-API), an own input verification system got added, that proves if the correct data got inserted and converts the data if possible and necessary. The new verification system uses the following syntax to gather the data:

{'name': STRING, 'type': TYPE, 'fallback': STRING, 'restricted': [STRING, {'name': STRING, 'fallback': STRING}], 'list': BOOLEAN}

A small explanation:

• name is the name of the selected argument
• type is the target type of the argument, like str, bool, int or float
• fallback is used if the argumentis not present or a non-valid value
• restricted is a list of all possible values, if a value referes to another it is a string with a name and fallback
• list is a boolean indicating if chaining should be done

Also, the select statement now supports chaining. So you can now query for multiple things at once, in just one request. It get's returned as an object, where each item in select is a key. Here's an example:

Example request GET arguments:

?select=created_at,timestamp

Example input verification output:

{"select": ["created_at", "timestamp"]}

Example return output:

{'created_at': DATA, 'timestamp': DATA}

REST v4.2 will remove REST v3 and include a write only test case

Have a nice day

For the fourth time completely rebuilt how the REST-API works. I did this because hit a wall concerning reusability, simplicity, and expandability.

Instead of having one path for one interaction, I regrouped them for a better RESTful representation and a less hacky approach.

To show the changes I made, these are the old URLs in REST v3:

/create/message
/create/plant
/create/plant/register
/create/responsible
/delete/responsible/<r_uuid>
/execute/discover
/get/day/night/time
/get/discovered/<int:registered>/names
/get/discovered/<int:registered>/names/extended
/get/message/<m_uuid>
/get/message/<m_uuid>/content
/get/messages/names
/get/plant/<p_uuid>
/get/plant/<p_uuid>/created_at
/get/plant/<p_uuid>/intervals
/get/plant/<p_uuid>/location
/get/plant/<p_uuid>/message
/get/plant/<p_uuid>/responsible
/get/plant/<p_uuid>/responsible/email
/get/plant/<p_uuid>/responsible/username
/get/plant/<p_uuid>/responsible/wizard
/get/plant/<p_uuid>/sensor/<s_uuid>/latest
/get/plant/<p_uuid>/sensor/<sensor>/<any(high, low):mode>/today/<any(yes,no):if_no_data_days_before>
/get/plant/<p_uuid>/sensor/<sensor>/<any(high,low):mode>/ever
/get/plant/<p_uuid>/sensor/<sensor>/data
/get/plant/<p_uuid>/sensor/<sensor>/data/<float:until>
/get/plant/<p_uuid>/sensor/<sensor>/data/count
/get/plant/<p_uuid>/sensor/<sensor>/data/current
/get/plant/<p_uuid>/sensor/<sensor>/data/start/<int:start>/stop/<int:stop>
/get/plant/<p_uuid>/sensor/<sensor>/prediction
/get/plant/<p_uuid>/sensor/<sensor>/range
/get/plant/<p_uuid>/sensors/range
/get/plant/<p_uuid>/status/average
/get/plant/<p_uuid>/status/online/
/get/plant/<p_uuid>/survived
/get/plant/<p_uuid>/type
/get/plant/<plant>/average_status/percent
/get/plant/<plant>/current_status
/get/plant/current/host
/get/plants/master
/get/plants/name
/get/plants/name/extended
/get/plants/satisfaction
/get/plants/sensors/satisfaction
/get/responsible/<r_uuid>
/get/responsible/persons
/get/sensor/<s_uuid>
/get/sensor/<sensor>/range
/get/sensor/<sensor>/unit
/update/current/host/to/localhost
/update/day/night/time
/update/notification/message
/update/plant/<p_uuid>/alive/<any(online,offline):mode>/add
/update/plant/<p_uuid>/connection-lost/duration
/update/plant/<p_uuid>/location
/update/plant/<p_uuid>/name
/update/plant/<p_uuid>/non-persistant/duration
/update/plant/<p_uuid>/notification/duration
/update/plant/<p_uuid>/ranges
/update/plant/<p_uuid>/responsible
/update/plant/<p_uuid>/satisfaction/level/add
/update/plant/<p_uuid>/satisfaction/level/reset
/update/plant/<p_uuid>/type
/update/responsible
/update/responsible/wizard

Those are many paths to remember and to use, huh?

In REST v3 only /get/ essentially used the GET method. Everything else, more or less consistent, used the POST method.

What exactly changed? Instead of having 65 endpoints, which aren't particularly well ordered or have any structure what so ever, the new API now has 18 endpoints and is a bit faster. The new endpoints are using, instead of only one, multiple HTTP request method. Just for comparison, here's a small list of the new paths and the supported methods:

/day/night                         (GET, POST)
/discover                          (GET, PUT - substitute for execute)
/host                              (GET, POST)
/messages                          (GET, PUT)             
/messages/<m_uuid>                 (GET, POST)
/persons                           (GET, PUT)
/persons/<r_uuid>                  (GET, POST)
/plants                            (GET, PUT)
/plants/<p_uuid>                   (GET, POST)
/plants/<p_uuid>/message           (GET)
/plants/<p_uuid>/responsible       (GET) 
/plants/<p_uuid>/sensor            (GET)
/plants/<p_uuid>/sensor/<s_uuid>   (GET)
/plants/<p_uuid>/status            (GET)
/responsibles                      (redirect to /persons - REST v3 artifact)
/responsibles/<r_uuid>             (redirect to /persons/<r_uuid> - REST v3 artifact)
/sensors                           (GET)
/sensors/<s_uuid>                  (GET)

As you can see from the now available endpoints, every object has only a fraction of the paths used before. Essentially every object now has two endpoints except one. The object that is the exception is the plant. This something is one of the more important objects used for saving a variety of different data.

Another new feature is the uniform structure of the data returned in JSON:

{"code": 200, "content": []}

A little explanation: content is guaranteed to be either an object or array. If no data is present, an empty array is going to get returned. The code is a typical HTTP code, saying if something possibly went very wrong.

Also: REST v4 is currently not tested and REST v3 is still included in this build, because of moving purposes and testing, but is going to get removed in REST v4.1