Por que precisamos de serviços da Web RESTful?


123

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.


2
Não é uma tecnologia incrível - é uma tecnologia diferente. Se você quer que alguém o convença de que é incrível e deve ser usado sempre, tente um consultor.
quillbreaker

Respostas:


133

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.


@Darrell: como no mundo o REST reduz o acoplamento sobre o SOAP? Ou, como o SOAP aumenta o acoplamento sobre o REST? Você está se referindo ao fato de que um cliente SOAP realmente precisa entender o SOAP, mas um cliente REST precisa entender apenas os tipos de mídia?
John Saunders

4
@John Geralmente, a maneira como o SOAP é usado faz com que o cliente exija conhecimento "compilado" de todos os pontos de extremidade do servidor, todos os tipos de dados de parâmetros e todos os tipos de retorno. Não há orientação no mundo SOAP para tentar usar tipos padronizados para transmitir dados entre cliente e servidor. Isso significa que todo novo serviço que um desenvolvedor cliente usa, possui seu próprio conjunto exclusivo de tipos, terminais e protocolo de interação. Isso é acoplamento.
Darrel Miller

O @John REST tenta padronizar o protocolo de interação com a semântica dos verbos HTTP, os formatos de dados para os tipos registrados da IANA e todos os pontos de extremidade devem ser descobertos dinamicamente. Isso significa que o acoplamento cliente / servidor está localizado na definição do tipo de mídia. Assim como Rich disse, "seu serviço reduz o escopo do acoplamento a apenas uma coisa: os tipos de mídia".
Darrel Miller

@ Darrell: isso não é acoplamento no sentido tradicional. O cliente pode ser considerado "acoplado" aos metadados (o WSDL), mas não ao serviço. Considere um serviço que retorna um "Funcionário": {int id; string firstName, lastName, streetAddress1, streetAddress2, cidade, estado; int zip;}. Você parece sugerir que registremos "Empregado" na IANA ou que apenas consideremos "Empregado" uma matriz associativa de pares nome / valor.
John Saunders

@ John Deixe-me definir o que quero dizer com acoplamento em termos WSDL. Imagine poder ter um contrato de serviço no qual você possa adicionar métodos, remover métodos e renomear métodos sem precisar recompilar o cliente. Considere também que o cliente pode ser instruído a usar esses novos métodos sem recompilação. O contrato de mensagem é corrigido pelo HTTP, mas é extensível por meio de cabeçalhos e o contrato de dados é a única alteração que pode interromper um cliente; no entanto, usando metadados no contrato de mensagem, o servidor pode entregar dinamicamente a versão apropriada do contrato de dados ao cliente.
Darrel Miller

11

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.


O SOAP foi definido em 1998. Quantas "convenções" HTTP eram convenções naquela época?
John Saunders

De acordo com este w3.org/Protocols/HTTP/1.0/spec.html, o HTTP está em uso desde 1990. E daí? Todos sabemos que o único motivo pelo qual o SOAP usa o http foi porque a porta 80 provavelmente estava aberta no firewall. A Microsoft não cometeria o erro DCOM novamente.
Darrel Miller

1
"O REST é construído com HTTP em vez de em cima dele " +1. Esse segmento inteiro é realmente útil para eu entender a validade do uso de REST sobre SOAP e vice-versa.
precisa

9

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.


4
O comentário contras não está muito correto. Ao mover um parâmetro do URI para o corpo, isso ainda não é seguro. Use SSL para segurança. Além disso, quando os dados no URI podem ser muito longos, você pode usar a postagem e colocá-los no corpo. A maioria dos idiomas do servidor combina os dados dos parâmetros URI e POST, portanto, nenhuma alteração no servidor deve ser necessária.
Emil Ivanov

1
@Emil - Lembre-se de que o SSL nem sempre está disponível. Algumas pessoas desejam segurança baseada em mensagens e não transporte segurança baseada no nível. E no que diz respeito ao uso do corpo de um POST ... POST é um dos verbos usados ​​para processar solicitações REST. Você nem sempre pode reutilizá-lo para atender às suas necessidades.
Justin Niessner 02/09/09

1
Um grande CON: não padronizados "descrição" linguagem como WSDL para serviços SOAP - cada poder serviço REST ou não pode ser documentada, e a qualidade da documentação é muito diferente da oferta de serviços para outro .....
marc_s

3
@Marc_s Se o REST for feito corretamente, não há necessidade de uma "linguagem de descrição" como o WSDL. Os tipos de mídia usados ​​precisam ser documentados, mas não deve existir documentação que associe os pontos finais aos tipos de mídia.
Darrel Miller

@ Darrel: Me desculpe, eu não compro o absurdo "sem descrição". Mesmo que os tipos de documento estejam documentados, eles também precisam ser descritos. Além disso, algumas pessoas realmente gostam de desserializar o conteúdo em objetos em uma linguagem de programação. Nesse caso, é muito útil ter uma definição legível por máquina do que o serviço pode enviar e receber, para que sua ferramenta possa criar as classes correspondentes e o código de serialização.
John Saunders

8

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", ...


Então, qual é o benefício de ter objeto em vez de método?
Soumya Rauth

4

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.


@ John Se eu inicializar o VS e criar um projeto WCF e criar uma interface com o atributo [ServiceContract], eu posso adicionar qualquer chamada de método que eu desejar. CreateCustomer (), MakeOrder (), ConfirmOrder (), VerifyOrder (), SubmitOrder (), CheckStockAvailability (), CancelOrder () A partir desses métodos, você pode me dizer qual sequência devo usar para processar um pedido? Você pode me dizer quando posso ligar para CancelOrder ()? Devo verificar a disponibilidade antes de confirmar o pedido? Devo verificar o pedido antes de verificar a disponibilidade? É provável que essa interface não seja consistente com a da folha de pagamento.
Darrel Miller

1
@ Darrel: Não vejo como o REST ajuda a resolver isso. Fornece MakeOrderURLs para ConfirmOrdere CancelOrder? O cliente ainda não sabe como chamar o serviço, mas precisa ser orientado por dados?
John Saunders

1
@ John Exatamente. O cliente sabe que os URLs ConfirmOrder e CancelOrder podem ser fornecidos, mas não sabe como são esses URLs e só os seguirá se fornecidos. Você chama isso de orientado a dados, Roy chama de hipermídia como o mecanismo do estado do aplicativo.
Darrel Miller

@ Darrel: Acho que nunca vi nenhum serviço crítico para os negócios em que quero determinar o que chamar em seguida, com base no URL que foi passado na chamada anterior.
John Saunders

1
@ JohnSaunders: isso ocorre porque uma chamada REST não é sobre chamadas de método, mas transição de estado (pense em máquina de estado). Em qualquer estado, um servidor RESTful especificaria transições de estado válidas e o usuário ou agente escolherá as transições que deseja seguir.
Lie Ryan

4

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.


O melhor exemplo publicamente visível até o momento é a API da Sun Cloud. Aqui está uma explicação passo a passo kenai.com/projects/suncloudapis/pages/… Apenas para qualificar minha experiência com SOAP. Criei e ainda suportei serviços Web ASMX usando o Web Service Software Factory da Microsoft do grupo Patterns and Practices. Criei serviços baseados no WCF usando uma versão posterior da mesma fábrica de software. Eu usei também System.ServiceModel.Web do WCF desde que é foi lançado pela primeira vez com o Biztalk Services SDK em maio de 2007.
Darrel Miller

1
John - um exemplo de uma API de descanso é o Amazon. Eles possuem uma API @SOAP e uma REST. Pode ser útil para você
RichardOD

3

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.


3

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 #.


" 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). "Este é outro ótimo exemplo prático para eu tirar essa postagem. Obrigado.
precisa
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.