O padrão Webservice, mantido pelo W3C, é sem dúvida um dos padrões mais adotados para integração de sistemas atualmente.
Um dos objetivos principais do WebService é prover uma forma única de sistemas falarem entre si, ofertando recursos próprios a terceiros e utilizando recursos ofertados por estes.
/* Quando um sistema prove recursos seus a outros sistemas chamamos de “exposição de um serviço”, e quando utiliza recursos de outro sistema chamamos de “consumo de um serviço” */
Webservices também são considerados API’s, pois abrem de certo modo uma porta no sistema para que outros utilizem recursos, compartilhando seu escopo.
O uso do padrão Webservice
É um padrão que já possui quase duas décadas, vem amadurecendo muito.
Mas muitos profissionais mais jovens ainda estão o descobrindo, e alguns mais profissionais experientes ainda não o experimentaram em escala considerável.
Sendo um padrão muito requisitado, profissionais eventualmente se deparam com a necessidade de se projetar ou desenvolver um Webservice, mas muitas das vezes não tem maldade no uso destas API’s. Implementar (no sentido de codificar) um Webservice em Java ou C# é tranquilo, mas nem tudo é somente implementação.
Cuidado no uso de Webservice
O ponto que quero abordar é o cuidado necessário ao se pensar num WebMethod (os métodos ou “funções” que um Webservice irá expôr para sistemas consumirem).
Quando lidamos com um sistema fechado, sem integração com terceiros, é muito comum falarmos em refatoração.
Utilizar refactoring geralmente é visto como algo positivo (e acho que realmente é, quando utilizado corretamente), pois melhora continuamente um sistema, sua arquitetura, estrutura etc.
Quando um ponto do sistema é refatorado e há impacto em outros pontos, basta alterar chamadas, passar novos parâmetros ou coisa do tipo e tudo estando no nível do “código fonte” não há impacto para o usuário final. Mas com Webservice não é bem assim. Mas está tudo “dentro de casa”!
/* Sistema fechado é um sistema que não possui integração com outros sistemas. */
Como já citado, a finalidade de um Webservice é prover integração entre sistemas, mas sistemas são caixas fechadas que somente seu dono pode abrir.
Quando um Webservice é publicado, vários outros sistemas nele se conectarão para consumir seus métodos, e essa conexão não é somente baseada em arquivo de configuração, está escrita em código, contida numa build, inserida num setup etc.
Vejamos isso na vida real
Imaginemos um Webservice com um WebMethod chamado CalcularFrete, de uma empresa de entregas como os Correios.
O método é utilizado por milhares de sites internet, que realizam centenas de requisições por minuto no serviço. Este método recebe como parâmetro um CEP de origem, um CEP de destino e o peso da mercadoria, e retorna o valor do frete.
Um dia, os Correios verificam que somente estes parâmetros de entrada não são suficientes, pois é necessário verificar se trata-se de frete para pessoa física ou jurídica, senão o cálculo ficará errado.
Então um Analista desta empresa diz: “É mole, basta incluirmos um novo parâmetro no método, obrigatório é claro, e todos os sistemas consumidores alteram suas interfaces passando o novo parâmetro, pronto, resolvido!”.
Tecnicamente, a solução é essa mesmo.
Mas isso se aplica?
Imagine realizar a alteração em cada sistema consumidor deste Webservice (milhares de sites conforme o exemplo).
Suponhamos então que outro Analista diga: “Não podemos fazer isso, vai gerar um impacto enorme pois muitos não alterarão as chamadas em suas interfaces e perderemos receita, nossos clientes ficarão insatisfeitos. Vamos criar um novo método, CalcularFrenteNovo, e aí orientamos nossos clientes a utilizarem este e abandonarem o antigo”. O que vai acontecer?
Naturalmente que muitos continuarão conectados ao método antigo, haverá duplicidade de lógica e outros prejuízos mais.
A mensagem com este post é: ao definir um WebMethod num Webservice tente fazer o impossível para concluir que nunca será necessário alterá-lo, pois se um dia esta necessidade aparecer problemas sérios ocorrerão. Uma vez publicado, não é plausível considerar refatorar um WebMethod.
Não se restringe a Webservice
Lembrando, que essa recomendação não aplica-se apenas a APIs do tipo Webservice. Este cuidado deve ser tomado para qualquer tipo de API.
Grande abraço!
[activecampaign form=3]