Навіщо використовувати сервіси (REST / SOAP) замість бібліотеки?

Скажімо, ви хочете розбити свої програми на послуги. Чи є якісь вагомі причини застосувати підхід SOA порівняно з просто створенням бібліотечного API, який може завантажуватися програмами, які цього потребують.

Різниця може бути тонкою між обома. Наприклад, у світі .NET, у вас може бути додаток, який буде відчувати себе монолітним для кінцевого споживача і який буде працювати на тій же машині, але всередині, розділиться на купу служб WCF. Ви також можете мати архітектури, в яких бібліотеки не пов’язані між собою (addins / plugins) і просто дотримуються протоколу під час розмови один з одним.

Якщо ми уникаємо говорити про ті посередницькі випадки, а мати справу лише з сильно пов’язаною бібліотекою API та окремою службою REST, то, можливо, ви захочете розглянути наступні моменти:

1. API бібліотеки викликається на одній машині. Послуги можуть розміщуватися в будь-якому місці та телефонувати з будь-якого місця. Якщо ви рахуєте розміщення програми на декількох машинах з міркувань продуктивності / масштабованості / безпеки, швидше за все, вам знадобиться користуватися послугами.

2. Аналогічна ситуація стосується використання однієї служби додатком, розгорнутим на декількох машинах. Наприклад, якщо ви робите заявку для банку, який виконує деякі фінансові розрахунки, один із способів - розгорнути всю велику програму на кожному робочому столі та змусити кожного разу робити оновлення великих розмірів для кожного клієнта; Іншим підходом було б розміщення обчислювальної частини на серверах та розгортання на настільних ПК лише легкого додатка із лише інтерфейсом користувача та купою дзвінків на ці сервери.

3. Якщо ви розміщуєте сервіс REST, користуватися ним може кожен: користувач Mac, людина, яка використовує Linux тощо. Якщо ви створили бібліотеку C # за допомогою Visual Studio і розповсюджуєте її як DLL, забудьте про користувачів (клієнтів ?) які не мають Windows.

Ще одна перевага послуг полягає в тому, що коли ви оновлюєте послугу, вона негайно розгортається для всіх споживачів послуги. Тож якщо ви виправили помилку чи проблему з продуктивністю, кожен отримує перевагу, як тільки оновлений сервіс починає працювати, замість того, щоб поширювати оновлення, яке люди можуть вирішити ігнорувати.

Переваги бібліотеки:

• Нижчі накладні витрати на виклик (лише стрибок або навіть вказівний ) = можуть збільшити продуктивність
• Найпростіша річ, яка могла б спрацювати
• Немає ризику зниження централізованої послуги та не вплине на всіх споживачів

Переваги обслуговування:

• Усі отримують оновлення негайно та прозоро (якщо не пропонується версія API)
• Споживачі не можуть декомпілювати код
• Можна окремо масштабувати сервісне обладнання
• Технологічний агностик. За допомогою спільної бібліотеки споживачі повинні використовувати сумісну технологію.
• Більш безпечний. Рівень користувальницького інтерфейсу може викликати службу, яка знаходиться за брандмауером замість прямого доступу до БД.

Підхід SOA дозволяє розміщувати та обслуговувати різні послуги окремо. Крім коду, для розгортання певної послуги може знадобитися велика кількість спеціальної конфігурації (паролі, порти, сертифікати тощо). Споживання послуги REST має обмежену складність, яку можна чітко зафіксувати та легко зрозуміти. Він також більш безпечний, оскільки означає, що вам не потрібно надавати клієнтам доступ до баз даних або інших ресурсів.

Якщо відбудеться зміна служби SOA, то цю службу SOA доведеться переробляти, повторно перевіряти та перерозподіляти. Усі програми, які споживають цю послугу, можуть продовжувати це робити. Зміни на бібліотеку в DLL означатимуть, що всі споживачі цієї бібліотеки повинні бути перероблені для посилання на DLL, всі вони повинні бути повторно перевірені, і їх потрібно буде повторно розмістити. Також існує небезпека, що це може не відбутися належним чином, і різні програми матимуть різні версії DLL. Іноді це може не бути проблемою - можливо, кожна система повинна мати версію бібліотеки, яка була присутня під час розгортання (можливо, ви оновили систему реєстрації, щоб мати нові корисні функції - чи справді випотрібно оновлювати кожну систему?) в цьому випадку бібліотека чудово. Але скажіть, у вас є послуга з обчислення ставки податку, і податкове законодавство змінюється. Вам не потрібно оновлювати кожну систему, щоб включити цю зміну, було б краще зробити це в одному місці. У цьому випадку послуга є кращим варіантом.

Є кілька хороших відповідей, але я хотів би додати більше речей до цих відповідей:

Метод бібліотеки API дуже корисний, коли ви хочете взаємодіяти з речами з якомога меншими накладними витратами. Наслідком цього є те, що між API та додатками, що використовують його, існує більш висока зв'язок. Іноді це нормально для застосування та навіть необхідне, але якщо у вас дуже розподілена система чи ви думаєте, що сумісність є величезною проблемою, можливо, вам доведеться пройти один крок вперед до абстракції та використовувати інші способи спілкування. Тим більше, якщо ви хочете мати розподілену систему, SOAP - це свого роду наступний крок у SOA, але ви все одно залишитесь на залежність між підрозділами, оскільки вони повинні знати процедури один одного. REST виводить його на новий рівень, дозволяючи машині уніфіковано дізнаватися щось про вміст інших служб.

У вашому випадку, якщо ваша програма не поширюється, я не бачу причин перетворювати вашу програму на SOA.