Construção de Web Services a maneira DESCANSO

Roger L. Costello

Primeiro vou fornecer uma breve introdução para descansar e, em seguida, descrever como construir serviços da Web no estilo REST.

O que é demais?

REST é um termo cunhado por Roy Fielding em seu Ph.D. dissertação [1] para descrever um estilo de arquitetura de sistemas em rede. REST é um acrônimo para Representational State Transfer.

Por que é chamado Representational State Transfer?

A Web é composto de recursos. Um recurso é qualquer item de interesse. Por exemplo, o Aircraft Corp Boeing pode definir um recurso 747. Os clientes podem acessar esse recurso com este URL:

http://www.boeing.com/aircraft/747

representação do recurso é devolvido (por exemplo, Boeing747.html). A representação coloca o aplicativo cliente em um estado . O resultado do cliente atravessando um hiperlink em Boeing747.html é outro recurso é acessado. A nova representação coloca o aplicativo cliente em um outro estado. Assim, a mudanças no aplicativo cliente ( transferência s) do Estado com cada representação de recurso -> Representational State Transfer!

Aqui está a explicação de Roy Fielding do significado de Representational State Transfer:

"Representational State Transfer destina-se a evocar uma imagem de como um aplicativo da Web bem projetado comporta: uma rede de páginas web (um estado da máquina virtual), onde o usuário avança através de uma aplicação selecionando links (transições de estado), resultando em a página seguinte (representando o próximo estado da aplicação) que estão sendo transferidos para o usuário e processado para a sua utilização ".

A motivação para o descanso

A motivação para o descanso era capturar as características da Web que fez a Web bem sucedido. Posteriormente essas características estão sendo usados ​​para orientar a evolução da Web.

DESCANSO - um estilo de arquitetura, não um padrão

RESTO não é um padrão. Você não vai ver o W3C colocando para fora uma especificação REST. Você não vai ver a IBM ou a Microsoft ou Sun vendendo um kit de ferramentas do desenvolvedor REST. Por quê? Porque resto é apenas um estilo arquitectónico. Você não pode engarrafar esse estilo. Você só pode compreendê-lo, e projetar seus serviços da Web nesse estilo. (Análogo ao estilo arquitectónico cliente-servidor. Não existe um padrão cliente-servidor.)

Enquanto descanso não é um padrão, ele faz padrões de uso:

  • HTTP
  • URL
  • XML / HTML / GIF / JPEG / etc (Resource Representações)
  • text / xml, text / html, image / gif, image / jpeg, etc (tipos MIME)

O Sistema RESTO clássico

A Web é um sistema RESTO! Muitos desses serviços Web que têm vindo a utilizar estes muitos anos - Serviços de livro-encomenda, serviços de busca, serviços on-line do dicionário, etc - são serviços Web baseados em REST. Infelizmente, você estiver usando REST, construção de serviços REST e você não sabe mesmo.

REST está preocupado com a "grande figura" da Web. Ele não lida com detalhes de implementação (por exemplo, usando servlets Java ou CGI para implementar um serviço Web). Então, vamos olhar um exemplo de criação de um serviço de Web do resto perspectiva "big picture".

Peças Depot Web Services

Parts Depot, Inc ( empresa fictícia ) implantou alguns serviços web para permitir aos seus clientes a:

  • obter uma lista de peças
  • obter informações detalhadas sobre uma parte específica
  • enviar uma ordem de compra (PO)

Vamos considerar como cada um desses serviços são implementados de forma RESTful.

Obter lista de peças

O serviço web disponibiliza uma URL para um recurso de lista de peças. Por exemplo, um cliente usaria esta URL para obter a lista de peças:

http://www.parts-depot.com/parts

Note-se que "como" o serviço de web gera a lista de peças é completamente transparente para o cliente. Todo o cliente sabe é que, se ele / ela envia a URL acima, em seguida, um documento que contém a lista de peças é retornado. Desde a implementação é transparente para os clientes, Parts Depot é livre para modificar a implementação subjacente deste recurso, sem afetar os clientes. Este é o baixo acoplamento .

Aqui está o documento que o cliente recebe:

<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.parts-depot.com"
         xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>
      <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/>
      <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/>
      <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>
</p:Parts>

[Suponha que através de negociação de conteúdo do serviço determinado que o cliente quer a representação como XML (para processamento de máquina-a-máquina).] Note-se que a lista de peças possui links para obter informações detalhadas sobre cada parte. Esta é uma característica fundamental do REST. As transferências de clientes de um estado para o próximo, examinando e escolhendo entre as URLs alternativas no documento de resposta.

Obter dados Parte detalhada

O serviço web disponibiliza uma URL para cada recurso de parte. Exemplo, aqui está como um cliente solicita parte 00345:

http://www.parts-depot.com/parts/00345

Aqui está o documento que o cliente recebe:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"  
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>This part is used within the frap assembly</Description>
      <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>10</Quantity>
</p:Part>

Novamente observar como esses dados são ligados dados para ainda mais - a especificação para esta parte pode ser encontrada atravessando o hiperlink. Cada documento de resposta permite que o cliente pesquisa para obter informações mais detalhadas.

Submeta PO

O serviço web disponibiliza uma URL para enviar uma PO. O cliente cria um documento de instância PO que está em conformidade com o esquema PO que Parts Depot tem projetado (e divulgados em um documento WSDL). O cliente envia Po.xml como a carga útil de um HTTP POST.

O serviço PO responde ao HTTP POST com uma URL para o PO apresentado. Assim, o cliente pode recuperar o PO qualquer momento posterior (para atualizar / editar). O PO tornou-se um pedaço de informação que é partilhada entre o cliente eo servidor. As informações compartilhadas (PO) é dado um endereço (URL) pelo servidor e é exposto como um serviço da Web.

URLs lógicos contra URLs físicas

Um recurso é uma entidade conceitual. A representação é uma manifestação concreta do recurso. Este URL:

http://www.parts-depot.com/parts/00345

é um URL lógica, não uma URL física. Assim, não é necessário ser, por exemplo, uma página HTML estático para cada parte. Na verdade, se houvesse um milhão de peças, em seguida, um milhão de páginas HTML estáticas não seria um design muito atraente.

[Detalhe de implementação: Parts Depot poderia implementar o serviço que recebe dados detalhados sobre uma parte específica empregando um Java Servlet que analisa a cadeia após o nome do host, utiliza o número da peça para consultar o banco de dados de peças, formular os resultados da consulta como XML, e em seguida, retornar o XML como a carga útil da resposta HTTP.]

Por uma questão de URLs estilo não deve revelar a técnica de aplicação utilizada. Você precisa ser livre para alterar a sua aplicação, sem afetar os clientes ou ter URLs enganosas.

Erviços Web REST Características

Aqui estão as características de lazer:

  • Cliente-Servidor: um estilo de interação baseada em puxar: componentes que consomem puxar representações.
  • Stateless: cada solicitação do cliente para o servidor deve conter todas as informações necessárias para entender o pedido, e não pode tirar vantagem de qualquer contexto armazenado no servidor.
  • Cache: para melhorar as respostas a eficiência da rede deve ser capaz de ser rotulado como em cache ou não-armazenáveis ​​em cache.
  • interface uniforme: todos os recursos são acessados ​​com uma interface genérica (por exemplo, HTTP GET, POST, PUT, DELETE).
  • Recursos nomeados - O sistema é composto de recursos que são nomeados com um URL.
  • Representações de recursos interligados - as representações dos recursos são interligados usando URLs, permitindo assim que um cliente para o progresso de um estado para outro.
  • Componentes em camadas - intermediários, tais como servidores proxy, servidores de cache, gateways, etc, pode ser inserido entre clientes e recursos para apoiar o desempenho, a segurança, etc.

Princípios do REST Service Design Web

1. A chave para criar serviços Web em uma rede de descanso (ou seja, a Web) é identificar todas as entidades conceituais que você deseja expor como serviços. Acima vimos alguns exemplos de recursos: lista de peças, dados de peças detalhadas, ordem de compra.

2. Criar uma URL para cada recurso. Os recursos devem ser substantivos, verbos não. Por exemplo, não use o seguinte:

http://www.parts-depot.com/parts/getPart?id=00345

Observe o verbo, getPart. Em vez disso, use um substantivo:

http://www.parts-depot.com/parts/00345

3. Categorizar seus recursos de acordo com se os clientes podem apenas receber uma representação do recurso, ou se os clientes podem modificar (adicionar aos) o recurso. Para o primeiro, tornar esses recursos acessíveis através de um HTTP GET. Para a tarde, tornar esses recursos acessíveis usando HTTP POST, PUT e / ou DELETE.

4. Todos os recursos acessíveis via HTTP GET deve ser efeito colateral livre. Ou seja, o recurso deve retornar apenas uma representação do recurso. Invocando o recurso não deve resultar na modificação do recurso.

5. Nenhum homem / mulher é uma ilha. Da mesma forma, nenhuma representação deve ser uma ilha. Em outras palavras, colocar hiperlinks dentro de representações de recursos para permitir que clientes para aprofundar para obter mais informações e / ou para obter informações relacionadas.

6. Projeto de revelar dados gradualmente. Não revele tudo em um único documento de resposta. Fornecer links para obter mais detalhes.

7. Especifique o formato dos dados de resposta, utilizando um esquema (DTD, W3C Schema, RelaxNG ou Schematron). Para os serviços que exigem um POST ou colocar a ele, também fornecem um esquema para especificar o formato da resposta.

8. Descreva como seus serviços são para ser chamado utilizando um documento WSDL, ou simplesmente um documento HTML.

Resumo

Este artigo descreveu resto como um estilo de arquitetura. Na verdade, é o estilo arquitetônico da Web. RESTO descreve o que faz com que a Web funcione bem. Aderindo aos princípios do REST fará com que seus serviços funcionam bem no contexto da Web.

Em um artigo futuro vou escrever sobre a evolução da Web usando os princípios do REST.

Reconhecimento

Graças a Robert Leftwich e Philip Eskelin para os seus muito úteis comentários na criação deste documento.

Referências

[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Origem: http://www.xfront.com/REST-Web-Services.html