6
że dwa microservices:Jak obsługiwać ścieżki API REST, gdy powiązane zasoby należą do różnych mikroserwisów?
- UserService, który wyznacza ścieżkę jak użytkowników// użytkowników/id;
- MessageService, która definiuje ścieżki takie jak/messages,/messages /: id.
Ponadto każda wiadomość w MessageService ma atrybut user_id, który odwołuje się do użytkownika w UserService.
Teraz możemy powiedzieć, że chcę wyświetlić wszystkie wiadomości danego użytkownika. Teraz mogę myśleć z następujących metod:
- Ścieżka takich jak /users/id/Komunikaty Wydaje się, że najlepszym podejściem, jeśli chcę śledzić najlepszych praktyk REST API. Jednak wydaje mi się, że nie mogłem zdefiniować takiej ścieżki wewnątrz usługi MessageService, ponieważ byłbym ściśle powiązany z usługą UserService. Wierzę, że ścieżki zaczynające się od/users powinny należeć tylko do UserService.
- /messages? Id_użytkownika =: id, więc mógłbym użyć istniejącej ścieżki/wiadomości i dodać filtr według atrybutu (user_id). Nie jestem pewien, czy to dobra praktyka.
- Umieść bramkę API przed mikroserwisami i utwórz serwer proxy od /users /: id/messages do /messages? Id_użytkownika =: id. Dzięki temu klienci mogą korzystać z najbardziej przyjaznej dla REST ścieżki, jednocześnie utrzymując luźno połączone mikroserwisy.
Które z tych podejść byłoby najbardziej odpowiednie?
Tak, wiadomości zawsze należą do jednego użytkownika. Czy dobrą praktyką jest mieć ścieżkę zaczynającą się od/user w mikroserwisie, które nie przechowuje użytkowników, tylko odniesienie do nich? – vitorsdcs
Myślę, że w tym przypadku wszystko jest w porządku. Jeśli twoja usługa udostępnia zasoby o nazwie "users" (liczba mnoga), spodziewam się, że będę mógł wykonywać na nim operacje CRUD. W tym przypadku widzę to jako hierarchiczny podział kolekcji wiadomości. Ale jeśli ci się nie spodoba, możesz również umieścić użytkownika za kolekcją wiadomości, w ten sposób: '/ messages/user /: id' – MvdD