Boa apresentação de vocês. Mas, fiquei como uma dúvida: qual a diferença de fazer a solicitação por SOAP, GET ou POST? Quais as vantagens e desvantagens de cada um deles?
Olá, O professor comentou a respeito de uma discussão sobre o "SOAP estar morto". Não entendi bem, poderiam falar mais sobre isso? Leonardo Carlos da Cruz
Leo Cruz, Apesar do uso do protocolo SOAP ser uma recomendação XML Web Services, do consórcio WS-I, muitos web services não seguem tal orientação, utilizando o protocolo HTTP e definindo operações específicas sobre o próprio serviço. O uso de SOAP podem implicar na necessidade de um parser XML externo (msxml.dll) que nem sempre está disponível em computadores com versões do IE anteriores à versão 5.0. Ás vezes, a execução é lenta, principalmente durante a primeira chamada aos procedimentos disponibilizados no servidor. Há também um aumento considerável no tamanho do executável gerado (além da necessidade das dlls do parser XML, caso este não esteja disponível). As mensagens XML contendo informações de cabeçalho causa um tráfego adicional de dados na rede.
A primeira diferença é que o SOAP é um protocolo que define como se enviam objetos de um web service, ao passo que o GET e POST são maneiras de se obter informações de uma solicitação.
Ao se utilizar o método GET, as informações serão obtidas através da URI da solicitação. Já o método POST faz com que o prestador de serviço da solicitação aceite o pacote enviado na requisição como contâiner para os dados da solicitação. Tipicamente, em sistemas Web, os dados em uma solicitação GET vem na URL da página, e os dados POST vêm no formulário submetido pelo usuário.
Já o SOAP é uma técnica utilizada para empacotar os dadaos da solicitação, e pode ser utilizada, na Web, quando sobre o protocolo HTTP, apenas em conjunto com o método POST.
O GET tem a vantagem de ser idempotente e de obtenção de dados direto, pois o endereço é de fácil reconhecimento pela aplicação. A desvantagem é que isto pode expor alguns dados sensíveis e este método também tem uma capacidade de transmissão de dados menor.
O POST possui a vantagem de permitir um maior tráfego de dados, entretanto envolve a necessidade de manutenção do estado no servidor, o que nem sempre é possível. Podemos observar esse efeito em algumas páginas de internet quando clicamos em um botão de enviar, e acionamos a opção voltar do browser. Ele iria tentar fazer um novo envio via POST, mas ao se tentar isso, na maior parte das vezes você observa um comportamento inesperado na aplicação.
Finalmente, o SOAP possui a vantagem de ser um protocolo de fácil reconhecimento pelas aplicações, mas tem a desvantagem de ser muito verboso, o que incorre num maior tráfego de dados e consequente perda de performance das aplicações.
Boa apresentação, mas fiquei com dúvida no slide 7, sobre AJAX. A imagem ilustra como o mesmo programa Java no servidor pode ser base para um mesmo JavaScript para navegadores diferentes. Mas como funciona o DWR que aparece na comunicação entre o JavaScript no cliente e o Java no servidor?
Como o Javascript e Java são linguagens de programação diferentes, é natural que surja uma impedância entre elas, que só é resolvida por meio de técnicas que são orientadas por serviço.
O DWR é uma biblioteca JAVA que instalada no servidor, gera grande parte do código infra-estrutural, repetitivo e maçante que é preciso colocar no Javascript para que ele converse com o servidor JAVA. Logo, para o desenvolvedor de aplicações JAVA que usam AJAX, ele já disponibiliza uma API em Javascript que faz todo esse trabalho 'sujo' (criar um objeto XML HttpRequest, preparar a chamada no formato de um webservice XML, fazer esse trabalho assíncrono, receber a resposta, etc) de forma que a programação de chamada dos métodos Java de forma assíncrona seja o mais parecida com uma típica função Javascript
Existem alguns estudiosos que dizem que o javascript está ficando limitado principalmente em questão de eficiência para o seu uso atual.
Vocês acreditam que isso pode acelerar e promover uma padronização mais firme deste tipo de padrão uma vez que pode ser necessária a criação de uma nova linguagem para web?
Muito boa a apresentação de vocês. Tenho uma pergunta: nas desvantagens, vocês falaram que há um problema de performance quando uma aplicação consome muitos web services. Você acha que isso vai mudar? Como?
Boa apresentação de vocês. Mas, fiquei como uma dúvida: qual a diferença de fazer a solicitação por SOAP, GET ou POST? Quais as vantagens e desvantagens de cada um deles?
ResponderExcluirOlá,
ResponderExcluirO professor comentou a respeito de uma discussão sobre o "SOAP estar morto". Não entendi bem, poderiam falar mais sobre isso?
Leonardo Carlos da Cruz
Leo Cruz,
ResponderExcluirApesar do uso do protocolo SOAP ser uma recomendação XML Web Services, do consórcio WS-I, muitos web services não seguem tal orientação, utilizando o protocolo HTTP e definindo operações específicas sobre o próprio serviço.
O uso de SOAP podem implicar na necessidade de um parser XML externo (msxml.dll) que nem sempre está disponível em computadores com versões do IE anteriores à versão 5.0.
Ás vezes, a execução é lenta, principalmente durante a primeira chamada aos procedimentos disponibilizados no servidor. Há também um aumento considerável no tamanho do executável gerado (além da necessidade das dlls do parser XML, caso este não esteja disponível). As mensagens XML contendo informações de cabeçalho causa um tráfego adicional de dados na rede.
Daniel Chaves,
ResponderExcluirA primeira diferença é que o SOAP é um protocolo que define como se enviam objetos de um web service, ao passo que o GET e POST são maneiras de se obter informações de uma solicitação.
Ao se utilizar o método GET, as informações serão obtidas através da URI da solicitação. Já o método POST faz com que o prestador de serviço da solicitação aceite o pacote enviado na requisição como contâiner para os dados da solicitação. Tipicamente, em sistemas Web, os dados em uma solicitação GET vem na URL da página, e os dados POST vêm no formulário submetido pelo usuário.
Já o SOAP é uma técnica utilizada para empacotar os dadaos da solicitação, e pode ser utilizada, na Web, quando sobre o protocolo HTTP, apenas em conjunto com o método POST.
O GET tem a vantagem de ser idempotente e de obtenção de dados direto, pois o endereço é de fácil reconhecimento pela aplicação. A desvantagem é que isto pode expor alguns dados sensíveis e este método também tem uma capacidade de transmissão de dados menor.
O POST possui a vantagem de permitir um maior tráfego de dados, entretanto envolve a necessidade de manutenção do estado no servidor, o que nem sempre é possível. Podemos observar esse efeito em algumas páginas de internet quando clicamos em um botão de enviar, e acionamos a opção voltar do browser. Ele iria tentar fazer um novo envio via POST, mas ao se tentar isso, na maior parte das vezes você observa um comportamento inesperado na aplicação.
Finalmente, o SOAP possui a vantagem de ser um protocolo de fácil reconhecimento pelas aplicações, mas tem a desvantagem de ser muito verboso, o que incorre num maior tráfego de dados e consequente perda de performance das aplicações.
Otmar Pereira
Boa apresentação, mas fiquei com dúvida no slide 7, sobre AJAX. A imagem ilustra como o mesmo programa Java no servidor pode ser base para um mesmo JavaScript para navegadores diferentes. Mas como funciona o DWR que aparece na comunicação entre o JavaScript no cliente e o Java no servidor?
ResponderExcluirHenrique Chevreux,
ResponderExcluirComo o Javascript e Java são linguagens de programação diferentes, é natural que surja uma impedância entre elas, que só é resolvida por meio de técnicas que são orientadas por serviço.
O DWR é uma biblioteca JAVA que instalada no servidor, gera grande parte do código infra-estrutural, repetitivo e maçante que é preciso colocar no Javascript para que ele converse com o servidor JAVA. Logo, para o desenvolvedor de aplicações JAVA que usam AJAX, ele já disponibiliza uma API em Javascript que faz todo esse trabalho 'sujo' (criar um objeto XML HttpRequest, preparar a chamada no formato de um webservice XML, fazer esse trabalho assíncrono, receber a resposta, etc) de forma que a programação de chamada dos métodos Java de forma assíncrona seja o mais parecida com uma típica função Javascript
Otmar Pereira
Existem alguns estudiosos que dizem que o javascript está ficando limitado principalmente em questão de eficiência para o seu uso atual.
ResponderExcluirVocês acreditam que isso pode acelerar e promover uma padronização mais firme deste tipo de padrão uma vez que pode ser necessária a criação de uma nova linguagem para web?
Muito boa a apresentação de vocês.
ResponderExcluirTenho uma pergunta: nas desvantagens, vocês falaram que há um problema de performance quando uma aplicação consome muitos web services. Você acha que isso vai mudar? Como?