- \n
- an HTTP server (Epoch<\/a>)\n
- an HTTP router\n
- HTTP request and response entity classes\n
- an interface to a Mustache<\/a> template responder (Sideburns)\n
- PostgreSQL and MySQL database adapters\n<\/ul>\n
and much more. Although relatively new to the scene, Zewo already has enough functionality to build a complete REST-based web service application. In the past I would have first considered Ruby and Sinatra<\/a>, but now with the arrival of Swift on Linux<\/a>, Zewo provides another great option.<\/p>\n
A Quick API Design<\/h2>\n
We’re going to build a REST API similar to that of AT&T’s M2X<\/a> platform. M2X is self-described as providing time-series data storage, device management, message brokering, event triggering, alarming, and data visualization for your industrial Internet of Things (IOT) products and services<\/i>. That’s a mouthful. Our API will be less ambitious and implement the time-series data storage piece, but that is enough to showcase some of the capabilities of Zewo.<\/p>\n
In the IOT<\/a> world we can think about devices<\/i> and streams<\/i> of data that are associated with the device. For example, a device could be a single-board computer like a BeagleBone or Raspberry Pi with several sensors attached to it. The sensor, in turn, would be providing a stream<\/i> of datapoints<\/i>, say temperature readings. These concepts can be modeled nicely in a relational database fronted by a REST API. And, if relational databases aren’t your thing, folks are working on NoSQL interfaces such as MongoDB<\/a>.<\/p>\n
Devices, Streams, and Datapoints<\/h3>\n
Our model will consist of
Device<\/code>,Stream<\/code>, andDatapoint<\/code>.<\/p>\nA
Device<\/code> has the following attributes, or properties:<\/p>\n- \n
- name\n
- serial\n
- location\n
- streams\n<\/ul>\n
A
Stream<\/code> has the following properties:<\/p>\n- \n
- name\n
- datapoints\n<\/ul>\n
And finally, a
Datapoint<\/code> (sometimes referred to as a reading<\/i>) will be:<\/p>\n- \n
- timestamp\n
- value\n<\/ul>\n
Now, believe me, this is the not the end-all be-all data model for an IoT application, but it provides enough structure to make our REST API interesting.<\/p>\n
The operations we will support are:<\/p>\n
- \n
- creating a new device\n
- posting a value to a stream\n
- retrieving the values of a stream\n<\/ul>\n
Of course, this is limited functionality, so it is left up to the reader to add things like:<\/p>\n
- \n
- updating the location of the device\n
- adding a new stream to a device\n<\/ul>\n
So, let’s dive in!<\/p>\n
First Things First<\/h2>\n
The example code provided at the end of the tutorial has only been tested on Linux, and everything done here is on an Ubuntu 14.04 system. To get up and running you will need to:<\/p>\n
- \n
- install Swift<\/a>\n
- install Postgres<\/a>\n
- create a Postgres database named
iot_staging<\/code>\n- create a Postgres user named
iotuser<\/code> with the passwordiotuser<\/code>\n<\/ul>\nThere are detailed instructions on these steps further below.<\/p>\n
Once the prerequisites are installed we’re going to use the Swift Package Manager to bootstrap in our Zewo dependencies. In a directory named
iotapp<\/code> create yourPackage.swift<\/code> file:<\/p>\n\nimport PackageDescription\n\nlet package = Package(\n name: \"iotapp\",\n dependencies:[\n .Package(url:\"https:\/\/github.com\/Zewo\/Epoch\", majorVersion:0, minor:1),\n .Package(url:\"https:\/\/github.com\/Zewo\/Middleware\", majorVersion:0, minor:1),\n .Package(url:\"https:\/\/github.com\/Zewo\/PostgreSQL\", majorVersion: 0, minor:1),\n ]\n)\n<\/pre>\n
and then run
swift build<\/code>. You will see the Swift Package Manager download and compile all of the required packages:<\/p>\n\nCloning Packages\/Epoch\nUsing version 0.1.0 of package Epoch\nCloning Packages\/HTTPParser\nUsing version 0.1.0 of package HTTPParser\nCloning Packages\/CHTTPParser\nUsing version 0.1.0 of package CHTTPParser\nCloning Packages\/HTTP\nUsing version 0.1.2 of package HTTP\nCloning Packages\/Core\nUsing version 0.1.1 of package Core\nCloning Packages\/CURIParser\nUsing version 0.1.0 of package CURIParser\nCloning Packages\/Venice\nUsing version 0.1.0 of package Venice\nCloning Packages\/CLibvenice\nUsing version 0.1.0 of package CLibvenice\nCloning Packages\/Middleware\nUsing version 0.1.0 of package Middleware\nCloning Packages\/Router\nUsing version 0.1.0 of package Router\nCloning Packages\/PostgreSQL\nUsing version 0.1.0 of package PostgreSQL\nCloning Packages\/SQL\nUsing version 0.1.0 of package SQL\nCloning Packages\/CLibpq\nUsing version 0.1.0 of package CLibpq\nCompiling Swift Module 'Core' (15 sources)\nLinking Library: .build\/debug\/Core.a\nCompiling Swift Module 'HTTP' (10 sources)\nLinking Library: .build\/debug\/HTTP.a\nCompiling Swift Module 'HTTPParser' (4 sources)\nLinking Library: .build\/debug\/HTTPParser.a\nCompiling Swift Module 'Venice' (21 sources)\nLinking Library: .build\/debug\/Venice.a\nCompiling Swift Module 'Epoch' (9 sources)\nLinking Library: .build\/debug\/Epoch.a\nCompiling Swift Module 'Router' (1 sources)\nLinking Library: .build\/debug\/Router.a\nCompiling Swift Module 'Middleware' (11 sources)\nLinking Library: .build\/debug\/Middleware.a\nCompiling Swift Module 'SQL' (6 sources)\nLinking Library: .build\/debug\/SQL.a\nCompiling Swift Module 'PostgreSQL' (5 sources)\nLinking Library: .build\/debug\/PostgreSQL.a\n<\/pre>\n
Note:<\/b> If the above bombed out it is likely due to missing dependencies. You don’t need to perform the bootstrap steps just yet, but if you’re chomping at the bit run the following:<\/p>\n
\nsudo apt-get install libpq-dev\necho \"deb [trusted=yes] http:\/\/apt.zewo.io\/deb .\/\" | sudo tee --append \/etc\/apt\/sources.list\nsudo apt-get update\nsudo apt-get install uri-parser http-parser libvenice \n<\/pre>\n
Anatomy of a Zewo REST Application<\/h2>\n
A Zewo REST application looks similar to other HTTP application stacks such as Rails<\/a>, Sinatra<\/a>, etc. At the top of the stack is the familiar HTTP Server. Zewo provides us with Epoch<\/a>, described as a Venice based HTTP server for Swift 2.2 on Linux<\/i>. A straightforward
main.swift<\/code> initializes our server:<\/p>\n\nimport Epoch\n\nServer(port:8080, responder:router).start()\n<\/pre>\n
Next down the stack is our routing functionality, which is an instance of Zewo Router<\/a>. The
router<\/code> is initialized inRouter.swift<\/code> which looks like this:<\/p>\n\nimport Router\nimport Middleware\n\nlet router = Router { route in\n route.router(\"\/api\", APIv1 >>> log)\n}\n<\/pre>\nThe
>>><\/code> admittedly looks like a little black magic. It is an overloaded operator defined in Zewo Middleware<\/a>. In this example it provides for logging our API actions.<\/p>\nThe
route.router(\"\/api\", APIv1 >>> log)<\/code> statement will anchor our web service at\/api<\/code>. Let’s look now atAPIv1.swift<\/code>:<\/p>\n\nimport HTTP\nimport Router\nimport Middleware\n\nlet APIv1 = Router(\"\/v1\") {\n route in\n route.get(\"\/version\") {\n _ in\n return Response(status: .OK,\n json:[\"version\":\"1.0.0\"])\n }\n\n \/\/ Create a new device\n route.post(\"\/devices\", parseJSON >>> deviceController.create)\n\n \/\/ Get a device\n route.get(\"\/devices\/:serial\", deviceController.show)\n\n \/\/ Post a datapoint to a stream\n route.post(\"\/devices\/:serial\/streams\/:name\/value\",\n parseJSON >>> datapointController.create)\n\n \/\/ Get values posted to a stream\n route.get(\"\/devices\/:serial\/streams\/:name\", datapointController.index)\n\n}\n<\/pre>\nAPIv1<\/code> is where the real action is happening. Our URL anchor point is now extended to\/api\/v1<\/code> and we’ve specified a number of specific routes from there:<\/p>\n- \n
GET \/api\/v1\/version<\/code>\nPOST \/api\/v1\/devices<\/code>\nGET \/api\/v1\/devices\/:serial<\/code>\nPOST \/api\/v1\/devices\/:serial\/streams\/:name\/value<\/code>\nGET \/api\/v1\/devices\/:serial\/streams\/:name<\/code>\n<\/ul>\nAgain, while not the richest API, it serves as starting point.<\/p>\n
If you’ve ever worked with Sinatra<\/a> you will recognize the named parameters<\/i> in the route patterns. These parameters, such as
:serial<\/code> and:name<\/code> will be provided to us in our controllers, which we’ll see next.<\/p>\nControllers<\/h3>\n
Zewo does all the heavy lifting of receiving an HTTP request and then routing the request to the appropriate controller<\/i>. It is here though where we have to pick up the request and do something with it.<\/p>\n
What is a controller again exactly? According to the Rails
ActionController<\/code><\/a> documentation a controller “is responsible for making sense of the request and producing the appropriate output”. This is what ourDeviceController<\/code> does for us:<\/p>\n\nimport Core\nimport HTTP\nimport Middleware\n\nlet deviceController = DeviceController()\n\nfinal class DeviceController {\n\n let devices = try! DeviceRecord()\n let streams = try! StreamRecord()\n\n func create(request:Request) -> Response {\n \n guard let json = request.JSONBody else {\n return Response(status:.BadRequest,\n json:[\n \"message\":\"No device definition found\"\n ])\n }\n\n guard let name = json[\"name\"]?.stringValue else {\n return Response(status:.BadRequest,\n json:[\n \"message\":\"name property missing\"\n ])\n }\n \n guard let serial = json[\"serial\"]?.stringValue else {\n return Response(status:.BadRequest,\n json:[\n \"message\":\"serial property missing\"\n ])\n }\n\n var streamName:String\n guard let streams = json[\"streams\"]?.arrayValue else {\n return Response(status:.BadRequest,\n json:[\n \"message\":\"streams property missing\"\n ])\n }\n \n \n var location = ZERO_POINT\n if let _location = json[\"location\"] {\n location[\"latitude\"] = _location[\"latitude\"]!.doubleValue!\n location[\"longitude\"] = _location[\"longitude\"]!.doubleValue! \n }\n\n if let device = devices.insert(name, serial:serial, location:location) {\n for s in streams {\n streamName = s[\"name\"]!.stringValue!\n let stream = self.streams.insert(streamName, deviceId:device.id)\n device.addStream(stream)\n }\n \n return Response(status:.OK, json:device.toJSON())\n } else {\n return Response(status:.BadRequest, json:[\n \"message\":\"error creating device\"\n ])\n }\n }\n}\n<\/pre>\nRecall that it was the
APIv1<\/code> router that callsdeviceController.create<\/code> when aPOST \/devices<\/code> is received. Thecreate<\/code> function takes aRequest<\/code> object as its only argument, and then returns aResponse<\/code>. In other words, the function is making sense of the request and producing the appropriate output<\/i>. Making sense of the request is broken down into distinct steps:<\/p>\n- \n
- obtaining the JSON body of the request and extracting required fields
name<\/code> andserial<\/code>\n- obtaining the location field if it is available, otherwise the location defaults to (0.0, 0.0)\n
- extracting the required
streams<\/code> field from the JSON\n- inserting a new
Device<\/code> into the database\n- inserting a new
Stream<\/code> for each stream specified\n<\/ul>\nThe response to this request can be one of two types:<\/p>\n
- \n
.BadRequest<\/code> (HTTP Status 400)\n.OK<\/code> (HTTP Status 200)\n<\/ul>\nIn both cases we return a JSON body with additional information.<\/p>\n
An example of a valid JSON request body for
POST \/devices<\/code> looks like this:<\/p>\n\n{\"name\":\"BeagleBone\",\n \"serial\":\"NATT-8GXF-B7GF-RXNC\",\n \"location\":{\n \"latitude\":-34.8836,\n \"longitude\":-56.1819\n },\n \"streams\":[]\n}\n<\/pre>\nIf the request was successful we expect a response to look like:<\/p>\n
\n{\n \"serial\": \"NATT-8GXF-B7GF-RXNC\",\n \"streams\": [],\n \"name\": \"BeagleBone\",\n \"location\": {\n \"longitude\":\"-56.1819\",\n \"latitude\":\"-34.8836\"\n },\n \"id\": \"14\"\n}\n<\/pre>\nThe server returned an additional field
id<\/code> in the JSON response. Some APIs are designed such that the client use theid<\/code> field for future references to the created object. Our API, on the other hand, will use the serial number to identify a given device.<\/p>\nRecords<\/h3>\n
Observe that the controller<\/i> does not interact directly with the database. That is the job of our record<\/i> class, which is modeled after the concept of
ActiveRecord<\/code><\/a> in Rails. TheDeviceRecord<\/code> class knows about Postgres, what table is used to manage devices (in fact, it creates that table), and how to insert and find devices. In RailsActiveRecord<\/code> is smart enough to read the table schema and create methods such asfind<\/code> on the fly. OurDeviceRecord<\/code> does not go that far; we aren’t building Rails here.<\/p>\nThis is the content of our
DeviceRecord.swift<\/code> file:<\/p>\n\nimport PostgreSQL\nimport CLibpq\nimport Foundation\n\nfinal class DeviceRecord {\n\n let tableName = \"devices\"\n let db = Connection(\"postgresql:\/\/iotuser:iotuser@localhost\/iot_staging\")\n\n init() throws {\n try db.open()\n try db.execute(\"CREATE TABLE IF NOT EXISTS \\(tableName) (id SERIAL PRIMARY KEY, name VARCHAR(256), serial VARCHAR(256) UNIQUE, location POINT)\")\n }\n\n deinit {\n db.close()\n }\n\n func insert(name:String, serial:String, location:Point) -> Device {\n\n let stmt = \"INSERT into \\(tableName) (name,serial,location) VALUES('\\(name)','\\(serial)',POINT(\\(location[\"latitude\"]!),\\(location[\"longitude\"]!))) RETURNING id\"\n \n logmsg(stmt)\n \n let result = try! db.execute(stmt)\n let id = result[0][\"id\"]!.string!\n return Device(id:id, name:name, serial:serial, location:location)\n }\n\n func findBySerial(serial:String) -> Device? {\n\n let stmt = \"SELECT * from devices where serial = '\\(serial)'\"\n \n logmsg(stmt)\n \n let result = try! db.execute(stmt)\n if result.count > 0 {\n let id = result[0][\"id\"]!.string!\n let name = result[0][\"name\"]!.string!\n let serial = result[0][\"serial\"]!.string!\n let location = result[0][\"location\"]!.string!\n let locationAsPoint = pointFromString(location)\n return Device(id:id, name:name, serial:serial, location:locationAsPoint)\n }\n return nil\n }\n\n}\n<\/pre>\nAt a fundamental level there really isn’t a whole lot going on in this file, with of course the exception that we are issuing Postgres SQL commands to the underlying database adapter and reading the result.<\/p>\n
Before leaving the
DeviceRecord<\/code>, notice thatinsert<\/code> returnsDevice<\/code>. This is not<\/i> a good idea, and we should change the implementation to returnDevice?<\/code> in the event there is an issue with the SQLINSERT<\/code>. The example code in Github will returnDevice?<\/code> so we can catch these errors.<\/p>\nCombining all the components together, top-to-bottom, we get a view of what the “stack” looks like:<\/p>\n
![\"Basic](\"http:\/\/dev.iachieved.it\/iachievedit\/wp-content\/uploads\/2015\/12\/Basic_Zewo_App.png\")
<\/a>Basic Web Service Stack<\/figcaption><\/figure>\n A Working Example<\/h2>\n
Now that we have a basic idea of how Zewo is used to build a REST web service, let’s run a working example.<\/p>\n
First, install of the dependencies you’ll need, which includes
libpq-dev<\/code> for the Postgres headers, as well as some additional packages Zewo requires.<\/p>\n\nsudo apt-get install libpq-dev\necho \"deb [trusted=yes] http:\/\/apt.zewo.io\/deb .\/\" | sudo tee --append \/etc\/apt\/sources.list\nsudo apt-get update\nsudo apt-get install uri-parser http-parser libvenice \n<\/pre>\n
Now, get the code from Github and switch to the
basic<\/code> branch.<\/p>\n\ngit clone https:\/\/github.com\/iachievedit\/iotapp\ncd iotapp\ngit checkout basic\n<\/pre>\n
Build the application with
swift build<\/code> and run it:<\/p>\n\nswift build\n.build\/debug\/iotapp\n<\/pre>\n
If Postgres isn’t running or cannot otherwise be contacted, you might see this error:<\/p>\n
\nfatal error: 'try!' expression unexpectedly raised an error: PostgreSQL.Connection.Error.ConnectFailed(\"could not connect to server: Connection refused\\n\\tIs the server running on host \\\"localhost\\\" (::1) and accepting\\n\\tTCP\/IP connections on port 5432?\\ncould not connect to server: Connection refused\\n\\tIs the server running on host \\\"localhost\\\" (127.0.0.1) and accepting\\n\\tTCP\/IP connections on port 5432?\\n\"): file swift\/stdlib\/public\/core\/ErrorType.swift, line 53\nIllegal instruction (core dumped)\n<\/pre>\n
In this case, install Postgres and create your user and database:<\/p>\n
\n$ sudo apt-get install postgresql\n$ sudo su - postgres\n$ psql template1\npsql (9.4.5)\nType \"help\" for help.\n\ntemplate1=# CREATE USER iotuser WITH PASSWORD 'iotuser';\nCREATE ROLE\ntemplate1=# CREATE DATABASE iot_staging;\nCREATE DATABASE\ntemplate1=# GRANT ALL PRIVILEGES ON DATABASE \"iot_staging\" to iotuser;\nGRANT\ntemplate1=# \\q\n$ exit\n<\/pre>\n
Once the application is up and running, we can use cURL or Postman to create a new device. Here we’ll use cURL:<\/p>\n
\n$ curl -X POST -H \"Content-Type: application\/json\" -d '{\"name\":\"BeagleBone\", \"serial\":\"N9TT-8GXF-B7GF-RXNC\", \"location\":{\"latitude\":-34.8836, \"longitude\":-56.1819}, \"streams\":[{\"name\":\"cpu-occupancy\"}, {\"name\":\"free-memory\"}]}' 'http:\/\/localhost:8080\/api\/v1\/devices'\n<\/pre>\nOur Zewo application processes the request, logging to STDOUT:<\/p>\n
\n12\/23\/15, 8:11 PM \/home\/iotapp\/iotapp\/Sources\/DeviceRecord.swift:23 insert(_:serial:location:): INSERT into devices (name,serial,location) VALUES('BeagleBone','N9TT-8GXF-B7GF-RXNC',POINT(-34.8836,-56.1819)) RETURNING id\nPOST \/api\/v1\/devices HTTP\/1.1\nContent-Type: application\/json\nAccept: *\/*\nUser-Agent: curl\/7.43.0\nHost: localhost:8080\nContent-Length: 200\n\n{\"name\":\"BeagleBone\",\n \"serial\":\"N9TT-8GXF-B7GF-RXNC\",\n \"location\":{\n \"latitude\":-34.8836,\n \"longitude\":-56.1819\n },\n \"streams\":[\n {\"name\":\"cpu-occupancy\"},\n {\"name\":\"free-memory\"}\n ]\n}\n-\nHTTP\/1.1 200 OK\ncontent-type: application\/json; charset=utf-8\nContent-Length: 128\n\n{\"id\":\"1\",\"name\":\"BeagleBone\",\"location\":{\"longitude\":-56.1819,\"latitude\":-34.8836},\"streams\":[],\"serial\":\"N9TT-8GXF-B7GF-RXNC\"}\n----------------------------------------\n<\/pre>\nThe response to our command is what we expect, a JSON string with our device!<\/p>\n
\n{\"id\":\"1\",\"name\":\"BeagleBone\",\"location\":{\"longitude\":-56.1819,\"latitude\":-34.8836},\"streams\":[],\"serial\":\"N9TT-8GXF-B7GF-RXNC\"}\n<\/pre>\nTry issuing the command again with the same serial number. You should see
{\"message\":\"error creating device\"}<\/code> thanks to the logic we added to return a.BadRequest<\/code> if we couldn’t insert the device.<\/p>\nCreating Streams and Posting Datapoints<\/h2>\n
We now need to add the functionality that creates
streams<\/code> anddatapoints<\/code>. Unlike withDevice<\/code> we do not need aStreamController<\/code>. Streams are created directly through aStreamRecord<\/code> instance in theDeviceController<\/code>.<\/p>\nOur
StreamRecord<\/code> code looks like this:<\/p>\n\nimport PostgreSQL\nimport CLibpq\nimport Foundation\n\nfinal class StreamRecord {\n\n let tableName = \"streams\"\n let db = Connection(\"postgresql:\/\/iotuser:iotuser@localhost\/iot_staging\")\n\n init() throws {\n try db.open()\n try db.execute(\"CREATE TABLE IF NOT EXISTS \\(tableName) (id SERIAL PRIMARY KEY, name VARCHAR(256), device_id INTEGER NOT NULL)\")\n }\n\n deinit {\n db.close()\n }\n\n func insert(name:String, deviceId:String) -> Stream {\n\n let stmt = \"INSERT into \\(tableName) (name, device_id) VALUES('\\(name)', '\\(deviceId)') RETURNING id\"\n \n logmsg(stmt)\n\n let result = try! db.execute(stmt)\n let id = result[0][\"id\"]!.string!\n return Stream(id:id, name:name)\n \n }\n\n func findByName(name:String, deviceId:String) -> Stream? {\n let stmt = \"SELECT * from \\(tableName) where name = '\\(name)' and device_id = '\\(deviceId)'\"\n \n logmsg(stmt)\n\n let result = try! db.execute(stmt)\n \n if result.count > 0 {\n return Stream(id:result[0][\"id\"]!.string!,\n name:result[0][\"name\"]!.string!)\n } else {\n return nil\n }\n }\n\n}\n<\/pre>\nNote that our
streams<\/code> schema definition containsdevice_id<\/code>, which is a reference to the device that “owns” the stream. Again, unlike with Rails, we are not specifyinghas_a<\/code> orbelongs_to<\/code> relationships explicitly; we manage this through code.<\/p>\nPosting Datapoints<\/h3>\n
A stream<\/i> is a collection of data points, or values. For example, let’s say our BeagleBone device had a temperature sensor attached to it. We would want to POST a temperature reading to the
temperature<\/code> stream, like this:<\/p>\n\ncurl -X POST -H \"Content-Type: application\/json\" -d '{\"value\":\"77\"}' 'http:\/\/localhost:8080\/api\/v1\/devices\/NFTT-8GXF-B7GF-RXNC\/streams\/temperature\/value'\n<\/pre>\nOur API responds with:<\/p>\n
\n{\n \"value\": \"77\",\n \"inserted_at\": \"2015-12-23 21:13:42.763442\",\n \"id\": \"1\"\n}\n<\/pre>\nSome time later the temperature increases to 78 degrees, so another value is posted. Later on, it increases to 80 degrees, and so on. Then, we can retrieve our datapoints via a GET request:<\/p>\n
\ncurl -X GET -H \"Content-Type: application\/json\" 'http:\/\/localhost:8080\/api\/v1\/devices\/NFTT-8GXF-B7GF-RXNC\/streams\/temperature'\n<\/pre>\n
The following data is returned:<\/p>\n
\n{\n \"datapoints\": [\n {\n \"value\": \"77\",\n \"inserted_at\": \"2015-12-23 21:13:42.763442\",\n \"id\": \"1\"\n },\n {\n \"value\": \"78\",\n \"inserted_at\": \"2015-12-23 21:15:30.536468\",\n \"id\": \"2\"\n },\n {\n \"value\": \"80\",\n \"inserted_at\": \"2015-12-23 21:15:54.651966\",\n \"id\": \"3\"\n }\n ]\n}\n<\/pre>\nHere is our implementation of
DatapointController<\/code>. Note how the methodsDeviceRecord.findBySerial(serial:)<\/code> andStreamRecord.findByName(name:,deviceId:)<\/code> are used to associate the datapoint with the correct device and stream.<\/p>\n\nimport Core\nimport HTTP\nimport Middleware\n\nlet datapointController = DatapointController()\n\nfinal class DatapointController {\n\n let devices = try! DeviceRecord()\n let streams = try! StreamRecord()\n let datapoints = try! DatapointRecord()\n\n func create(request:Request) -> Response {\n\n logmsg(\"ENTRY\")\n\n let deviceSerial = request.parameters[\"serial\"]!\n let streamName = request.parameters[\"name\"]!\n\n guard let json = request.JSONBody, value = json[\"value\"]?.stringValue else {\n return Response(status:.BadRequest)\n }\n\n guard let device = devices.findBySerial(deviceSerial) else {\n return Response(status:.NotFound)\n }\n\n guard let stream = streams.findByName(streamName, deviceId:device.id) else {\n return Response(status:.NotFound)\n }\n\n if let datapoint = datapoints.insert(value, streamId:stream.id) {\n return Response(status:.OK, json:datapoint.toJSON())\n }\n \n return Response(status:.BadRequest)\n\n }\n \n func index(request:Request) -> Response {\n logmsg(\"ENTRY\")\n\n let deviceSerial = request.parameters[\"serial\"]!\n let streamName = request.parameters[\"name\"]!\n\n guard let device = devices.findBySerial(deviceSerial) else {\n return Response(status:.NotFound)\n }\n\n guard let stream = streams.findByName(streamName, deviceId:device.id) else {\n return Response(status:.NotFound)\n }\n\n let values = datapoints.findByStream(stream.id, count:10)\n let jsonValues = [\n \"datapoints\":JSON.from(values)\n ]\n\n return Response(status:.OK, json:JSON.from(jsonValues))\n \n }\n\n}\n<\/pre>\nOur
DatapointRecord<\/code> implementation looks like:<\/p>\n\nimport PostgreSQL\nimport CLibpq\nimport Foundation\n\nfinal class DatapointRecord {\n\n let tableName = \"datapoints\"\n let db = Connection(\"postgresql:\/\/iotuser:iotuser@localhost\/iot_staging\")\n\n init() throws {\n try db.open()\n try db.execute(\"CREATE TABLE IF NOT EXISTS \\(tableName) (id SERIAL PRIMARY KEY, inserted_at TIMESTAMP WITHOUT TIME ZONE DEFAULT (now() AT TIME ZONE 'utc'), value TEXT, stream_id INTEGER NOT NULL)\")\n }\n\n deinit {\n db.close()\n }\n\n func insert(value:String, streamId:String) -> Datapoint? {\n\n let stmt = \"INSERT into \\(tableName) (value, stream_id) VALUES('\\(value)', '\\(streamId)') RETURNING id, inserted_at\"\n logmsg(\"insert datapoint: \\(stmt)\")\n\n do {\n let result = try db.execute(stmt)\n let id = result[0][\"id\"]!.string!\n let inserted_at = result[0][\"inserted_at\"]!.string!\n logmsg(\"datapoint inserted with id \\(id)\")\n return Datapoint(id:id, value:value, inserted_at:inserted_at)\n } catch {\n return nil\n }\n \n }\n\n func findByStream(streamId:String, count:Int) -> [Datapoint] {\n let stmt = \"SELECT * FROM \\(tableName) WHERE stream_id = \\(streamId) LIMIT \\(count)\"\n\n logmsg(stmt)\n\n var datapoints:[Datapoint] = []\n do {\n let results = try db.execute(stmt)\n for result in results {\n let id = result[\"id\"]!.string!\n let value = result[\"value\"]!.string!\n let inserted_at = result[\"inserted_at\"]!.string!\n let datapoint = Datapoint(id:id, value:value, inserted_at:inserted_at)\n datapoints.append(datapoint)\n }\n return datapoints\n } catch {\n return []\n }\n }\n}\n<\/pre>\nAn exercise for the reader:<\/b> The
DatapointRecord.findByStream(streamId:count:)<\/code> function is called with a hardcoded value of 10. Extend the API to allow for the number of datapoints to be specified either by a JSON structure in the POST body, or through a URI query parameter. Consider also addinginserted_before<\/code> andinserted_after<\/code> filters to control which values to return.<\/p>\nComplete Application<\/h2>\n
- install Postgres<\/a>\n
- install Swift<\/a>\n