Todo esse papo sobre as vantagens e maravilhas do SOAP sempre pareceram um pouco suspeito, e agora finalmente eu percebi o porquê.
De algum modo, me parece que o discurso de benefícios o SOAP é uma versão travestida do seguinte argumento: o melhor é reusar o HTTP porque o melhor é reusar os servidores HTTP pré-existentes ou, ao menos, porque o problema de implementação de um servidor HTTP tem solução conhecida.
Uma crítica fundamental ao SOAP sobre HTTP é o fato de o HTTP não ter sido projetado como protocolo de transporte para outros protocolos; na prática, esse fato é simplesmente desconsiderado.
Creio que isso evidencia as razões histórias para esse esquema: o valor não está tanto nas capacidades do HTTP como protocolo de transporte, mas nas capacidades das implementações do HTTP de suportar esta forma de reuso.
Entendendo as coisas por esse ângulo, faz perfeito sentido que ao inventar uma plataforma de web services um sujeito reusasse, digamos, o Apache HTTP Server, ou o Microsoft IIS: são sistemas extensíveis de propósito.
Em um mundo imaginário onde implementar um sistema sobre TCP não fosse difícil, talvez SOAP sobre HTTP nunca tivesse nascido.
Isso, por sua vez, sugere um interessante objeto de pesquisa: um servidor genérico sobre TCP, tão extensível que implementar algo como SOAP sobre ele fosse uma solução natural.
O próprio Apache HTTP Server realiza esta proposta, de certa maneira; existem coisas como mod_ftp. Produtos como ACE e Boost.ASIO estão quase lá mas não são orientados a componentes o suficiente.
É claro que existem outras razões porque é interessante implementar SOAP sobre HTTP, como por exemplo o problema de implantação diante de firewalls convencionais que bloqueiam todas as portas TCP. Essa é uma razão para se implementar qualquer coisa sobre HTTP, é claro; não é uma propriedade especial doSOAP.
De algum modo, me parece que o discurso de benefícios o SOAP é uma versão travestida do seguinte argumento: o melhor é reusar o HTTP porque o melhor é reusar os servidores HTTP pré-existentes ou, ao menos, porque o problema de implementação de um servidor HTTP tem solução conhecida.
Uma crítica fundamental ao SOAP sobre HTTP é o fato de o HTTP não ter sido projetado como protocolo de transporte para outros protocolos; na prática, esse fato é simplesmente desconsiderado.
Creio que isso evidencia as razões histórias para esse esquema: o valor não está tanto nas capacidades do HTTP como protocolo de transporte, mas nas capacidades das implementações do HTTP de suportar esta forma de reuso.
Entendendo as coisas por esse ângulo, faz perfeito sentido que ao inventar uma plataforma de web services um sujeito reusasse, digamos, o Apache HTTP Server, ou o Microsoft IIS: são sistemas extensíveis de propósito.
Em um mundo imaginário onde implementar um sistema sobre TCP não fosse difícil, talvez SOAP sobre HTTP nunca tivesse nascido.
Isso, por sua vez, sugere um interessante objeto de pesquisa: um servidor genérico sobre TCP, tão extensível que implementar algo como SOAP sobre ele fosse uma solução natural.
O próprio Apache HTTP Server realiza esta proposta, de certa maneira; existem coisas como mod_ftp. Produtos como ACE e Boost.ASIO estão quase lá mas não são orientados a componentes o suficiente.
É claro que existem outras razões porque é interessante implementar SOAP sobre HTTP, como por exemplo o problema de implantação diante de firewalls convencionais que bloqueiam todas as portas TCP. Essa é uma razão para se implementar qualquer coisa sobre HTTP, é claro; não é uma propriedade especial doSOAP.
Prefiro usar HTTP com REST, de preferencia usando HyperMidia -- na linha que o Restfulie esta fazendo.
ResponderExcluirSOAP é interessante sobre XMPP :)