The development blog is there to keep you up to date with the latest Lighthouse releases and includes various tutorials about using our API and Message Queue, as well as posts about the latest development in connected device and sensor technology.
READ THE BLOG >The Lighthouse API is organised around REST and served by the HTTP transport protocol. Data is returned from the API in JSON format and standard HTTP status codes are used to indicate success and failure of client requests. JSON returned by the API contain hypermedia links in order to facilitate HATEOS. All requests and responses must take place over HTTPS. For security reasons, HTTP requests are not supported.
Lighthouse Reference>The Lighthouse API is organised around REST and served by the HTTP transport protocol. Data is returned from the API in JSON format and standard HTTP status codes are used to indicate success and failure of client requests. JSON returned by the API contain hypermedia links in order to facilitate HATEOS. All requests and responses must take place over HTTPS. For security reasons, HTTP requests are not supported.
The following code sample retrieves an access token from the Lighthouse Identity Server and uses that token to request a collection of Device resources:
The Lighthouse Message Queue is an AMQP based outbound message queue that allows an authenticated subscriber to consume high volume Device data. The Lighthouse Platform creates Data Packets, Check Ins and Events as Device data processing artefacts which are securely published as message to queues consumed by your business systems. The messages contain a JSON formatted body which can be easily read by the client allowing the creation of custom business workflows based on near real time Device data.
The current version of the Connect Message Queue publishes all Check-Ins and Events for all Devices that are associated with the Head Account Message Queue subscription. This includes Devices that are associated with any Child Accounts.
All Connect Message Queue Subscriptions will only be accessible using a single set of credentials, meaning for each subscription there is a specific username and password (Issuer and Key) which gives access only to that particular Subscription and only with the Read permission.
The connection string will be in the following format for most .NET clients:
The following code sample retrieves an access token from the Lighthouse Identity Server and uses that token to request a single Device resource: