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:
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)
/responsibles (redirect to /persons - REST v3 artifact)
/responsibles/<r_uuid> (redirect to /persons/<r_uuid> - REST v3 artifact)
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...
Read more »