Соглашение об именах бэкэнда / внешнего интерфейса / API - PullRequest
Новая
       61

Соглашение об именах бэкэнда / внешнего интерфейса / API

0 голосов
/ 12 марта 2020

Например, у нас есть 2 микросервиса, написанные Java, C#. Фронт-энд с Typescript. Java использует регистр верблюдов и имеет один GET с параметрами запроса и ответом JSON, C# использует pascal регистр и имеет один GET с параметрами запроса и ответом JSON. TypeScript использует регистр верблюдов и оба GET.

Первый вопрос: нужно ли использовать разные регистры для параметров запроса и JSON внутри GET (C# - pascal case и Java - верблюжий case) или нам нужно использовать одно соглашение для всех источников? Также параметры запроса и JSON должны иметь одинаковые регистры, не так ли?

Второй вопрос: если у меня уже был какой-то API с параметрами запроса и JSON в случае pascal. Нужно ли мне написать "нормализатор" для сопоставления pascal случая с верблюдом? С моей точки зрения, у frontend, backend и API могут быть разные соглашения, но разработчики должны отображать данные, поступающие из другого места. Но может быть слишком сложно написать множество «сериализаций» для внешнего интерфейса для всех данных из API.

Исходя из моего опыта, я разработал проект, в котором все части использовали верблюжий корпус, но также я разработал приложение, в котором использовались бэкэнд и API. pascal Кейс и фронтенд использовали верблюжий кейс, но у меня были некоторые проблемы с последним.

Просто хочу узнать ваше мнение об этой теме и узнать, как вы это делаете? Был бы рад увидеть ваши собственные примеры и опыт. Большое спасибо!

1 Ответ

0 голосов
/ 12 марта 2020

У нас был один и тот же вопрос в проекте, над которым я сейчас работаю, несколько недель go, и мы рассмотрели эти моменты:

  1. Мы хотели, чтобы сущности с «publi c лицом к лицу» имели то же самое соглашение (конечные точки, JSON DTOs и c.)
  2. Мы хотели различить guish между функциями / методами и переменными
  3. Мы не хотели влиять на усвоенное поведение внутри технологии договорились о том, чтобы ключи в JSON были snake_case для удобства чтения, а также имена переменных, если язык не слишком мнителен (т. е. мы использовали snake_case для JavaScript, но не для Java).

    Далее мы договорились о том, что конечными точками является camelCase, поскольку это метод / функция, подобная конструкции. Мы выбрали camelCase вместо PascalCase, поскольку PascalCase может вводить в заблуждение в отношении имен классов, обычно являющихся PascalCase. Мы даже взяли CamelCase для JavaScript функций.

    До сих пор это прекрасно работает. Надеюсь, это поможет.

...