Por que precisamos de serviços da Web RESTful?

Vou aprender serviços da Web RESTful (é melhor dizer que precisarei fazer isso porque faz parte do programa de mestrado em CS).

Li algumas informações na Wikipedia e também li um artigo sobre o REST na Sun Developer Network e vejo que não é uma tecnologia fácil, existem estruturas especiais para a criação de aplicativos RESTful e, muitas vezes, são comparadas a serviços Web SOAP e O programador deve entender quando usar o SOAP e quando o REST pode ser uma boa abordagem.

Lembro-me de que, há vários anos, o SOAP era muito popular (na moda?) E o item 'SOAP' precisava estar presente em todos os bons currículos. Mas, na prática, era usado muito raramente e para fins muito simples.

Parece-me que o REST é outra 'última palavra da moda' (ou posso estar totalmente errado, porque nunca vi o REST na prática).

Você pode me dar alguns exemplos em que o REST deve ser usado e por que não podemos fazer o mesmo sem o REST (ou por que devemos gastar muito mais tempo para fazer o mesmo sem o REST)?

UPD : Infelizmente, não vejo argumentos concretos que possam me surpreender nos primeiros comentários. Faça-me pensar que o REST é uma tecnologia incrível!

Eu gostaria de ver respostas como esta:

Eu estava desenvolvendo outro aplicativo complexo HelloWorld e precisamos transferir muitos / poucos dados e propus a solução REST para meu colega de trabalho:

- Oh maldito! Jonny, certamente devemos usar o REST para implementar este aplicativo!
- Sim, Billy, podemos usar o REST, mas é melhor usar o SOAP. Confie em mim porque sei algo sobre o desenvolvimento de aplicativos HelloWorld.
- Mas o SOAP é uma tecnologia antiquada do século passado e podemos usar uma melhor.
- Billy, você está pronto para passar três dias experimentando o REST? Podemos fazer isso com o SOAP em 2 horas.
- Sim, tenho certeza de que gastamos ainda mais tempo para alcançar a mesma segurança / desempenho / / escalabilidade / qualquer outra coisa com o SOAP. Tenho certeza de que os aplicativos HelloWorld devem ser desenvolvidos apenas com o REST a partir de agora.

O REST deve ser usado se for muito importante minimizar o acoplamento entre os componentes do cliente e do servidor em um aplicativo distribuído.

Pode ser esse o caso se o servidor for usado por muitos clientes diferentes sobre os quais você não tem controle. Também pode ser o caso se você deseja atualizar o servidor regularmente sem precisar atualizar o software cliente.

Posso garantir que não é fácil alcançar esse baixo nível de acoplamento . É essencial seguir todas as restrições do REST para ter sucesso. É difícil manter uma conexão puramente sem estado. Escolher os tipos de mídia certos e compactar seus dados nos formatos é complicado. Criar seus próprios tipos de mídia pode ser ainda mais difícil.

Adaptar o comportamento rico do servidor à interface HTTP uniforme pode ser confuso e às vezes parece pedante em comparação com a abordagem RPC relativamente direta.

Apesar das dificuldades, os benefícios são que você possui um serviço que um desenvolvedor cliente deve entender facilmente devido ao uso consistente do protocolo HTTP. O serviço deve ser facilmente detectável devido à hipermídia e o cliente deve ser extremamente resiliente às alterações no servidor .

Os benefícios da hipermídia e a evitação do estado da sessão tornam o balanceamento de carga simples e o particionamento de serviços viável . A estrita conformidade com as regras HTTP torna maravilhosa a disponibilidade de ferramentas como depuradores e proxies de cache.

Atualizar

Parece-me que o REST é outra 'última palavra da moda' (ou posso estar totalmente errado, porque nunca vi o REST na prática).

Acho que o REST se tornou moda porque as pessoas que tentam fazer projetos do tipo SOA descobriram que, usando a pilha SOAP, elas não estão percebendo os benefícios prometidos. As pessoas continuam voltando para a web como um exemplo de metodologias simples de integração. Infelizmente, acho que as pessoas subestimam a quantidade de planejamento e previsão necessárias para criar a web e simplificam demais o que precisa ser feito para permitir o tipo de reutilização acidental que ocorre na web.

Você diz que nunca viu o REST na prática, mas isso não pode ser verdade se você usar um navegador da Web. O navegador da web é um cliente REST.

• Por que você não precisa fazer uma atualização do navegador quando alguém altera algum html em um site?
• Por que posso adicionar um novo conjunto completo de páginas a um site e o "cliente" ainda pode acessar essas novas páginas sem uma atualização?
• Por que não preciso fornecer uma "linguagem de descrição de serviço" ao navegador da Web para informar quando acessar http://example.org/images/cat que o tipo de retorno será uma imagem jpeg e quando você for para http://example.org/description/cat, o tipo de retorno será text / html?
• Por que posso usar um navegador da web para visitar sites que não existiam quando o navegador foi lançado? Como o cliente pode saber sobre esses sites?

Podem parecer perguntas insanas, mas se você souber a resposta, poderá começar a ver o que é o REST. Veja StackOverflow para obter mais benefícios do REST. Quando olho para uma pergunta, posso marcar essa página como favorita ou enviar o URL para um amigo e ele pode ver as mesmas informações. Ele não precisa navegar pelo site para encontrar essa pergunta.

O StackOverflow usa uma variedade de serviços OpenId para autenticação, gravatar.com para imagens de avatar, google-analytics e Quantserve para informações analíticas. Esse tipo de integração entre empresas é o tipo de coisa com a qual o mundo SOAP apenas sonha . Um dos melhores exemplos é o fato de as bibliotecas jQuery usadas para direcionar a interface do usuário do StackOverflow serem recuperadas da rede de entrega de conteúdo do Google. O fato de a SO poder direcionar o cliente (ou seja, seu navegador da web) a baixar o código de um site de terceiros para melhorar o desempenho é uma prova do baixo acoplamento entre o cliente da web e o servidor.

Estes são exemplos de uma arquitetura REST em ação.

Agora, alguns sites / aplicativos violam as regras do REST e o navegador não funciona conforme o esperado.

• O famoso problema do botão Voltar é causado pelo uso do estado da sessão no servidor.
• O balanceamento de carga pode se tornar um problema quando você tem o estado da sessão no servidor.
• Os aplicativos Flash geralmente impedem que o URL identifique especificamente uma representação.
• O outro problema que interrompe os navegadores da web é a baixa conformidade com os padrões de tipo de mídia. Ouvimos o tempo todo sobre como o IE6 precisa ser morto. O problema é que os padrões não foram seguidos adequadamente ou foram ignorados por qualquer motivo.
• O uso de sessões de login é a fonte de muitas falhas de segurança.

O REST está em todo lugar. É a parte da web que a faz funcionar bem. Se você deseja criar aplicativos distribuídos que podem ser dimensionados como a Web, seja resistente a alterações como a Web e promova a reutilização conforme a Web, siga as mesmas regras que eles criaram ao criar navegadores da Web.

O REST foi lançado, pelo que sei, pela dissertação de Roy Fielding, Estilos de arquitetura e Design de arquiteturas de software baseadas em rede , que vale a pena ser lida se você ainda não viu.

No topo da dissertação há uma citação:

Quase todo mundo se sente em paz com a natureza: ouvindo as ondas do oceano contra a costa, perto de um lago calmo, em um campo de grama, em uma charneca soprada pelo vento. Um dia, quando tivermos aprendido o caminho atemporal novamente, sentiremos o mesmo em relação a nossas cidades, e nos sentiremos tão em paz neles, como hoje caminhamos à beira-mar ou esticados na grama alta de uma cidade. Prado.

- Christopher Alexander, A maneira atemporal de construção (1979)

E isso realmente resume tudo lá em cima. O REST é de muitas maneiras mais elegante.

O SOAP é um protocolo sobre o HTTP, portanto, ignora muitas convenções HTTP para criar novas convenções no SOAP e, de várias maneiras, é redundante com o HTTP. HTTP, no entanto, é mais do que suficiente para recuperar, pesquisar, gravar e excluir informações via HTTP, e isso é muito do que é REST. Como o REST é construído com HTTP, e não sobre ele, também significa que o software que deseja integrar-se a ele (como um navegador da web) não precisa entender o SOAP para fazer isso, apenas o HTTP, que deve ser o mais amplamente compreendido e integrado com o protocolo em uso neste momento.

A partir daqui :

Vantagens do REST:

• Leve - não há muita marcação extra em xml
• Resultados legíveis por humanos
• Fácil de construir - sem a necessidade de kits de ferramentas

Verifique também isso :

Para ser justo, o REST não é a melhor solução para todos os serviços da Web. Os dados que precisam ser protegidos não devem ser enviados como parâmetros nos URIs. E grandes quantidades de dados, como as dos pedidos de compra detalhados, podem rapidamente se tornar complicadas ou até fora dos limites dentro de um URI. Nesses casos, o SOAP é realmente uma solução sólida. Mas é importante experimentar o REST primeiro e recorrer ao SOAP somente quando necessário. Isso ajuda a manter o desenvolvimento de aplicativos simples e acessível.

Posso dizer com segurança que gastei muito tempo para entender isso como iniciante, mas este é o melhor link para começar com o REST do zero! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

Apenas para puxar você,

Pense no que é um "serviço web tradicional". É uma interface com "métodos" expostos. Os clientes sabem o nome, a entrada e a saída dos métodos e, portanto, podem chamá-los.

Agora imagine uma interface que não exponha "métodos". Em vez disso, expõe "objetos". Portanto, quando um cliente vê essa interface, tudo o que vê é um ou mais "objetos". "Um objeto" não tem entrada e saída - porque "ele não faz nada". É um substantivo, não um verbo. É "uma coisa", não "uma ação".

Por exemplo, pense em um serviço da web tradicional que forneça as condições climáticas atuais, se você fornecer uma cidade. Provavelmente, possui um método da Web, como GetWeatherInfo (), que utiliza uma cidade como entrada e fornece dados climáticos como saída. Até agora, é fácil entender como um cliente consumirá esse serviço da web.

Agora imagine, no lugar do serviço da web acima, existe um novo que expõe cidades como objetos. Então, quando você olha para ele como um cliente, em vez de GetWeatherInfo (), vê Nova York, Dallas, Los Angeles, Londres e assim por diante. E essas cidades não têm nenhum método específico de aplicação dependente delas - elas são aparentemente como gases inertes - elas mesmas não reagem.

Você deve estar pensando - bem, como isso ajuda você, como cliente, a chegar ao clima de Dallas? Chegaremos a isso em alguns momentos.

Se tudo que você obtém de um serviço da web é um "conjunto de objetos", obviamente você precisa de uma maneira de "agir com base neles". Os objetos em si não possuem métodos para você chamar; portanto, você precisa de um conjunto de ações que possa aplicar a esses objetos. Em outras palavras, você precisa "aplicar um verbo ao substantivo". Se você vir um objeto, digamos, uma maçã, que é "um substantivo", poderá aplicar "um verbo" como comer. Mas nem todos os verbos podem ser aplicados a todos os substantivos. Assim, você pode dirigir um carro, mas não pode dirigir uma televisão.

Portanto, se um serviço da Web expuser apenas objetos, e você for solicitado - bem, vamos agora projetar algumas ações ou verbos padrão que "todos os clientes podem aplicar a todos os objetos que veem", ...

Aqui estão algumas idéias:

• O REST restringe seu serviço a usar uma interface uniforme. Você não precisa perder tempo sonhando acordado (ou discutindo) sobre todas as maneiras possíveis de seu serviço - você começa a trabalhar identificando os recursos em seu sistema. Acabou sendo um grande trabalho em si, mas felizmente os problemas tendem a ser muito melhor definidos.
• Com recursos, associações e representações em mãos, há muito pouco a fazer na implementação de seu serviço, porque muitas decisões foram tomadas para você.
• Seu sistema se parecerá muito com outros sistemas RESTful; as curvas de aprendizado para colegas de equipe, parceiros e clientes serão reduzidas.
• Você terá um vocabulário comum para discutir problemas de design com outros desenvolvedores e até mesmo com aqueles menos preocupados tecnicamente (como clientes).
• Como Darrel diz, porque você está usando um design orientado por hipertexto , seu serviço restringe o escopo do acoplamento a apenas uma coisa: os tipos de mídia. Isso ajuda você como desenvolvedor, pois as alterações no seu sistema estão contidas em uma estreita faixa de contato. Isso ajuda seus clientes a diminuir o número de alterações.
• Quase todos os problemas que você pode ter na implementação do REST podem ser resolvidos expondo um novo recurso ou repensando seu modelo de recurso. Esse foco é, na IMO, um grande aumento de produtividade.

Resumindo, o REST remove muitas das decisões de design e implementação mais demoradas e controversas do fluxo de trabalho da sua equipe. Ele muda sua atenção da implementação de seu serviço para o design . E faz isso sem empilhar o gobbledygook no protocolo HTTP.

A maioria das respostas "profissionais" sobre o REST parece vir de pessoas que nunca desenvolveram um serviço ou cliente da Web SOAP usando um ambiente que fornece ferramentas apropriadas para a tarefa. Eles reclamam de problemas que simplesmente nunca encontrei, usando o Visual Studio .NET e o Rational Web Developer da IBM. Suponho que, se você precisar desenvolver serviços da Web ou clientes em uma linguagem de script ou em alguma outra linguagem com pouco ou nenhum suporte a ferramentas, essas são reclamações válidas.

Eu também tenho que admitir que vários dos pontos "profissionais" parecem coisas que podem realmente ser verdadeiras - mas que eu nunca vi um exemplo que ilustra seu valor. Em particular, eu apreciaria muito se alguém publicasse um comentário contendo um link para um bom exemplo de um serviço web REST. Deve ser aquele que usa vários níveis de recursos, possivelmente em uma hierarquia, e que usa tipos de mídia corretamente. Talvez se eu der um bom exemplo, entenderei e, nesse caso, volto aqui e admito.

Para adicionar um toque um pouco prosaico às respostas já dadas a razão pela qual usamos os serviços REST, onde eu estou é que, se você sabe que pode entregar uma URL a um parceiro de negócios e sabe que ele receberá, em troca, uma laje de XML bem definida não importa se eles estão trabalhando em .Net xx, PHP, Python, Java, Ruby ou sabe-se o que isso reduz severamente as dores de cabeça.

Isso também significa que, do lado não técnico, nosso pessoal de vendas pode se gabar de nossa API versátil para pessoas sem medo de parecer muppets completos.

Além dos benefícios técnicos, é fácil para um não técnico explicar, demonstrar e sentir-se confiante. SOAP, embora igualmente legal para os técnicos seja muito menos acessível para os não técnicos e, portanto, não é tão fácil de "vender".

Costumo notar que as coisas que os não-técnicos podem dar a volta na cabeça tendem a ficar. Portanto, duvido que o REST, como técnica, possa ser tão suscetível quanto o SOAP aos caprichos da moda.

Mas tudo o que é necessário para não colocar nada em um serviço REST que deve ser bloqueado é duplo, apenas porque a tecnologia é tão facilmente entendida por pessoas que não são tão tecnicamente preocupadas.

REST é um estilo de arquitetura para projetar aplicativos em rede. A idéia é que, em vez de usar mecanismos complexos como CORBA, RPC ou SOAP para conectar-se entre máquinas, HTTP simples seja usado para fazer chamadas entre máquinas.

De várias maneiras, a própria World Wide Web, baseada em HTTP, pode ser vista como uma arquitetura baseada em REST. Os aplicativos RESTful usam solicitações HTTP para postar dados (criar e / ou atualizar), ler dados (por exemplo, fazer consultas) e excluir dados. Assim, o REST usa HTTP para todas as quatro operações CRUD (Criar / Ler / Atualizar / Excluir).

REST é uma alternativa leve a mecanismos como RPC (Remote Procedure Calls) e Web Services (SOAP, WSDL, et al.). Mais tarde, veremos quanto mais simples o REST é.

Apesar de simples, o REST é completo; basicamente não há nada que você possa fazer nos serviços da Web que não possa ser feito com uma arquitetura RESTful. REST não é um "padrão". Nunca haverá uma recomendação do W3C para o REST, por exemplo. E, embora existam estruturas de programação REST, trabalhar com o REST é tão simples que você pode "rolar sozinho" com recursos de biblioteca padrão em linguagens como Perl, Java ou C #.