| Table of Contents |
|---|
Overview
We'll store device details and store sensor readings over time.
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
{
"form_id": 2,
"locale":"en_US",
"type": "update",
"status": "published",
"values":{
"unit": "cpm",
"value": 20,
"captured_at": "2013-03-10T07:43:41Z"
}
} |
Forms
At the core of Ushahidi is posts and posts are defined by forms. Forms are basically templates. They allow the system to structure the data correctly by defining what is expected along with making sure it is valid. Forms can have sub-forms. The reason for this is illustrated above. You want one form to define what a device is. Next you want another form to define the datastreams generated by this device.
Why not have a single form? Each time you receive a new sensor reading, having a single form with the device information and sensor readings just means you'd have a lot more columns and some like the device information that doesn't change over time being repeated over and over, consuming unnecessary resources.
Posts & Endpoints
- The device we created above is accessible at GET:/api/v2/posts/1, where 1 is the id of the device.
- The endpoint that sensors would transmit readings to is accessible at POST:/api/v2/posts/1/updates
- form_id lets the endpoint know which datastream is posting to. In this case form_id:1 is for the radiation readings and form_id:2 is for lat/lon