Developer friend field naming for x-osb-cmdb - Githubissues

orange-cloudfoundry / osb-cmdb

A configuration management db for Open Service Broker API broker implementations

Apache License 2.0

14 stars 1 forks source link

Developer friend field naming for x-osb-cmdb #100

Open gberche-orange opened 3 years ago

gberche-orange commented 3 years ago

Expected behavior

As a service broker author

in order to consume the osb api extension x-osb-cmdb with automatic field mapping
I need the field name to be valid in my programming language

Observed behavior

x-osb-cmdb uses dash character which is not supported in field name in

python: requires a custom decoder see https://docs.python.org/3/library/json.html#json.JSONDecoder
javascript: https://stackoverflow.com/questions/29482226/json-object-with-dash-character-on-element-name

Use of _ would be more developer friendly.

Affected release

Reproduced on version 1.4.0

Alternative fixes

introduce a new field x_osb_cmdb. Document x-osb-cmdb as deprecated but keep it.
introduce a new field x_osb_cmdb. Remove x-osb-cmdb field from requests (breaking change)
introduce a new field x_osb_cmdb. add opt-in to keep x-osb-cmdb (likely as user-facing a catalog tag/metadata)

Impacts of 1) :

more verbose payload
confusions for service broker authors to see duplicated fields

Impacts of 2) :

service brokers with existing updateable service instances need to support both variations x_osb_cmdb and x-osb-cmdb (since once the breaking change is deployed they will receive updates including x_osb_cmdb param

Impacts of 3)

user-facing opt-in somewhat damages UX
implementation complexity for osb-cmdb