server - define api

[gardleopard]

Decide initial schema for our api.

suggestion:

{
  "name" : "featureName",
  "status" : "on/off/custom",
  "customKey" : "user",
  "customValue" : "beta,employee",
  "activeFrom" : "2012-04-23T18:25:43.511Z",
  "activeTo" : "2012-04-23T18:25:43.511Z"
}

[eirslett]

{
  "name": "featureName",
  "status": 0,
  "parameters": {
    "foo": "bar",
    "baz": 3
  }
}

works well for JSON deserializers; you get a type-safe Feature with a Map<String,String> parameter map. I think that's what the MVP uses.

[jarib]

👍 for @eirslett's proposal

1. Parameters should definitely be an object, not a string.
2. Your parameters example has a number in it, so it's not a Map<String, String>. Typo?
3. I think it's OK to keep the status property as a human-readable string.

[ivarconr]

Instead of calling it custom, could we not just keep it as "strategy" as this is a well concept in the feature-toggle domain. And also it is much simpler for the generic-client if we say that parameters are always Map<string, string>.

The bigger question is whether we need multiple parameters for an activation strategy, or if we always only require one parameter? In all "known" strategies it would work just fine with one parameter (with the exception of activation by date (from-to).

{
  "name": "featureName",
  "status": "on/off/custom",
  "strategy": "by_user",
  "parameters": {
    "foo": "bar",
    "baz": "3"
  }
}

[gardleopard]

Landed on:

{
  "name": "featureX",
  "status": "on/off",
  "strategy": "strategyX",
  "parameters": {
    "foo": "bar"
  }
}

[Andersos]

There has been a update to the api:

{
  "name": "featureX",
  "description": "Description",
  "enabled": true/false,
  "strategy": "strategyX",
  "parameters": {
    "foo": "bar"
  }
}

Edit after @jarib comment. enabled is boolean but was written with quotes.

[jarib]

Why not just boolean true/false instead of encoding it as a string?

[Andersos]

👍 see edit.