Web API x Web Services

01/09/2014

0

Olá, gente. Como vão?

Andei vendo uns posts sobre Web API e pelop que já estudei, parece muito com MVC (me pareceu um MVC sem as views). Mas minha principal dúvida, de acordo com o que entendi da proposta da Web API, é se ela é uma tecnologia que visa substituir os web services já existentes.

Por exemplo, eu tenho um web service ASMx que fornece dados no formato byte[] para outra aplicação. Tudo funciona muito bem. Aí eu pergunto: seria interessante migrar para Web API?

Obrigada desde já.
Rachel Andrade

Rachel Andrade

Responder

Post mais votado

02/09/2014

Olá Rachel, tudo bem?

O Web API é um framework que surgiu mais recentemente, para a implementação de Web Services seguindo a arquitetura REST. A ideia por trás do desenvolvimento nessa tecnologia é construir serviços com uma estrutura mais simples, substituindo o uso de um XML mais complexo no padrão SOAP por algo equivalente em JSON ou ainda XML puro.

Segue um link de um artigo que escrevi aqui no site a respeito de Web API:

https://www.devmedia.com.br/asp-net-web-api-implementando-servicos-restful/31024

Além de uma estrutura mais simplificada, uma das vantagens em se adotar tal prática seria um menor tráfego de informações ao longo de uma rede (quando comparado a uma mensagem gerada em SOAP).

Acredito que se você já tem um Web Service que atende a um determinado tipo de demanda, talvez não seja tão produtivo substituir o mesmo por algo em Web API. A não ser que vc pretenda reestruturar todo o serviço, a fim de melhorar o código ou implementar novas funcionalidades. Se realmente optar por esse caminho, lembre-se de que a aplicação que consome o serviço também precisará ser alterada.

É importante lembrar ainda que serviços REST também podem ser desenvolvidos a partir de WCF. Além disso, a Microsoft recomenda atualmente que Web Services em SOAP sejam criados usando WCF ao invés do padrão ASMX (mais uma vez, se o seu serviço atende ao que se espera, mudar não trará tantos retornos a meu ver).

Espero que tenha ajudado.

Renato Groffe

Renato Groffe
Responder

Mais Posts

02/09/2014

Rachel Andrade

Olá, Renato. Tudo ótimo, e com você?

Obrigado e parabéns pelo artigo, muito claro e esclarecedor.

Realmente fico com receio de migrar um projeto sem necessidade. Sem querer abusar, você poderia opinar sobre esse meu cenário atual? É o seguinte:

Tenho uma aplicação Windows Phone que recebe dados de um ASMx no formato byte[]. Quando recebo, transoformo esses bytes em um arquivo e passo a utilizá-lo normalmente. Esse arquivo basicamente é um zip contendo outros arquivos XML.

Você acha que o tráfego de dados poderia ser reduzido se eu criasse uma Web API para retornar esses dados diretamente em formato JSON?

Ou seja, o mesmo arquivo em byte[] ou seu conteúdo em JSON, o que seria melhor em termo de tráfego?

Muito obrigada pela atenção e mais uma vez, parabéns pelo artigo.
Responder

02/09/2014

Renato Groffe

Olha Rachel, faz tempo que não faço nada envolvendo manipulação de arquivos via Web Service, mas acredito que sim.

Acho que poderia fazer uma aplicação rápida Web API para comparar isto. Tem um utilitário chamado Fiddler que permite monitorar as respostas geradas por Web Services, logando em tela todo o conteúdo que é devolvido após o processamento de uma requisição.

Por coincidência, publicaram outro post meu a respeito dessa ferramenta esses dias aqui no site:

https://www.devmedia.com.br/utilitario-fiddler-monitoramento-de-web-services/31274

Acredito que você possa comparar e ver a diferença com este programa (que imagino ser significativa).

Abs.
Responder

10/09/2014

Rachel Andrade

Oi, Renato.
Desculpe a demora. O fórum passou uns dias em manutenção. Vou ler seu artigo e fazer uns testes sim, comparando o que fica mais leve, se em byte[] ou JSON.
Obrigada mais uma vez. Volto em breve para dar um feedback.
Responder

17/09/2014

Renato Groffe

Sem problemas Rachel.

Eu também não tive tempo de responder antes.

Abs
Responder

26/11/2015

Alex Sander

Oi, Renato.
Desculpe a demora. O fórum passou uns dias em manutenção. Vou ler seu artigo e fazer uns testes sim, comparando o que fica mais leve, se em byte[] ou JSON.
Obrigada mais uma vez. Volto em breve para dar um feedback.

Como foi seu resultado Rachel? Gostaria de saber seu feedback pois tenho o mesmo dilema em mãos.
Responder

19/02/2016

Helder

Olá pessoal, tudo bem?
Não sei se já conhecem, mas existe uma plataforma para criação de webservices muito eficiente, basta apenas liberar acesso para o banco de dados, e você pode criar uma nova tabela, um novo campo com apenas um clique, talvez ajude muito vocês.
Fica a indicação do Datasocket.
datasocket.co/free
Responder

01/06/2016

Vinicius Barbosa

Oi, Renato.
Desculpe a demora. O fórum passou uns dias em manutenção. Vou ler seu artigo e fazer uns testes sim, comparando o que fica mais leve, se em byte[] ou JSON.
Obrigada mais uma vez. Volto em breve para dar um feedback.


Oi Rachel ...

Bom dia, qual seria o seu feedback ???
Responder

20/02/2017

Rachel Andrade

Oi, pessoal. Desculpem a imensa demora.

No meu caso, optei por trafegar todos os dados em formato JSON, seguindo o que é mais comum em serviços RESTful. Inclusive, isso também facilita a leitura dos dados e evita alguns processamentos. Por exemplo, eu antes juntava vários arquivos em um ZIP que dava poucos KB de tamanho. Então optei por retornar um único JSON com vários registros.

Espero ter ajudado e obrigado a todos pelas colaborações.
Responder

28/03/2017

Natália

Bom dia pessoa, estou com uma duvida nesses códigos:

var client = new RestClient("https://apiteste.com.br");


HttpWebRequest requisicao = (HttpWebRequest)WebRequest.Create("link");


O primeiro "RestClient" seria uma chamada Web Api RESTful, e a segunda "HttpWebRequest" seria um exemplo da chamada de um WebService?
Obrigada.
Responder

21/06/2017

Rodolfo Quinones

Boa tarde
Já vi este artigo em algum outro lugar...
Responder

21/06/2017

Rodolfo Quinones

Olá Rachel, tudo bem?

O Web API é um framework que surgiu mais recentemente, para a implementação de Web Services seguindo a arquitetura REST. A ideia por trás do desenvolvimento nessa tecnologia é construir serviços com uma estrutura mais simples, substituindo o uso de um XML mais complexo no padrão SOAP por algo equivalente em JSON ou ainda XML puro.

Segue um link de um artigo que escrevi aqui no site a respeito de Web API:

https://www.devmedia.com.br/asp-net-web-api-implementando-servicos-restful/31024

Além de uma estrutura mais simplificada, uma das vantagens em se adotar tal prática seria um menor tráfego de informações ao longo de uma rede (quando comparado a uma mensagem gerada em SOAP).

Acredito que se você já tem um Web Service que atende a um determinado tipo de demanda, talvez não seja tão produtivo substituir o mesmo por algo em Web API. A não ser que vc pretenda reestruturar todo o serviço, a fim de melhorar o código ou implementar novas funcionalidades. Se realmente optar por esse caminho, lembre-se de que a aplicação que consome o serviço também precisará ser alterada.

É importante lembrar ainda que serviços REST também podem ser desenvolvidos a partir de WCF. Além disso, a Microsoft recomenda atualmente que Web Services em SOAP sejam criados usando WCF ao invés do padrão ASMX (mais uma vez, se o seu serviço atende ao que se espera, mudar não trará tantos retornos a meu ver).

Espero que tenha ajudado.




Olá, boa tarde
Acho que já vi este artigo em algum outro lugar
Responder

22/06/2017

Joel Rodrigues

Boa tarde
Já vi este artigo em algum outro lugar...


Olá, Dolfo. Tudo bem?

Poderia nos informar em qual outro site você encontrou esse artigo, por favor?
Responder

26/06/2017

Rodolfo Quinones

Hola Joel, bom dia
Foi aqui no Equador, pero não me recuerdo o site, já faz algun tempo. Mas se você deseja mesmo, posso procurar por aqui...
Abraços
Responder

Que tal ter acesso a um e-book gratuito que vai te ajudar muito nesse momento decisivo?

Ver ebook

Recomendado pra quem ainda não iniciou o estudos.

Eu quero
Ver ebook

Recomendado para quem está passando por dificuldades nessa etapa inicial

Eu quero

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar