Por que precisamos de Serviços Web repousantes?
vou aprender Serviços Web descansados (é melhor dizer que vou ter de fazer isto porque faz parte do programa de mestrado CS).
li alguma informação na Wikipédia e também li um artigo sobre o descanso na Sun Developer Network e vejo que não é uma tecnologia fácil, existem estruturas especiais para construir aplicações RESTful, e muitas vezes é comparado a serviços web SOAP e o programador deve entender quando usar sabão e quando o descanso pode ser bom abordagem.
Lembro-me que há vários anos o sabonete era muito popular.) e o item 'SOAP' tinha que estar presente em todos os bons CV. Mas na prática foi usado muito raramente e para alcançar propósitos muito simples. Parece-me que o descanso é outra "última palavra de moda" (ou posso estar totalmente errado porque nunca vi descanso na prática). Pode dar-me alguns exemplos onde o descanso deve ser usado e por que não podemos fazer o mesmo sem descanso (ou por que devemos gastar muito mais tempo para fazer o mesmo sem descanso)?unfortunately I can't see any concrete arguments which can blow my mind in first comments. Faz-me pensar que o resto é tecnologia incrível!
Gostava de ver respostas destas.Estava a desenvolver outro complexo. Aplicação HelloWorld e precisamos transferir lotes de / minúsculos dados e I solução de repouso proposta para o meu colega de trabalho: - Raios! Jonny, devíamos ... certamente use Resto para aplicação esta aplicação!- Sim, Billy, nós pode usar o descanso, mas é melhor usar SABAO. Confia em mim porque eu sei algo sobre o desenvolvimento do HelloWorld aplicacao.- Mas sabão é tecnologia antiquada dos últimos século e podemos usar melhor um.- Billy, estás pronto? para passar 3 dias para experimentar Descansar? Podemos fazer isto com sabão em 2. horario..– Sim, tenho a certeza. que passaremos ainda mais tempo alcançar o mesmo segurança/desempenho/ / escalabilidade / qualquer outra coisa com sabão. Tenho a certeza que as aplicações HelloWorld deve ser desenvolvido apenas com repouso a partir de agora.
8 answers
O descanso deve ser usado se for muito importante para si minimizar o acoplamento entre componentes do cliente e do Servidor numa aplicação distribuída.
Este pode ser o caso se o seu servidor for usado por muitos clientes diferentes sobre os quais não tem controlo. Também pode ser o caso se você quiser ser capaz de atualizar o servidor regularmente sem precisar atualizar o software cliente.
Posso garantir-lhe que alcançar este nível baixo of coupling is not easy to do . É fundamental seguir todas as restrições do descanso para ter sucesso. Manter uma ligação puramente sem estado é difícil. Escolher os tipos de mídia certos e apertar os seus dados para os formatos é complicado. Criar seus próprios tipos de mídia pode ser ainda mais difícil.Adaptar o rico comportamento do servidor na interface HTTP uniforme pode ser confuso e às vezes parece pedante em comparação com o RPC relativamente simples abordagem.
Apesar das dificuldades, os benefícios são que você tem um serviço que um desenvolvedor cliente deve ser capaz de compreender facilmente devido ao uso consistente do protocolo HTTP. O serviço deve ser fácil de descobrir devido à hypermedia e o cliente deve ser extremamente resiliente a alterações no servidor .
Os benefícios da hypermedia e a prevenção do Estado de sessão tornam o equilíbrio de carga simples e o particionamento do serviço viável . O a estrita conformidade com as regras do HTTP faz com que a disponibilidade de ferramentas como debuggers e proxies caching seja uma coisa maravilhosa.
Actualizar
Parece-me que o descanso é outro "última palavra da moda" (ou posso ser totalmente errado porque eu nunca ver descanso na prática).Eu acho que o descanso se tornou moda porque as pessoas que tentam fazer projetos tipo SOA descobriram que usando a pilha de sabão eles não estão percebendo os benefícios que foram prometido. As pessoas continuam voltando para a web como um exemplo de metodologias de integração simples. Infelizmente, eu acho que as pessoas subestimam a quantidade de planejamento e previsão que foi para a criação da web e eles simplificam demais o que precisa ser feito para permitir o tipo de reutilização acidental que ocorre na web.
Diz que nunca viu o descanso na prática, mas isso não pode ser verdade se alguma vez usar um navegador web. O navegador web é um descanso cliente.
- porque não precisa de fazer um navegador actualizar quando alguém alterar algum html num site? Porque posso adicionar um novo conjunto de páginas para um site e o"cliente" ainda pode acessar essas novas páginas sem uma actualização?
- porque não preciso de fornecer um "serviço-descrição-língua" para o navegador web para dizer quando vai para http://example.org/images/cat que o tipo de retorno será uma imagem jpeg e quando fores para http://example.org/description/cat o tipo de retorno será text / html?
- porque posso usar um navegador web para visitar sites que não existiam quando o o browser foi lançado? Como pode o o cliente sabe destes sites?
O StackOverflow utiliza uma variedade de serviços OpenId para Autenticação, gravatar.com para imagens avatar, google-analytics e Quantserve para informações analíticas. Este tipo de integração multi-empresa é o tipo de coisa que o mundo do sabão só sonha com. Um dos melhores exemplos é o facto de as bibliotecas jQuery que estão habituadas a drive the StackOverflow UI são recuperados a partir da rede de entrega de conteúdo do Google. O fato de que assim poderia direcionar o cliente (ou seja, seu navegador web) para baixar o código a partir de um site de terceiros para melhorar o desempenho é testemunho do baixo acoplamento entre cliente web e servidor.
Estes são exemplos de uma arquitetura de descanso no trabalho.Agora alguns sites / aplicações web quebram as regras do REST e então o navegador não funciona como esperado.
- a infamous problema no botão de trás é causado pelo uso do lado do servidor estado da sessão. A balanceamento de carga pode tornar-se uma dor quando você tem o estado de sessão do lado do servidor.
- as aplicações Flash muitas vezes impedem a URL da identificação específica de um representacao. O outro problema que quebra a rede os navegadores estão em má conformidade com padrões do tipo media. Ouvimos tudo the time about how IE6 needs to be cancelar. O problema é que as normas não foram devidamente respeitadas, ou foram ignorados por qualquer razão.
- a utilização das sessões de autenticação é a fonte de muitos buracos de segurança.
O descanso foi arrancado, tanto quanto sei, pela dissertação de Roy Fielding estilos arquitectónicos e o Design de Arquitecturas de Software baseadas em rede , o que vale a pena ler se ainda não olhaste para ele.
No topo da dissertação está uma citação:
quase todos se sentem em paz com a natureza: ouvindo o oceano ondas contra a costa, por um lago calmo, num campo de relva, em um heath windblown. Um dia, quando tivermos aprendido o caminho eterno mais uma vez, nós sentiremos o mesmo em relação às nossas cidades, e sentiremos o mesmo muito em paz neles, como fazemos hoje caminhando pelo oceano, ou estendido na relva comprida de um prado.
- Christopher Alexander, O modo intemporal de construir (1979)
E isso resume tudo. O descanso é, em muitos aspectos, mais elegante. O SOAP é um protocolo no topo do HTTP, por isso contorna muitas convenções HTTP para construir novas convenções no SOAP, e é, de várias formas redundante com HTTP. HTTP, no entanto, é mais do que suficiente para arquivar, pesquisar, escrever e apagar informações via HTTP, e isso é muito do que o resto é. Porque o descanso é construído com HTTP em vez de em cima dele, também significa que o software que quer se integrar com ele (como um navegador web) não precisa entender SOAP para fazer isso, apenas HTTP, que tem que ser o mais amplamente compreendido e integrado-com protocolo em uso neste ponto.Outras vantagens:
- leve-não há muita marcação xml extra
- Resultados Legíveis Pelo Homem
- Fácil de construir-não são necessárias ferramentas
Verifique também Este para fora:
Para ser justo, o descanso não é a melhor solução para todos os serviços da Web. Os dados que precisam ser seguros não devem ser enviados como parâmetros em URIs. E grandes quantidades de dados, como aquele em ordens de compra detalhadas, pode rapidamente tornar-se pesado ou mesmo fora dos limites dentro de um URI. Nestes casos, o sabão é realmente uma solução sólida. Mas é importante tentar descansar primeiro e recorrer ao sabão apenas quando necessário. Isso ajuda a manter o desenvolvimento de aplicativos simples e acessível.
Só para te puxar,
Pense no que é um "serviço web tradicional". É uma interface com métodos expostos."Os clientes conhecem o nome, entrada e saída dos métodos e assim pode chamá-los. Agora imagine uma interface que não exponha "métodos". Em vez disso, expõe "objectos". Então, quando um cliente vê esta interface, tudo o que vê é um ou mais "objetos". "Um objecto" não tem entrada nem saída – porque "não faz nada". É um substantivo, não um verbo. É " a coisa", não "Acção".Por exemplo, pense num serviço web tradicional que fornece o condições meteorológicas atuais se você lhe fornecer uma cidade. Provavelmente. tem um método web como GetWeatherInfo() que leva uma cidade como entrada e fornece dados meteorológicos como saída. É fácil para ti até agora entenda como um cliente vai consumir este serviço web.
Agora imagine, no lugar do serviço web acima, há um novo isso expõe as cidades como objectos. Então, quando você vê isso como um cliente, em vez de GetWeatherInfo(), você vê Nova York, Dallas, Los Angeles, Londres e assim por diante. E estas cidades não têm nenhuma aplicação métodos específicos Pendurados deles-eles são aparentemente como inerte gases-eles próprios não reagem. Deve estar a pensar – bem, como é que isso o ajuda, como cliente, a ... chegar ao tempo de Dallas? Chegaremos a isso dentro de momentos.Se tudo o que você obtém de um serviço web é um "conjunto de objetos", obviamente você preciso de uma maneira de "agir sobre eles". Os próprios objectos não têm métodos para você ligar, então você precisa de um conjunto de ações que você pode aplicar estes objectos. Em outras palavras, você precisa " aplicar um verbo ao substantivo". Se você vê um objeto, digamos, uma maçã, que é "um substantivo", você pode aplicar "um verbo" como comer. Mas nem todos os verbos podem ser aplicados a todos substantivo. Como, você pode dirigir um carro, mas não pode dirigir uma televisão.
Assim, se um serviço web expõe apenas objetos – e você é perguntado-bem, vamos agora projetar algumas ações padrão ou verbos que " todos os clientes pode aplicar-se a todos os objectos que vêem", ...
Eu também tenho que admitir que vários dos pontos " pro " soam como coisas que podem realmente ser verdade - mas que eu nunca vi um exemplo que ilustra o seu valor. Em particular, eu apreciaria muito se alguém postasse um comentário contendo um link para um bom exemplo de um serviço web de descanso. Este deve ser um que usa vários níveis de recurso, possivelmente em uma hierarquia, e que usa os tipos de mídia corretamente. Talvez se eu olhar para um bom exemplo, eu vou entender, em nesse caso, eu volto aqui e admito.
Para adicionar um pouco prosaico de rotação para as respostas já dadas a razão utilizamos os serviços REST, onde eu estou, é que, se você sabe que você pode entregar um parceiro de negócio de uma URL, e sei que eles vão receber, em retorno, um bem estabelecidas laje de XML não importa se eles estão trabalhando .X Net.x, PHP, Python, Java, Ruby ou deus-sabe-o que reduz drasticamente dores de cabeça.
Também significa que, no final dos negócios, as nossas pessoas podem gabar-se da nossa versátil API a pessoas sem receios de parecem marretas. Para além dos benefícios técnicos, tudo o que é fácil para um não-técnico explicar, demonstrar e sentir-se confiante é uma coisa boa. Sabão, embora tão fresco para os técnicos é muito menos acessível pelos não-técnicos e, portanto, não é tão fácil de "vender". Tenho tendência a reparar que as coisas que não são técnicas podem ter a cabeça redonda tendem a colar. Por isso duvido que descansar como técnica seja tão susceptível como sabão aos caprichos de moda. Mas todas as coisas sobre não colocar nada em um serviço de descanso que deve ser bloqueado é duplamente verdade, quanto mais não seja porque a tecnologia é tão facilmente compreendida por pessoas que não são tão tecnicamente inteligentes.- O descanso obriga o seu serviço a usar uma interface uniforme. Você não tem que perder tempo sonhando (ou discutindo) sobre todas as formas possíveis de seu serviço poderia funcionar - você começa direito a trabalhar identificando os recursos em seu sistema. Acaba por ser um grande trabalho em si, mas felizmente os problemas tendem a ser muito mais bem definidos. Com os recursos, as suas associações e as suas representações em mãos, há muito pouco a fazer em implementando seu serviço porque muitas decisões foram tomadas por você. O seu sistema será muito parecido com outros sistemas repousantes; as curvas de aprendizagem para colegas de equipa, parceiros e clientes serão reduzidas.
- você terá um vocabulário comum para discutir problemas de design com outros desenvolvedores, e mesmo com aqueles menos tecnicamente minded (como clientes). Como o Darrel diz, Porque estás a usar um desenho de hipertexto, o teu serviço restringe o âmbito do acoplamento. só para uma coisa: os media. Isso ajuda você como um desenvolvedor, porque as mudanças no seu sistema estão contidos dentro de uma estreita faixa de contato. Isso ajuda seus clientes em que menos de suas alterações quebrarão seu código. Quase todos os problemas que possa ter na implementação do descanso podem ser resolvidos expondo um novo recurso ou repensando o seu modelo de recursos. Este foco é, IMO, um grande aumento da produtividade.
Resumindo, o descanso remove muitas das mais demoradas e decisões controversas de design e implementação do fluxo de trabalho de sua equipe. Muda a sua atenção de implementar o seu serviço para projectá-lo. E ele faz isso sem empilhar gobbledygook no protocolo HTTP.
O descanso é um estilo de arquitectura para a concepção de aplicações em rede. A idéia é que, ao invés de usar mecanismos complexos como CORBA, RPC ou SOAP para se conectar entre máquinas, HTTP simples é usado para fazer chamadas entre máquinas.
De muitas maneiras, a própria World Wide Web, baseada em HTTP, pode ser vista como uma arquitetura baseada no resto. Aplicações RESTful usam solicitações HTTP para postar dados (criar e/ou atualizar), ler dados (por exemplo, fazer consultas), e excluir dados. Assim, as outras utilizações HTTP para todas as quatro operações CRUD (Create/Read/Update/Delete).
O descanso é uma alternativa leve a mecanismos como o RPC (chamadas de procedimento remoto) e serviços Web (SOAP, WSDL, et al.). Mais tarde, veremos quanto mais simples é o descanso.
Apesar de ser simples, o descanso é totalmente caracterizado; não há basicamente nada que você possa fazer em serviços Web que não possa ser feito com uma arquitetura repousante. O descanso não é um"padrão". Nunca haverá um W3C recommendataion para descanso, por exemplo. E enquanto existem frameworks de programação REST, trabalhar com o REST é tão simples que você pode muitas vezes "rolar seu próprio" com recursos de biblioteca padrão em linguagens como Perl, Java, ou C#.