My first rough thoughts looking at the documentation...
1. I'll need to ask every user to get both an developer Application key and an user API key.
- This is something I pointed out to Ecowitt in an email months ago, the concept of an Application key does not work with open source software where you cannot keep the app-key secure.
- Also the App key is rate limited to 3/sec. If you have thousands of users, you have no way of knowing what the app-key rate usage is going to be, nor limiting it. The users will just be hit with refused connections, so the app retries the request making the situation even worse.
2. The historic data response JSON structure
- Making each sensor a standalone item with the structure is not great
For example "temp_and_humidity_ch1" ... "temp_and_humidity_ch8". I think it would be better to have a top level "temp_and_humidity", and have that contain an array of sensors, each one identified by a channel number. Then if you later decide to add say channels 9-16, the array just expands with the extra sensors and very little/no code change is required at the client end.
- The "list" of dates/values is an object, that is really awkward to handle. It cries out to be an array of key/value pairs. They even called it "list"!
3. Why are most of the numeric values passed as strings?
It was stuff like that I was hoping to thrash out in a beta, this looks like and smells like a published API that isn't going to change.
I hoped it would look more like this...
"temp_and_humidity": [
{
"channel": 1,
"data": {
"temperature": {
"unit": "ºF",
"list": [
[1643076300, 32.2],
[1643076600, 20.9]
]
},
"humidity": {
"unit": "%",
"list": [
[1643076300, 40],
[1643076600, 33]
]
}
}
},
{
"channel": 2,
"data": {
"temperature": {
"unit": "ºF",
"list": [
[1643076300, 32.2],
[1643076600, 20.9]
]
},
"humidity": {
"unit": "%",
"list": [
[1643076300, 40],
[1643076600, 33]
}
}
}
},
...
]
},
