REST exposes data through resource-oriented HTTP endpoints. For a digital twin, separate paths can identify rooms, sensors, and measurements. This is useful when a client needs a specific resource, but following relationships across many resources can require several requests. section 5.6.2
Following rooms to temperature readings
To find the current temperature in every second-floor room, request GET /floors/2/rooms, then GET /rooms/{id}/sensors for each room, then GET /sensors/{id}/measurements/latest for each sensor. The requests are sequential because each step supplies identifiers for the next. Hiding that traversal behind one endpoint may be convenient, but calling the result REST does not, by itself, make it strictly RESTful. section 5.6.2
An external API can also supply data a twin does not collect itself. NASA’s GIBS interface provides VIIRS satellite imagery that could add context to reservoir, agricultural, or urban-heat monitoring. A Python request for a Lake Kariba image specifies a bounding box, date, layer, dimensions, and PNG format, then writes the response to a file. section 4.4.3
Listing 4.8 Using the NASA GIBS RESTful API to retrieve an image of Lake Kariba
import requests
from datetime import datetime, timedelta
bbox = (26.5, -18.5, 29.0, -16.0) #1
yesterday = (datetime.now() - timedelta(1)).strftime('%Y-%m-%d')
params = {
'SERVICE': 'WMS',
'VERSION': '1.1.1',
'REQUEST': 'GetMap',
'LAYERS': 'VIIRS_SNPP_CorrectedReflectance_TrueColor',
'SRS': 'EPSG:4326',
'BBOX': f'{bbox[0]},{bbox[1]},{bbox[2]},{bbox[3]}',
'WIDTH': '1024',
'HEIGHT': '640',
'FORMAT': 'image/png',
'TIME': yesterday,
'TRANSPARENT': 'true'
}
response = requests.get( #2
'https://gibs.earthdata.nasa.gov/wms/epsg4326/best/wms.cgi',
params=params)
filename = f'lake_kariba_{yesterday}.png'
with open(filename, 'wb') as f:
f.write(response.content)
The listing shows the request parameters, Python requests.get call, and saved image file. section 4.4.3
Choose an API shape with the data relationships in mind. REST’s resource-specific endpoints have fixed response shapes; for a query spanning rooms, sensors, and readings, OData can expand related data in one request, while GraphQL lets the client specify the required fields in one query. section 5.6.2
Table 5.1 A comparison of API protocols that can serve data from a digital twin
|
Protocol
|
Architecture
|
Query mechanism
|
Efficiency for complex data
|
|---|---|---|---|
|
REST
|
Multiple resource-specific endpoints, such as
/rooms and
/sensors
|
Fixed server responses; rigid data shape
|
Low. Requires multiple sequential requests.
|
|
OData
|
Standardized protocol built on REST principles
|
Flexible querying via URL parameters (
$filter,
$select,
$expand)
|
Moderate. Allows clients to request related data in a single request using
$expand, improving efficiency over REST.
|
|
GraphQL
|
Single endpoint (
$graphql)
|
Client-defined query language specifying exact data needs
|
High. Addresses over-fetching; retrieves all required data across relationships in a single round trip.
|
The comparison table makes the request-count and response-shape tradeoffs visible. section 5.6.2
