Answers:
两者之间的差异可能很小。例如，在.NET世界中，您可能拥有一个对于最终用户而言感觉像是单片的应用程序，该应用程序可以在同一台机器上运行，但是在内部却被分解为一堆WCF服务。您可能还拥有一些体系结构，在这些体系结构中，库之间没有牢固地链接（插件/插件），并且在彼此通信时仅遵循协议。
如果我们避免谈论这些中间情况，而只处理强链接的API库与单独的REST服务，那么您可能需要考虑以下几点：
在同一台计算机上调用库API。服务可以在任何地方托管，并且可以在任何地方调用。如果出于性能/可伸缩性/安全性的原因而考虑将应用程序托管在多台计算机上，则可能需要使用服务。
当部署在多台计算机上的应用程序使用一项服务时，情况也类似。例如，如果您要为一家银行做一个应用程序来进行一些财务计算，则一种方法是将整个大型应用程序部署到每个台式机上，并被迫每次都对每个客户进行大型更新。另一种方法是将计算部分托管在服务器上，并且仅将轻量级应用程序部署到桌面，该应用程序只有一个UI和对这些服务器的大量调用。
如果您托管的是REST服务，那么任何人都可以使用它：Mac用户，使用Linux的人等。如果您已经使用Visual Studio创建了C＃库，并以DLL的形式分发了它，那么请不要理会用户（客户？）没有Windows的人。
服务的另一个优点是，当您更新服务时，它将立即部署到该服务的所有使用者。因此，如果您修复了错误或性能问题，那么只要更新的服务投入使用，每个人都可以从中受益，而不必分发人们可能会选择忽略的更新。
图书馆优势：
服务优势：
如果SOA服务发生更改，则必须重新开发，重新测试和重新部署该SOA服务。使用该服务的所有应用程序都可以继续这样做。对DLL中的库进行更改将意味着必须重新开发该库的所有使用者以引用该DLL，都必须重新测试它们，并且都必须重新部署它们。还有可能无法正确发生这种危险，并且不同的应用程序将具有不同版本的DLL。有时这可能不是问题-也许每个系统都应具有部署时提供的库版本（您可能已更新了日志记录系统以具有有用的新功能-您真的需要用它来更新每个系统吗？）在这种情况下，一个库就可以了。但是说您有一个计算税率的服务，那么税法就会改变。您并不需要更新每个系统以包含此更改，最好在一个地方进行。在这种情况下，服务是更好的选择。
有几个好的答案，但我想在给定的答案中添加更多内容：
当您想以尽可能少的开销与事物进行交互时，API库方法非常有用。结果是API与使用它的应用程序之间存在更高的耦合。有时，这对于应用程序来说是可以的，甚至是必要的，但是，如果您的系统非常分散，或者您认为互操作性是一个大问题，则可能需要进一步提高抽象层次并使用其他通信方式。尤其是，如果您想拥有一个分布式系统，则SOAP是SOA的下一步，但是由于单元之间必须彼此了解，所以您仍然会受到单元之间的依赖。REST通过允许机器以统一的方式学习有关其他服务上的内容的知识，将其提升到一个新的水平。
对于您而言，如果您的应用程序未分发，那么我看不出有任何理由将您的应用程序转换为SOA。