Comments 5
Спасибо за труд! Полезный гайд, стандартизация сильно экономит время. А как вы решаете эту задачу между командами?
В БД мы используем snake_case
Мы придерживаемся стиля snake_case, т.к. при чтении меньше когнитивная нагрузка. Но разделение стилей БД с API - хорошая идея.
Но разделение стилей БД с API - хорошая идея.
Почему?
я придерживаюсь такого разделения на основании документации по технологиям
Например если заглянуть в официальную доку postgresql, там все аттрибуты в БД указаны через snake_case. И раз авторы технологии так указали, я решила следовать этому стилю при работе с базой
во всех официальных туториалах javascript переменные в основном называются через camelCase, поэтому при работе с JSON (javascript нотация ведь), придерживаюсь такого стиля
ну а где JSON в API, там и остальные параметры, поэтому их в ту же корзинку
не претендую, конечно, на истину, но у меня были такие размышления
А потом записать это в какое-то формальное описание, и валидировать каждую спеку API в пайплайне CI/CD, да ведь? Типа Swagger API Style Validator или API Design System?
да
недавно изучала white paper: "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency" https://dl.acm.org/doi/10.1145/3613905.3650803
в рамках исследования авторы оценивали влияние применения гайдлайнов и линтеров на качество и скорость разработки API
Результаты показали, что совместное и раздельное использование этих инструментов статзначимо увеличивает производительность создания API и улучшает его с точки зрения пользовательского опыта. Кроме того, они обучили ИИшку на ревью и генерации спецификаций API. И тоже получили хороший результат
Контракт REST API: Пригладим названия