Dlaczego warto korzystać z usług (REST / SOAP) zamiast biblioteki?

22

Załóżmy, że chcesz podzielić swoje aplikacje na usługi. Czy istnieją uzasadnione powody, aby zastosować podejście SOA, a nie po prostu utworzyć interfejs API biblioteki, który może zostać załadowany przez aplikacje, które tego potrzebują.

Nate Reed
źródło
6
Hej, Nate, przeczytaj Steve's Google Platforms Rant , zapewnia świetny wgląd w pytanie o platformę (usługi) vs produkt (biblioteka) ...
yannis

Odpowiedzi:

11

Różnica może być subtelna między nimi. Na przykład w świecie .NET możesz mieć aplikację, która wydaje się monolityczna dla użytkownika końcowego i która będzie działać na tej samej maszynie, ale wewnątrz będzie podzielona na kilka usług WCF. Możesz także mieć architektury, w których biblioteki nie są silnie połączone (dodatki / wtyczki) i po prostu postępują zgodnie z protokołem, rozmawiając ze sobą.

Jeśli unikniemy mówienia o przypadkach pośrednich i zajmiemy się tylko silnie połączoną biblioteką API w porównaniu z oddzielną usługą REST, możesz rozważyć następujące kwestie:

  1. Biblioteka API jest wywoływana na tym samym komputerze. Usługi mogą być hostowane w dowolnym miejscu i wywoływane z dowolnego miejsca. Jeśli liczysz na hostowanie aplikacji na wielu komputerach ze względu na wydajność / skalowalność / bezpieczeństwo, prawdopodobnie będziesz musiał skorzystać z usług.

  2. Podobnie jest w przypadku korzystania z jednej usługi przez aplikację wdrożoną na kilku komputerach. Na przykład, jeśli robisz aplikację dla banku wykonującego obliczenia finansowe, jednym ze sposobów jest wdrożenie całej dużej aplikacji na każdym pulpicie i zmuszanie do robienia dużych aktualizacji każdemu klientowi za każdym razem; innym podejściem byłoby hostowanie części obliczeniowej na serwerach i wdrażanie na komputerach jedynie lekkiej aplikacji z tylko interfejsem użytkownika i wieloma wywołaniami do tych serwerów.

  3. Jeśli prowadzisz usługę REST, każdy może z niej korzystać: użytkownik komputera Mac, osoba korzystająca z systemu Linux itp. Jeśli utworzyłeś bibliotekę C # za pomocą programu Visual Studio i rozpowszechniasz ją jako bibliotekę DLL, zapomnij o użytkownikach (klientach) ?), którzy nie mają systemu Windows.

Arseni Mourzenko
źródło
9

Kolejną zaletą usług jest to, że po aktualizacji usługa jest natychmiast wdrażana u wszystkich odbiorców usługi. Jeśli więc naprawiłeś błąd lub problem z wydajnością, każdy otrzymuje korzyść, gdy tylko zaktualizowana usługa zostanie uruchomiona, zamiast dystrybuować aktualizację, którą ludzie mogą zignorować.

Mike O'Connor
źródło
To prawda, ale może to być również wadą. Po wprowadzeniu zmiany w usłudze, od której zależy wiele aplikacji, można nieoczekiwanie przerwać działanie jednej lub wielu z tych aplikacji. Nie ma to na celu odstraszenia nikogo od usług, pamiętaj tylko, że musisz upewnić się, że wszyscy konsumenci usługi nadal działają przy każdej zmianie usługi. Jeszcze lepiej jest pozostawić starsze metody usług w spokoju po ich wdrożeniu i stworzyć nowe metody, gdy trzeba zmienić implementację.
Lews Therin,
8

Zalety biblioteki:

Zalety usługi:

  • Każdy otrzymuje aktualizacje natychmiast i przejrzyście (chyba że oferowany jest wersjonowany interfejs API)
  • Konsumenci nie mogą dekompilować kodu
  • Można osobno skalować sprzęt serwisowy
  • Technologia agnostyczna. Dzięki wspólnej bibliotece konsumenci muszą korzystać z kompatybilnej technologii.
  • Więcej Ochrony. Warstwa interfejsu użytkownika może wywoływać usługę znajdującą się za zaporą ogniową zamiast bezpośredniego dostępu do bazy danych.
Cory House
źródło
„kod natywny” nie ma tu naprawdę sensu: a) usługa może również używać „kodu natywnego”, oraz b) kompilacja just-in-time często zapewnia taką samą wydajność jak kod natywny.
sleske
Punkt wzięty. Mówię o „kodzie natywnym”, gdy mówię o tym, że biblioteka jest wywołaniem „w toku”. Nie ma narzutu warstwy usługi (np. HTTP w przypadku wywołania interfejsu API sieci Web)
Cory House
Tak, koszt połączenia powinien być rzeczywiście niższy. Pozwoliłem sobie na edycję twojej odpowiedzi, zastępując wzmiankę o „natywnym kodzie” słowem „niższy koszt połączenia”. Jeśli nie zgadzasz się :-).
sleske
To, co lubię dodawać, to wykorzystanie transakcji . Zazwyczaj znacznie trudniej jest przeprowadzać transakcje ponad granicami usług niż w bibliotece współdzielonej.
c_mart,
2

Podejście SOA umożliwia oddzielne hostowanie i obsługę różnych usług. Oprócz kodu wdrożenie określonej usługi może wymagać wielu specjalnych konfiguracji (haseł, portów, certyfikatów itp.). Korzystanie z usługi REST ma skończoną złożoność, którą można jasno udokumentować i łatwo zrozumieć. Jest również bezpieczniejszy, ponieważ oznacza, że ​​nie musisz udzielać dostępu do baz danych ani innych zasobów klientom.

nerwowy
źródło
1

Jeśli nastąpi zmiana w usłudze SOA, usługa SOA będzie musiała zostać przebudowana, ponownie przetestowana i wdrożona ponownie. Wszystkie aplikacje korzystające z tej usługi mogą nadal to robić. Zmiana biblioteki w bibliotece DLL oznacza, że ​​wszyscy konsumenci tej biblioteki będą musieli zostać przebudowani w celu odniesienia do tej biblioteki DLL, wszyscy będą musieli zostać ponownie przetestowani i wszyscy będą musieli zostać ponownie wdrożeni. Istnieje również niebezpieczeństwo, że może się to nie powieść, a różne aplikacje będą miały różne wersje biblioteki DLL. Czasami może to nie stanowić problemu - być może każdy system powinien mieć wersję biblioteki, która była obecna w czasie wdrażania (być może zaktualizowałeś system rejestrowania, aby miał przydatne nowe funkcje - czy naprawdępotrzebujesz zaktualizować każdy system z nim?) w tym przypadku biblioteka jest w porządku. Ale powiedz, że masz usługę obliczania stawki podatkowej, a przepisy podatkowe się zmieniają. Nie chcesz aktualizować każdego systemu, aby uwzględnić tę zmianę, lepiej byłoby zrobić to w jednym miejscu. W takim przypadku usługa jest lepszą opcją.

Paul T. Davies
źródło
0

Istnieje kilka dobrych odpowiedzi, ale chciałbym dodać więcej rzeczy do podanych odpowiedzi:

Metoda biblioteki API jest bardzo przydatna, gdy chcesz wchodzić w interakcje z jak najmniejszymi kosztami. Konsekwencją jest wyższe sprzężenie API z aplikacjami, które go wykorzystują. Czasami jest to w porządku dla aplikacji, a nawet konieczne, jednak jeśli masz bardzo rozproszony system lub uważasz, że interoperacyjność jest ogromnym problemem, być może będziesz musiał pójść o jeden krok wyżej od abstrakcji i użyć innych sposobów komunikacji. Zwłaszcza jeśli chcesz mieć system rozproszony, SOAP jest swego rodzaju kolejnym krokiem w SOA, ale nadal pozostaniesz zależny między jednostkami, ponieważ muszą one znać się nawzajem. REST przenosi go na nowy poziom, umożliwiając maszynie nauczenie się czegoś o zawartości innych usług w ujednolicony sposób.

W twoim przypadku, jeśli twoja aplikacja nie jest rozpowszechniana, nie widzę żadnego powodu, aby przekształcić ją w SOA.

aagaard
źródło