To be able to save user-specific data, such as settings for the NetworkMap (customization options) or the dashboard, the data-provider (Data-Provider) should be extended.
Goal:
- 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
- no 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 in bundle data-provider
- 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
- model is using camelCase for properties
- subItems have to be also JSONObjects, not Arrays or simple types.
Open Questions:
- when should the initial settings entry of a user be created? When settings are updated / saved for the first time?
- UI is responsible for data-structure → so initial data is writting by UI
- empty data on server will return empty json object: "{}"
- 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?
- PUT!
- partial will be implemented
- If we use PUT, do we need POST?
- no
- Should settings be queryable by section? ( eg. dashboard, networkmap, ...)
- filter only for root element key
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.
Extension of data-provider
Operation | Expected result |
---|---|
GET /userdata | Gets all the settings of a specified user |
GET /userdata/{key} | Gets the subsettings of a spefic user for rootElem[key] |
PUT /userdata | Creates/Updates settings entry of a user |
PUT /userdata/{key} | Creates/Updates settings entry of a user for rootElem[key] |
DELETE /userdata | Deletes settings entry of a user |
DELETE /userdata/{key} | 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
{ "networkMap":{ "startupPosition": {"lat": 52.5095, "lon":13.3290, "zoom": 10}, "tileOpacity": 90, "styling":{ "theme": "light" } }, "dashboard":{ "color":"#F00" } }
GET /userdata/networkMap
{ "startupPosition": {"lat": 52.5095, "lon":13.3290, "zoom": 10}, "tileOpacity": 90, "styling":{ "theme": "light" } }
Write settings data of a user
PUT /userdata
{ "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
{ "startupPosition": {"lat": 52.5095, "lon":13.3290, "zoom": 10}, "tileOpacity": 90, "styling":{ "theme": "light" } }
Note: settings data currently subject to change, note will be deleted once finalized