Thing-Centric vs. Traditional Query Approaches
In a relational database, physical assets are records in a table. That table has multiple sub-tables with different data about the assets and a foreign key back to the asset table. There can be multiple layers of hierarchy and relationships. An application developer builds queries against the database, asking questions using standard SQL syntax and using a variety of JOIN and WHERE clauses. For example, to access the historical data for a lawn tractor, you could form a query similar to the following:
Select Asset.Name, LawnTractorHistory.timestamp, LawnTractorHistory.location, LawnTractorHistory.temperature
From Asset, LawnTractorHistory
Where Asset.ID = LawnTractorHistory.AssetID and
LawnTractorHistory.timestamp is between [querystart] and [queryend]
You would then write code to process the result set from the query. You repeat this process to build your solution.
As you build your model, ThingWorx dynamically expands the REST API layer to access those capabilities and functions. The API pattern is relatively simple. If you want a list of Things, you ask:
https:<Server>/Thingworx/Things
and you get a list of the Things in the model to which you have access. If you type:
https:<Server>/Thingworx/Things/<thingName>
you get a list of the properties, services, and other capabilities of the specified Thing. You can drill down through the list since it is a browsable name space.
The same pattern is available for the entire Thing model. Try:
https:<Server>/Thingworx/Server
and you get a list of all entities. You can click through and experiment.