Minha dúvida é voltada ao conceito e não a um código ou tecnologia específica(Java,.NET,etc).
Vamos supor que eu precise integrar 2 sistemas sendo um em Java o outro em ColdFusion. O sistema que irá consumir os webservices será o feito em java e os webservices serão feitos no sistema feito em coldfusion.
Ai no caso o sistema em java deveria executar uma implementação para consumir 3 métodos de webservice, sendo que todos eles tem como retorno um xml com um formato padronizado e conhecido pela outra aplicação.
Qual é a vantagem de se realmente implementar os webservices? Porque não poderia simplesmente enviar um HTTP post com os parametros de entrada e o servidor montar uma página com o response type em xml?
Existem várias vantagens de se usar um Web Service. A mais clara que vejo é a facilidade de trocar informações sem expor infra-estrutura ou serviços privados. Um simples HTTP Post trás dezenas de problemas que não são enfrentados com um Web Service. Além disso eles permitem definir um workflow, optimizando os processos de transação de informação.
Foi exatamente essa a pergunta que Roy Fielding e muita gente da indústria de software se fez há alguns anos. E disso nasceu os Web Services REST.
WS baseado em SOAP só é vantajoso/útil quando você precisa controlar transações, implementar algumas formas complexas de segurança e todo o WS-* stack. Quer dizer, ainda assim é questionável.
[quote=bKn]
Um simples HTTP Post trás dezenas de problemas que não são enfrentados com um Web Service. Além disso eles permitem definir um workflow, optimizando os processos de transação de informação.[/quote]
Poderia citar alguns desses problemas, por favor?
Em relação ao workflow, também é possível alimentar alguma ferramenta de BPM com REST sem precisar de Web Service SOAP(jBPM). Apesar de que eu nunca vi muita utilidade nisso de BPM.
REST e HTTP não são a mesma coisa; REST poderia ser implementado de várias maneiras, já HTTP simplesmente segue o estilo arquitetural do primeiro. Fora que eu não imagino uma aplicação desktop funcionando com HTTP, coisa que é facilmente alcançável com SOAP.
Nope. É o contrário, REST é um estilo arquitetural que se baseia em HTTP. Aliás, quais as outras maneiras de se implementar REST sem HTTP?
[quote=bKn]
Fora que eu não imagino uma aplicação desktop funcionando com HTTP, coisa que é facilmente alcançável com SOAP.[/quote]
Qual o problema de se usar HTTP em um desktop exatamente? Na grande maioria das linguagens que conheço isso é bem trivial.
E em relação ao envelope SOAP, sei que ele pode ser transportado por outros protocolos além do HTTP(SMTP, FTP, etc) mas a implementação de transporte padrão é HTTP. Como você trafegaria um envelope SOAP em uma aplicação desktop se não por HTTP?
Nope. É o contrário, REST é um estilo arquitetural que se baseia em HTTP. Aliás, quais as outras maneiras de se implementar REST sem HTTP?
[/quote]
HTTP é uma arquitetura concreta, já REST é apenas um estilo de arquitetura, que pode ser implementado em várias outras tecnologias. Aqui ele é implementado somente em java.
A unica desvatagem que eu vejo no REST é a não padronização!!! não existe nenhuma especificação…
por outro lado o ws possue mais de 10 especificações .kkkk
Só para apimentar… o Banco Postal (desenvolvido em 2001) funciona com HTTP… todas as transações oriundas da aplicação desktop rodando nas agências os Correios em qualquer parte do Brasil são enviadas (e retornadas) via HTTP (ou HTTPS) como xml para (e de) um servletzinho que está lá só para intermediar o desktop com o switcher para o mainframe milhares de quilometros além.
Não acredito que o termo SOAP possa conviver na mesma frase com o advérbio facilmente a menos por preguiça de quem usa uma ferramenta (tipo um WLI da vida) ou uma IDE para gerar automaticamente uma solução complicada para coisas simples. Fica fácil para quem clica no Next, Next mas tudo o mais fica mais difícil.
Ele só se aproveitou dos princípios de REST deste artigo para criar uma arquitetura ROC(Resource Oriented Computing), usando a mesta semântica dos verbos HTTP para verbos próprios.
A proposta inicial de REST, segundo a tese de doutorado de seu criador(Roy Fielding) era suprir algumas carências do protocolo HTTP utilizando a web como plataforma. http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm
Anyway…
Eu particularmente dos cenários que passei, em nenhum deles SOAP traria nenhuma vantagem direta ou indireta. E desconfio que essa regra se aplica a grande e emagadora maioria dos cenários.