-
Notifications
You must be signed in to change notification settings - Fork 2
Service Properties
Some entities in the SolarNetwork API include a serviceProperties property that is an arbitrary
map data structure using string keys and arbitrary values. In JSON this is expressed as a JSON
object, for example:
{
"apiKey": "{SSHA-256}aQrTEQH1rQoe...",
"sourceIdMap": {
"/123789/inv/98765": "/INV/1"
},
"virtualSourceIds": [
"/GEN/1"
]
}Usually only specific keys in this mapping are supported by the associated entity type, however SolarNetwork does not usually restrict what entries are included in the mapping.
Some APIs offer a PATCH endpoint to merge changes into an entity's service properties. This is a
convenient way to add or update the service properties, without having to post the entire object.
The body of the PATCH request is a JSON object with just the properties you need to add or change.
These PATCH endpoints will support a mode query parameter that can alter the way nested objects
and lists within the service properties object are merged.
The default merge mode is Simple. In this method, only top-level keys are merged. For any
top-level key you provide in the PATCH request, it will be added to the existing service
properties if that key does not already exist, or it will replace that entire top-level key if
it does exist.
Assuming an entity has the service properties shown at the top of this page, imagine sending a
PATCH request with a mode=Simple query parameter (or no mode parameter at all) with this
content:
{
"alternateName": "Big Solar Farm",
"sourceIdMap": {
"/123789/inv/98766": "/INV/2"
},
"virtualSourceIds": [
"/GEN/2"
]
}the resulting service properties would look like this:
{
"alternateName": "Big Solar Farm",
"apiKey": "{SSHA-256}aQrTEQH1rQoe...",
"sourceIdMap": {
"/123789/inv/98766": "/INV/2"
},
"virtualSourceIds": [
"/GEN/2"
]
}☝️ Notice how the
sourceIdMapobject andvirtualSourceIdsarray were completely replaced by thePATCHcontent. ThealternateNameproperty was added, and theapiKeyproperty was preserved from the original service properties.
The RecursiveObjects merge mode combines changes from arbitrarily nested objects within the service
properties object. Following on from the example in the Simple section, if we
sent the same PATCH request but with a mode=RecursiveObjects query parameter, the outcome would
change to this:
{
"alternateName": "Big Solar Farm",
"apiKey": "{SSHA-256}aQrTEQH1rQoe...",
"sourceIdMap": {
"/123789/inv/98765": "/INV/1",
"/123789/inv/98766": "/INV/2"
},
"virtualSourceIds": [
"/GEN/2"
]
}☝️ Notice how the
sourceIdMapobject now contains entries from both the original service properties and thePATCHrequest. ThevirtualSourceIdsarray was still completely replaced by thePATCHcontent, however.
The RecursiveObjectsAndArrays merge mode combines changes from arbitrarily nested objects and
arrays within the service properties object. Following on from the example in the
Simple section, if we sent the same PATCH request but with a
mode=RecursiveObjectsAndArrays query parameter, the outcome would change to this:
{
"alternateName": "Big Solar Farm",
"apiKey": "{SSHA-256}aQrTEQH1rQoe...",
"sourceIdMap": {
"/123789/inv/98765": "/INV/1",
"/123789/inv/98766": "/INV/2"
},
"virtualSourceIds": [
"/GEN/1",
"/GEN/2"
]
}☝️ Notice how the
sourceIdMapobject andvirtualSourceIdsarray contain entries from both the original service properties and thePATCHrequest.
- SolarNetwork API access
- SolarNetwork API authentication
- SolarNetwork API rate limiting
- SolarNetwork global objects
- SolarNetwork aggregation
- SolarFlux API
- SolarIn API
- SolarQuery API
-
SolarUser API
- SolarUser enumerated types
- SolarUser datum expire API
- SolarUser datum export API
- SolarUser datum import API
- SolarUser datum stream alias API
- SolarUser event hook API
- SolarUser location request API
- SolarUser Cloud Integrations API
- SolarUser DIN API
- SolarUser DNP3 API
- SolarUser ININ API
- SolarUser OCPP API
- SolarUser OSCP API
- SolarUser Secrets API
- SolarUser SolarFlux API