Наше API было создано на .net framework 4.5, который уже устарел. Поэтому недавно мы перешли на .Net 6 и начали налаживать внутреннюю архитектуру и процессы взаимодействия между бэкенд частью и фронтендом (React-приложением). Хотим поделиться опытом проектирования и разработки API на .Net 6 и рассказать, какие методы и практики мы используем.
- Сначала проектируются эндпоинты, которые ограничивают бизнес-логику, связанную с функциональностью.
- Эндпоинты разделяются, чтобы каждый выполнял конкретную задачу и возвращал только соответствующие данные.
- Важно учесть, что API может иметь несколько версий, чтобы обеспечить совместимость с клиентским приложением и не привести к нарушению работоспособности. Изменения вносятся только в новые версии API, а старые версии продолжают работать без изменений, но добавляется признак что эндпоинт устарел.
- В нашем случае используется React-приложение, поэтому проект соответствует определенным требованиям, например, RestFul API. Он должен быть легким для понимания, безопасным, эффективным, а также иметь понятную структуру и смысл:
- Использование уникальных URI.
- HTTP-методы, определяются API и включают: GET, POST, PUT и DELETE, которые могут быть использованы для работы с ресурсами. При разработке API важно определить, какие методы будут поддерживаться для каждого ресурса.
- Данные должны быть представлены в определенном формате (JSON или XML), который определяется при проектировании API. В нашем случае всегда используется JSON, так как React-приложение использует JavaScript Object Notation для обмена данными между сервером и клиентом.
- API не хранит состояние клиента между запросами. Вместо этого, клиент передает необходимую информацию в каждом запросе, обеспечивая безопасность и надежность работы. При разработке API не следует хранить информацию о клиенте на сервере, ведь это не только снижает нагрузку на сервер, но и позволяет достичь более высокой производительности и эффективности.
- API должен использовать коды состояния HTTP для передачи информации о выполнении запросов. В нашем случае мы всегда отправляем код 200 success, а состояние ответа передаем в теле ответа.
- API использует кэширование для повышения производительности и снижения нагрузки на сервер.
- При создании нейминга в проекте мы придерживаемся нескольких важных критериев:
- все названия объектов должны быть написаны в CamelCase – одном из самых популярных стилей программирования на языке C#;
- нейминг строится вокруг реальных сущностей, существующих в проекте. Например, если в проекте есть объект accountDatabase, то по этому объекту будет построен эндпоинт “/accountDatabase”;
- мы используем существительные, вместо глаголов, а для того чтобы установить смысл запроса и улучшить его читабельность используем разные HTTP-методы – GET, POST, PUT или DELETE;
- для простых GET-запросов используем path-параметры, а для сложных запросов с фильтрами – query-параметры, в остальных случаях передаем данные в body;
- нейминг самих параметров пишется при помощи CamelCase.
- Для React-приложений, работающих с удаленным сервером API на другом домене, необходима настройка политики CORS, чтобы обеспечить поддержку отправки кросс-доменных запросов.
- React-приложения должны пройти аутентификацию и авторизацию, чтобы взаимодействовать с API. Важно, чтобы API соответствовал требованиям приложения и поддерживал механизмы аутентификации и авторизации. Мы используем JWT Bearer токены для этого.
- Для работы с большими объемами данных на React-приложениях рекомендуется осуществлять пагинацию на стороне бэка. Это позволит загружать данные по мере необходимости и ускорить загрузку страниц на стороне клиента.
- Мы реализовали в проекте ONION-архитектуру, разбив обработку запросов на логические уровни (аутентификация, проверка ролей, валидация, работа с БД). Сейчас еще рассматриваем внедрение CQRS и MediatR.
Наше API проходит данные процессы при разработке новой функциональности. Из-за быстрого развития IT-сферы, мы постоянно корректируем и дорабатываем наши технологии и подходы, чтобы соответствовать современным требованиям бизнеса. Важно помнить, что все правила разработки определяет бизнес, и каждое новое требование должно соответствовать его потребностям. Это не рекомендации к разработке вашего API, мы всего лишь делимся своим опытом и подходами.
Спасибо за внимание!
