Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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

Restriction:

  • username must be unique

Characteristics:

  • Additional API on "/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, ...)


Extension of data-provider

OperationExpected result
GET /data-provider:userdata/{username}Gets the settings of a specified user
POST /data-provider:userdata/{username}Creates a settings entry for a specified user
PUT /data-provider:userdata/{username}Creates/Updates settings entry of a user
DELETE /data-provider:userdata/{username}Deletes settings entry of a user

Example settings data of a user

{
    "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

  • No labels