Ответ
Количество API в микросервисной архитектуре определяется количеством и ответственностью отдельных сервисов. Каждый сервис, как правило, предоставляет свой собственный API для взаимодействия.
Ключевые моменты:
- Один сервис — один API: Каждый микросервис инкапсулирует свою бизнес-логику и предоставляет к ней доступ через свой API (REST, gRPC, GraphQL).
- Типы API: Различают внутренние API (для межсервисной коммуникации) и внешние API (публичные, для клиентов или фронтенда).
- Пример: Система с сервисами
User,Order,Paymentбудет иметь как минимум три отдельных API.
Практический пример REST API для сервиса пользователей (Spring Boot):
@RestController
@RequestMapping("/api/users")
public class UserController {
@GetMapping("/{id}")
public ResponseEntity<User> getUser(@PathVariable Long id) {
User user = userService.findById(id);
return ResponseEntity.ok(user);
}
}Фактическое число конечных точек (endpoints) внутри каждого API зависит от функциональности сервиса.
Ответ 18+ 🔞
Да ты посмотри, какая хуйня получается! В микросервисах, блядь, всё просто, как три копейки. Сколько сервисов — столько и API, ёпта. Каждый этот маленький пиздёныш-сервис сидит в своей песочнице и орёт на весь мир через свою собственную дырку в заборе, то есть API.
Вот тебе суть, разжёванная:
- Один чувак — одна дверь: Один сервис — один его личный API. Не лезь к нему в дом через окно, стучи в дверь (REST, gRPC, GraphQL — это как разные способы постучать, блядь).
- Двери бывают разные: Есть внутренние двери — для своих, чтобы сервисы между собой болтали. А есть парадный вход — это уже для посторонних, типа фронтенда или мобильного приложения.
- Пример для совсем тупых: Есть система: «Пользователи», «Заказы», «Платежи». Это три отдельных конторы, у каждой свой телефон для связи (API). И нехуй звонить в «Платежи», чтобы спросить, как пользователя звать!
А вот, смотри, как это выглядит в коде, если делать сервис пользователей на Spring Boot. Ничего не трогаю, оставляю как есть, технически точно:
@RestController
@RequestMapping("/api/users")
public class UserController {
@GetMapping("/{id}")
public ResponseEntity<User> getUser(@PathVariable Long id) {
User user = userService.findById(id);
return ResponseEntity.ok(user);
}
}А внутри каждого такого API уже может быть дохуя этих конечных точек (endpoints). Хочешь — пользователя создавай, хочешь — удаляй, хочешь — обновляй. Это уже от аппетитов сервиса зависит, блядь. Главное — не пытайся из одного сервиса управлять данными другого напрямую, а то получишь ебаный спагетти-код и пиздец, а не архитектуру.