[Question] Why are some configuration keys changed to snake_case while others are still camelCase?

[JProvAnt]

Release version

v7.0.0-alpha.3.0.0

Question Details

Since v7alpha3 some configuration keys use snake_case, like named_values, service_policies, version_sets. However many keys still use camelCase, like apimServiceName, displayName, loggerId etc.

Why are some snake_case and others still camelCase? I find this personally super confusing and inconsistent.

For example below the new configuration.extractor.yaml example, why is workspaceName1 camelCase and then further below named_values is snake_case? To me this seems strange to mix naming conventions like this.

workspaces:
  - workspaceName1:
      apis:
        - workspaceApiName1:
            operations: []
            diagnostics: []
            schemas: []
            releases:
              - workspaceReleaseName1
      backends:
        - workspaceBackendName1
      diagnostics: []
      groups: []
      loggers:
        - workspaceLoggerName1
      named_values:
        - workspaceNamedValueName1
      policy_fragments:
        - workspacePolicyFragmentName1
      products:
        - workspaceProductName1
      subscriptions: []
      tags:
        - workspaceTagName1
      version_sets:
        - workspaceVersionSetName1

Expected behavior

Either all keys should use camelCase as it previous was or all keys should use snake_case.

Actual behavior

Some keys are camelCase, some are snake_case.

Reproduction Steps

None

[github-actions]

  Thank you for opening this issue! Please be patient while we will look into it and get back to you as this is an open source project. In the meantime make sure you take a look at the [closed issues](https://github.com/Azure/apiops/issues?q=is%3Aissue+is%3Aclosed) in case your question has already been answered. Don't forget to provide any additional information if needed (e.g. scrubbed logs, detailed feature requests,etc.).
  Whenever it's feasible, please don't hesitate to send a Pull Request (PR) our way. We'd greatly appreciate it, and we'll gladly assess and incorporate your changes.

[guythetechie]

@JProvAnt - the only things that are changed to snake case are resource keys. And by resource keys, I mean the keys that indicate resource types (apis for APIs, named_values for named values, policy_fragments for policy fragments, etc).

In the example above, workspaceName1 is the value of your workspace name. The casing could be workspace-name-1, workspace_name_1, or whatever. It has to match whatever name you defined in APIM. Other properties (displayName, loggerId, etc) are dictated by the APIM REST API (e.g) and again have to match whatever the API says.

As a rule of thumb, configuration keys we control use case-insensitive snake casing. Our code treats resource types as configuration keys. We have sometimes supported exceptions (e.g. apimServiceName vs API_MANAGEMENT_SERVICE_NAME for legacy reasons), but the default is snake case. Also, the configuration YAML is just one of many sources we support; others use environment variables, exe switches, etc.

[JProvAnt]

@guythetechie Thanks for the quick response. Is it maybe possible in the future to support both camelCase and snake_case for resource keys?

[guythetechie]

I think it should be relatively straightforward, but the devil is in the details. Will look into it. I can definitely empathize with being driven crazy by minor inconsistencies...

[pmhofman-se]

Why is the key named_values, but the folder name "named values" in the export? Please just leave the underscore in. Spaces in folder names are horrible.

BTW, the configuration file in the root of the repo still contains camelCase keys.

[guythetechie]

Thanks for the feedback. The main branch is still on v6, which uses camelCase for configuration keys. We'll update the root configuration file on main as needed once v7 is released.

As for folder names, those have had spaces for as long as I can remember (at least several years). Breaking two configuration files as we do in v7 is not ideal, but it's manageable. Breaking everybody's folder structure is a step too far though, unless there's a very compelling reason to do so.

[guythetechie]

@pmhofman-se - we've reverted back to camelCase in our latest beta release.