Зачем использовать сервисы (REST / SOAP) вместо библиотеки?

Допустим, вы хотите разбить ваши приложения на сервисы. Существуют ли веские причины для принятия SOA-подхода, а не просто для создания библиотечного API, который может быть загружен приложениями, которым он нужен.

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

Если мы не будем говорить об этих промежуточных случаях и будем иметь дело только с сильно связанной библиотекой API, а не с отдельной службой REST, то вы можете рассмотреть следующие моменты:

1. API библиотеки вызывается на той же машине. Услуги могут быть размещены в любом месте и вызываться из любого места. Если вы рассчитываете разместить приложение на нескольких машинах по соображениям производительности / масштабируемости / безопасности, скорее всего, вам понадобятся сервисы.

2. Ситуация аналогична, когда речь идет об использовании одного сервиса приложением, развернутым на нескольких машинах. Например, если вы делаете приложение для банка, выполняющего некоторые финансовые вычисления, одним из способов является развертывание всего большого приложения на каждом настольном компьютере и принудительное выполнение крупномасштабных обновлений для каждого клиента каждый раз; Другой подход заключается в размещении вычислительной части на серверах и развертывании на настольных компьютерах только облегченного приложения с пользовательским интерфейсом и множеством вызовов на эти серверы.

3. Если вы размещаете службу REST, ее может использовать любой: пользователь Mac, человек, использующий Linux и т. Д. Если вы создали библиотеку C # с Visual Studio и распространяете ее как DLL, забудьте о пользователях (клиентах). ?) у кого нет винды.

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

Преимущества библиотеки:

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

Преимущества сервиса:

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

Подход SOA позволяет размещать и поддерживать различные сервисы отдельно. В дополнение к коду, для развертывания конкретной службы может потребоваться много специальных настроек (пароли, порты, сертификаты и т. Д.). Использование службы REST имеет ограниченную сложность, которая может быть четко задокументирована и легко понятна. Это также более безопасно, потому что это означает, что вам не нужно предоставлять доступ к БД или другим ресурсам клиентам.

Если в SOA-сервисе есть изменения, то этот SOA-сервис придется пересмотреть, протестировать и развернуть. Все приложения, которые используют этот сервис, могут продолжать это делать. Изменение библиотеки в DLL будет означать, что все пользователи этой библиотеки должны быть перестроены, чтобы ссылаться на эту DLL, все они должны быть повторно протестированы, и все они должны быть повторно развернуты. Существует также опасность того, что это может произойти неправильно, и разные приложения будут иметь разные версии DLL. Иногда это может не быть проблемой - возможно, каждая система должна иметь версию библиотеки, которая присутствовала во время развертывания (возможно, вы обновили свою систему журналирования, чтобы иметь полезные новые функции - действительно ли выНужно обновить каждую систему с ним?) в этом случае библиотека в порядке. Но скажем, у вас есть сервис для расчета налоговой ставки, и налоговые законы меняются. Вы не хотите обновлять каждую систему, чтобы включить это изменение, было бы лучше сделать это в одном месте. В этом случае услуга является лучшим вариантом.

Есть несколько хороших ответов, но я хотел бы добавить больше вещей к данным ответам:

Метод библиотеки API очень полезен, когда вы хотите взаимодействовать с вещами с минимальными издержками, насколько это возможно. Следствием этого является более высокая связь между API и приложениями, использующими его. Иногда это нормально для приложения и даже необходимо, однако, если у вас очень распределенная система или вы думаете, что совместимость является огромной проблемой, вам, возможно, придется продвинуться на одну ступень выше по абстракции и использовать другие способы общения. Особенно, если вы хотите иметь распределенную систему, SOAP является своего рода следующим шагом в SOA, но вы все равно останетесь с зависимостью между модулями, так как они должны знать процедуры друг друга. REST выводит его на новый уровень, позволяя машине унифицированно изучать содержимое других служб.

В вашем случае, если ваше приложение не распространяется, я не вижу причин для преобразования вашего приложения в SOA.