lowerCamelCase и алиасы

[nonamegithub]

С удовлетворением отметил использование lowerCamelCase в нейминге параметров запросов WebSocket proxy:

{
  "subscribeInfoRequest": {
    "subscriptionAction": "SUBSCRIPTION_ACTION_SUBSCRIBE",
    "instruments": [
      {
        "instrumentId": "962e2a95-02a9-4171-abd7-aa198dbe643a"
      }
    ]
  }
}

Вижу почерк профессионала)

Однако, чтобы начать использовать новый функционал, придется немало повозиться, так как аналогичные методы gRPC используют нейминг в стиле: subscription_action, instrument_id. Вдобавок, не хочется поганить свой код лишними проверками. Уже прошел один раз через это при переходе с REST на gRPC - имена одних и тех же параметров аналогичных методов зачастую вообще не были похожи друг на друга.

Итак, вопрос к разработчикам: насколько сложно будет добавить в запросы WebSocket proxy алиасы параметров методов, используемых в gRPC-стримах? Ну, а если при этом еще в gRPC-методы будут добавлены алиасы в стиле lowerCamelCase, то пользователи API без проблем смогут потихоньку переходить на новый стиль нейминга.

[nonamegithub]

Благодарю, Александр! Не буду даже акцентировать внимание на том, что и имена полей, возвращаемые в структурах данных результатов выполнения методов, тоже должны либо быть продублированы с альтернативными названиями, либо должны быть возвращены в стиле, использованном в запросе.

[AlexanderVolkovTCS]

Реализовано