Log entry & remote inductions implementation

[adnbr]

Perhaps the "log" implementation could be as follows, with JSON POSTed to a new flask endpoint?

POST /logs/new

{
  "machineuid":"machine-uid",
  "carduid":"card-uid",
  "elapsed":x in seconds
}

The server assumes that the start time is x seconds prior to the submission time, to simplify the node programming (it's expected the Python server will know the time, but it's more of a pain to get time from NTP on the access node).

It would follow that the new permissions (from the induction) would be similar:

POST /permissions/new

{
  "machineuid":"machine-uid",
  "inductor":"inductor-card-uid",
  "inductee":"inductee-card-uid"
}

Where inductor-card-uid is the UID of a card which is canInduct = true and inductee-card-uid is presumably a UID of a card which is canUse = false for the current machine. Return 200 for all OK and inserted, or another status code for a failure? 403, "user cannot induct on this machine" for example.

The python side would create a new entry in the user table if it doesn't exist, with a generic username. Perhaps this can in future be updated from SPACEDATA.

[adnbr]

If we take JSON POSTed for log entries and inductions, do we need to/should we take canuse requests as JSON as well?

I've found that the esp8266 restclient library doesn't quite send the header request properly, and I need to use request.get_json(force=True) in Flask to force it. Will look into the restclient library perhaps and see if there's something there that can be fixed. User error...

[callumsnowden]

Given we won't be making a POST request (presumably, as we're not creating new data only getting existing stuff) to the /canuse endpoint, I think sticking with the current method of building a URL is better. The HTTP/1.1 spec seems to say that sending a Request-Body can/will be ignored by the server when making a GET request (see https://stackoverflow.com/questions/978061/http-get-with-request-body).

If it makes things easier we could look at changing this?

[adnbr]

If it's OK as is then it can stay :)

[ultrafez]

If you'd like to keep the API close to RESTful principles, for the canuse route you could define the route as follows:

/machines/:id/canuse/:cardid

If you wanted it to be even more RESTful, you could model your permissions as a subresource of the machine, and define the URL as follows:

/machines/:id/inducted-cards/:cardid

This would return a 200 OK if the card had any permissions defined (and return details of those permissions), and a 404 if there were no permissions defined for the card. You could then add somebody as an inductee by POSTing to the same endpoint (and if the inductor card ID wasn't permitted, a 403)