API и бизнес-логика

Пост для новичков в профессии

В цикле постов про архитектуру информационных систем, я рассказывала про то, как вообще развивались системы, почему вообще бизнес-логика перешла на сервера и т.д. Но, когда у нас есть API, здесь, конечно, иногда возникает хаос. Но по сути надо запомнить простое правило: если правило влияет на поведение системы, оно должно быть в API! 

Рассмотрим на примере: есть заказ со статусами.

Плохой вариант реализации: API отдает список статусов, а фронт сам решает:
• какой показывать
• какой считать финальным
• какой доступен пользователю

Как надо: API возвращает текущий статус, доступные действия, ограничения. 

То есть мы действуем по правилам: 

1. Логика должна быть в одном месте
Иначе разные клиенты ведут себя по-разному, появляются расхождения, а баги сложно воспроизводить

2. API – это контракт, а не «данные на подумать»
Фронт не должен гадать, что делать с данными, он должен просто их использовать

А в результате упрощается развитие системы, т.к. когда логика централизована проще вносить изменения и масштабировать систему.

Но есть и обратная крайность, когда в API начинают тащить всё подряд: UI-логику, форматирование, лишние вычисления.

Поэтому запомните: 
• API – это бизнес-правила и поведение • Фронт – это отображение и UX

И расти вы начинаете, когда вы думаете не просто какие данные передать, а когда задаёте себе вопрос: где должна жить логика, чтобы через полгода система не превратилась в хаос.