...
- Provide a function to GET settings data by username
- Provide a function to POST / (PUT / PATCH?) settings data for a specific user
- Provide a function to DELETE settings data of a specific user
Restriction:
- username must be uniqueno clear payload data structure definition to keep it as flexible as possible => what is written, can be requested
Characteristics:
- user gets identified by token (basicAuth or JWT)
- Additional API on "/in bundle data-provider:userdata"
- Create a settings entry in the database if none exists
- Delivers back all settings of a user
- Updates the settings of a user
- Can delete (reset) settings of a user
Open Questions:
- when should the initial settings entry of a user be created? When settings are updated / saved for the first time?
- Use PUT or PATCH for updating entries? (settings may grow over time, eg. dashboard, networkmap, ...) Should the entire settings object be send or only a partial one?
- If we use PUT, do we need POST?
- Should settings be queryable by section? ( eg. dashboard, networkmap, ...)model is using camelCase for properties
- subItems have to be also JSONObjects, not Arrays or simple types
- UI is responsible for data-structure → initial data is written by UI
- empty data on server will return empty json object: "{}"
- partial updates and requests are possible ( (filter) by root element key, see examples)
Default values for deployment
It is now possible to deploy a default userdata file ($ODL_HOME/etc/userdata-defaults.json) into the SDNC container which delivers a merge of its values and the DB entry of the userdata.
Global settings for all users should be placed here, for example, available themes for the Network Map.
Extension of data-provider
Operation | Expected result | ||
---|---|---|---|
GET /data-provider:userdata/{username} | Gets all the settings of a specified userPOST | ||
GET / | data-provider:userdata/{ | usernamekey} | Creates a settings entry for a specifiedGets the subsettings of a specific user for rootElem[key] |
PUT /userdata | Creates/Updates settings entry of a user | ||
PUT / | data-provider:userdata/{ | usernamekey} | Creates/Updates settings entry of a user for rootElem[key] |
DELETE /userdata | Deletes settings entry of a user | ||
DELETE / | data-provider:userdata/{ | usernamekey} | Deletes settings entry of a user |
...
for rootElem[key] |
In fact, that jetty servlets can also handle camelCase URLs it is easily possible to filter for the correct property.
Examples
Read settings data of a user
GET /userdata
Code Block |
---|
{ "networkMap":{ "startupPosition": {"lat": 52.5095, "lon":13.3290, "zoom": 10}, "tileOpacity": 90, "styling":{ "theme": "light" } }, "networkMapThemes":{ "themes": [ {"key": "light", "site": "#11b4da", "selectedSite": "#116bda", "fiberLink": "#1154d9", "microwaveLink": "#039903"} ] } |
...
,
"dashboard":{
"color":"#F00"
}
} |
GET /userdata/networkMap
Code Block |
---|
{
"startupPosition": {"lat": 52.5095, "lon":13.3290, "zoom": 10},
"tileOpacity": 90,
"styling":{
"theme": "light"
}
} |
Write settings data of a user
PUT /userdata
Code Block |
---|
{
"networkMap":{
"startupPosition": {"lat": 52.5095, "lon":13.3290, "zoom": 10},
"tileOpacity": 90,
"styling":{
"theme": "light"
}
},
"dashboard":{
"color":"#F00"
}
} |
Write partial settings data of a user
PUT /userdata/networkMap
Code Block |
---|
{
"startupPosition": {"lat": 52.5095, "lon":13.3290, "zoom": 10},
"tileOpacity": 90,
"styling":{
"theme": "light"
}
} |