Olá,
sou iniciante em SOA e li alguns artigos sobre Web Service e fiquei com algumas duvidas :
-
Qual a diferança entre SOAP e Rest?
-
E se for utilizar em um projeto qual usar ??
se alguém puder me ajudar …
abs
A diferença é a tecnologia e os princípios por trás de cada um.
Eu nunca vi um bom exemplo de SOAP logo eu tenho a tendencia de achar que SOAP é necessário para coisas legadas ou que não exista alternativa. Por outro lado, REST é muito foda se vc conheçe HTTP direito. Agora, perceba que isto é parte de uma solução, com as abstrações corretas, fica transparente se vc usa um ou outro no fim das contas e isso pode ser muito util.
[quote=peczenyj]A diferença é a tecnologia e os princípios por trás de cada um.
Eu nunca vi um bom exemplo de SOAP logo eu tenho a tendencia de achar que SOAP é necessário para coisas legadas ou que não exista alternativa. Por outro lado, REST é muito foda se vc conheçe HTTP direito. Agora, perceba que isto é parte de uma solução, com as abstrações corretas, fica transparente se vc usa um ou outro no fim das contas e isso pode ser muito util.
http://www.infoq.com/articles/rest-soap-when-to-use-each[/quote]
Na verdade, os princípios de REST são justamente o que podem fazer alguém optar por SOAP. Lembrando que REST possui um conceito um pouco mais complicado de se modelar, que é a orientação a recursos. Acontece que nem tudo pode simplesmente ser modelado como recursos, e outras são simplesmente muito complicadas para serem modeladas assim. Esse aspecto parece estar sendo esquecido por muitos, que acabam criando RPC em cima de HTTP e acham que estão modelando REST.
Para mim, uma coisa é muito clara: é muito mais fácil modelar um serviço SOAP, porque ele é baseado em RPC. Já para consumir serviços, é também muito mais fácil fazer quando eles são REST, porque HTTP já é algo extremamente bem estabelecido no mercado, e todas as linguagens têm seus mecanismos para trabalhar com isso.
[]'s
Procure usar REST sempre que possível porque é mais simples, e nos lugares onde não for possível (por exemplo autenticação de usuário) use RPC sobre HTTP.
Quando usar SOAP? De preferencia nunca.
[quote=Botocudo]Procure usar REST sempre que possível porque é mais simples, e nos lugares onde não for possível (por exemplo autenticação de usuário) use RPC sobre HTTP.
Quando usar SOAP? De preferencia nunca.[/quote]
Para autenticação, usar RPC sobre HTTP? E a autenticação baseada em HTTP, que já é padrão? Você não usaria?
[quote=asaudate]
Para autenticação, usar RPC sobre HTTP? E a autenticação baseada em HTTP, que já é padrão? Você não usaria?[/quote]
Sim usaria, na verdade foi isso que eu quis dizer com “sobre http”, mas “baseado em HTTP” também serve.
O importante é que a informação não esta mais publicamente acessível por meio da url, e sim atras de um formulário de login/senha, por isso não é REST.
[quote=Botocudo][quote=asaudate]
Para autenticação, usar RPC sobre HTTP? E a autenticação baseada em HTTP, que já é padrão? Você não usaria?[/quote]
Sim usaria, na verdade foi isso que eu quis dizer com “sobre http”, mas “baseado em HTTP” também serve.
O importante é que a informação não esta mais publicamente acessível por meio da url, e sim atras de um formulário de login/senha, por isso não é REST.[/quote]
Ser ou não ser acessível por meio de URL não faz ser ou não ser REST. O importante é que a informação esteja rodando com os recursos oferecidos pelo HTTP e baseado em recursos. Por exemplo, um mecanismo de autenticação baseado em token poderia ser feito assim:
SOAP:
Modela-se um método Java para que ele receba um usuário e senha (de preferência, encriptados) e retorne um token:
@WebMethod
public String autenticar (String usuario, String senha) {
...
}REST:
Modela-se o token para que ele seja baseado em recursos. Dessa maneira, o token é “criado” na base online. Isso vira uma requisição POST (HEAD também ficaria interessante), passando um cabeçalho HTTP de autenticação / autorização. Sinto, mas essa maneira não é tão fácil de descrever em código 
Assim, mantenho meu ponto acima: pode ser bem mais fácil modelar várias coisas com SOAP. Para consumir esses serviços, é mais fácil com REST.
[]'s
Hum? Isso é um principio básico do REST.
Não sei o que isso tem a ver com REST, apenas quero deixar claro que sou a favor que use o que for melhor para o seu caso, inclusive o que for mais simples, se este for o critério de “melhor” que está sendo julgado.
Particularmente, não acho autenticação fácil pq estamos falando de segurança, independente de qual tecnologia está sendo usada, mas nunca achei também que fosse presenciar alguém dizer que usar SOAP é fácil. rs
Entenda apenas uma coisa, rodar sobre (ou ser baseado em) HTTP é apenas um detalhe de implementação e não tem a ver com a definição de REST em si. Autenticação HTTP é tão Restful quanto usar cookies, ou seja, nada.
Hum? Isso é um principio básico do REST.
Não sei o que isso tem a ver com REST, apenas quero deixar claro que sou a favor que use o que for melhor para o seu caso, inclusive o que for mais simples, se este for o critério de “melhor” que está sendo julgado.
Particularmente, não acho autenticação fácil pq estamos falando de segurança, independente de qual tecnologia está sendo usada, mas nunca achei também que fosse presenciar alguém dizer que usar SOAP é fácil. rs
Entenda apenas uma coisa, rodar sobre (ou ser baseado em) HTTP é apenas um detalhe de implementação e não tem a ver com a definição de REST em si. Autenticação HTTP é tão Restful quanto usar cookies, ou seja, nada.[/quote]
Poxa, dizer que REST rodar sobre HTTP é “apenas um detalhe” é sacanagem. Desde o princípio, tudo foi descrito, modelado, discutido, tomando como premissa o fato de que roda sobre HTTP e somente sobre HTTP (o que não é o caso do SOAP).
Quanto a dizer que SOAP é fácil, não foi o que eu disse. Disse que existem vários aspectos a serem considerados nessa discussão toda, óbvio. Acho que se for pra usar REST da maneira errada (coisa que, pasmem, é mais regra do que exceção), é melhor usar SOAP, porque SOAP tem um conceito melhor incutido na cabeça de todos nós. RPC é uma coisa que tem váááááários anos de uso, já orientação a recursos é bem mais recente. Acaba que as pessoas ainda tentam enfiar RPC goela abaixo de REST, coisa que é muito errada. Então, sim, modelar SOAP é mais fácil que usar REST por conta disso. Usar, em compensação, pode não ser tão fácil, porque todo mundo sabe que SOAP é bem mais burocrático do que REST.
Enfim, pra concluir: isso é uma questão de expertise. Se a equipe sabe usar REST, vá de REST. Se não sabe, melhor ficar com o SOAP (do que fazer a coisa do jeito errado).
[]'s
Mas o que você disse foi o contrário. Que tudo (ou pelo menos autenticação) foi descrito, modelado e discutido na especificação HTTP tomando como premissa a arquitetura REST. Eu disse que não, e citei cookies, como exemplo de recurso do HTTP que não é compativel com os ideais do REST.
Mas o que você disse foi o contrário. Que tudo (ou pelo menos autenticação) foi descrito, modelado e discutido na especificação HTTP tomando como premissa a arquitetura REST. Eu disse que não, e citei cookies, como exemplo de recurso do HTTP que não é compativel com os ideais do REST.[/quote]
Fato. Na realidade, acho que cookies são na verdade uma gambiarra para contornar a arquitetura do HTTP, que é stateless.
[quote=peczenyj]A diferença é a tecnologia e os princípios por trás de cada um.
Eu nunca vi um bom exemplo de SOAP logo eu tenho a tendencia de achar que SOAP é necessário para coisas legadas ou que não exista alternativa. Por outro lado, REST é muito foda se vc conheçe HTTP direito. Agora, perceba que isto é parte de uma solução, com as abstrações corretas, fica transparente se vc usa um ou outro no fim das contas e isso pode ser muito util.
http://www.infoq.com/articles/rest-soap-when-to-use-each[/quote]
Pacman,
O pessoal está realmente detonando esse artigo nos comentários. Grande parte deles é porque REST foi passado como RPC sobre HTTP, e não como uma abordagem mais voltada a recursos. Exatamente o que eu havia tentado explicar antes: não adianta tratar as duas coisas como se fossem “quase” iguais. Na verdade, existe uma diferença enorme na cultura, no jeito de pensar das duas coisas. E nem sempre os dois cabem para resolver dado problema.
[]'s
A principal diferença é que REST é uma arquitetura e SOAP é um protocolo.
Fonte: http://krams915.blogspot.com.br/2011/02/spring-3-rest-web-service-provider-and.html
Fonte 2: http://en.wikipedia.org/wiki/Representational_State_Transfer
Opa
Galera tem um pouco de receio com SOAP por causa de umas implementações bugadas que existem por ai (tipo as da microsoft). Mas SOAP não é ruim nem complicado, e pode ter tanto overhead quanto REST.