Por que usar serviços (REST / SOAP) em vez de uma biblioteca?

Digamos que você queira dividir seus aplicativos em serviços. Existem boas razões para adotar uma abordagem SOA versus apenas criar uma API de biblioteca que possa ser carregada pelos aplicativos que precisam.

A diferença pode ser sutil entre ambos. Por exemplo, no mundo .NET, você pode ter um aplicativo que pareça monolítico para um usuário final e que funcione em uma mesma máquina, mas por dentro, seria separado em vários serviços WCF. Você também pode ter arquiteturas nas quais as bibliotecas não estão fortemente vinculadas (addins / plugins) e estão apenas seguindo um protocolo quando conversam entre si.

Se evitarmos falar sobre esses casos intermediários e lidarmos apenas com a biblioteca de API fortemente vinculada versus um serviço REST separado, convém considerar os seguintes pontos:

1. Uma API de biblioteca é chamada na mesma máquina. Os serviços podem ser hospedados em qualquer lugar e serem chamados de qualquer lugar. Se você está contando com a hospedagem do aplicativo em várias máquinas por motivos de desempenho / escalabilidade / segurança, é provável que você precise usar serviços.

2. A situação é semelhante quando se trata de usar um serviço por um aplicativo implantado em várias máquinas. Por exemplo, se você estiver executando um aplicativo para um banco fazendo alguns cálculos financeiros, uma maneira é implantar todo o aplicativo grande em todos os desktops e ser forçado a fazer atualizações de tamanho grande para todos os clientes sempre; outra abordagem seria hospedar a parte da computação nos servidores e implantar nos desktops apenas um aplicativo leve, com apenas uma interface do usuário e várias chamadas para esses servidores.

3. Se você está hospedando um serviço REST, qualquer pessoa pode usá-lo: um usuário de Mac, uma pessoa que usa Linux etc. Se você criou uma biblioteca C # com o Visual Studio e a distribui como uma DLL, esqueça os usuários (clientes ?) que não possuem Windows.

Outra vantagem dos serviços é que, quando você atualiza o serviço, ele é implantado imediatamente em todos os consumidores do serviço. Portanto, se você corrigiu um bug ou problema de desempenho, todos obtêm o benefício assim que o serviço atualizado é ativado, em vez de distribuir uma atualização que as pessoas podem optar por ignorar.

Vantagens da biblioteca:

• Despesas gerais mais baixas por chamada (apenas salto ou mesmo inline ) = podem aumentar o desempenho
• A coisa mais simples que poderia funcionar
• Não há risco de o serviço centralizado cair e impactar todos os consumidores

Vantagens do serviço:

• Todos recebem atualizações de forma imediata e transparente (a menos que a API com versão seja oferecida)
• Os consumidores não podem descompilar o código
• Pode dimensionar o hardware de serviço separadamente
• Tecnologia independente. Com uma biblioteca compartilhada, os consumidores devem utilizar uma tecnologia compatível.
• Mais seguro. A camada da interface do usuário pode chamar o serviço que fica atrás de um firewall em vez de acessar diretamente o banco de dados.

Uma abordagem SOA permite que os vários serviços sejam hospedados e mantidos separadamente. Além do código, a implantação de um serviço específico pode exigir muita configuração especial (senhas, portas, certificados, etc.). Consumir um serviço REST possui uma quantidade finita de complexidade que pode ser claramente documentada e facilmente entendida. Também é mais seguro, porque significa que você não precisa conceder acesso aos bancos de dados ou outros recursos aos clientes.

Se houver uma alteração em um serviço SOA, esse serviço SOA precisará ser reconstruído, testado novamente e reimplementado. Todos os aplicativos que consomem esse serviço podem continuar fazendo isso. Uma alteração em uma biblioteca em uma DLL significará que todos os consumidores dessa biblioteca precisarão ser reconstruídos para fazer referência a essa DLL, todos terão que ser testados novamente e terão que ser reimplantados. Também existe o risco de isso não acontecer corretamente e aplicativos diferentes terão versões diferentes da DLL. Às vezes, isso pode não ser um problema - talvez todo sistema deva ter a versão da biblioteca presente no momento da implantação (você pode ter atualizado seu sistema de log para ter novos recursos úteis - você realmenteprecisa atualizar todos os sistemas com ele?) Nesse caso, uma biblioteca está correta. Mas digamos que você tenha um serviço para calcular a taxa de imposto, e as leis tributárias mudam. Você não precisa atualizar todos os sistemas para incorporar essa alteração; seria melhor fazê-lo em um só lugar. Nesse caso, um serviço é uma opção melhor.

Existem várias boas respostas, mas gostaria de acrescentar mais coisas às respostas fornecidas:

O método da biblioteca de API é muito útil quando você deseja interagir com itens com o mínimo de sobrecarga possível. A conseqüência é que há um maior acoplamento entre a API e os aplicativos que a utilizam. Às vezes, isso é bom para a aplicação e até necessário; no entanto, se você possui um sistema muito distribuído ou acha que a interoperabilidade é um grande problema, pode ser necessário dar um passo adiante na abstração e usar outras formas de comunicação. Especialmente, se você deseja ter um sistema distribuído, o SOAP é o próximo passo na SOA, mas você ainda ficará com a dependência entre as unidades, pois elas precisam conhecer os procedimentos uns dos outros. O REST leva a um novo nível, permitindo que uma máquina aprenda algo sobre o conteúdo de outros serviços de uma maneira unificada.

No seu caso, se seu aplicativo não for distribuído, não vejo motivo para transformá-lo em SOA.