Des vêtements, des chaussures, des soldes, ... et des guides mode et beauté !

Criando Serviços da Web o modo REST

Roger L. Costello

Vou primeiro fornecer uma breve introdução ao REST e depois descrever como criar serviços da Web no estilo REST.

O que é REST?

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 de representação de Transferência de Estado.

Por que é chamado de Transferência de Estado Representacional?

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

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

Uma representação do recurso é retornada (por exemplo, Boeing747.html). A representação coloca o aplicativo cliente em um estado . O resultado do cliente que atravessa um hiperlink no Boeing747.html é outro recurso acessado. A nova representação coloca o aplicativo cliente em outro estado. Assim, o aplicativo do cliente muda ( transferência s) com cada representação de recursos -> Representational State Transfer! Aqui está a explicação de Roy Fielding sobre o significado de Representational State Transfer: "Representational State Transfer destina-se a evocar uma imagem de como um aplicativo Web bem concebido se comporta: uma rede de páginas da web (uma máquina de estado virtual), onde o usuário progride através de um aplicativo selecionando links (transições de estado), resultando em A próxima página (que representa o próximo estado da aplicação) será transferida para o usuário e renderizada para uso. "

Motivação para REST

A motivação para o REST foi capturar as características da Web que tornaram a Web bem-sucedida. Posteriormente, essas características são usadas para orientar a evolução da Web.

REST - Estilo arquitetônico, não padrão

O REST não é um padrão. Você não verá o W3C colocar uma especificação REST. Você não verá a IBM ou a Microsoft ou a Sun vendendo o kit de ferramentas do desenvolvedor REST. Por quê? Como o REST é apenas um estilo arquitetônico. Você não pode arrumar esse estilo. Você só pode entender e projetar seus serviços da Web nesse estilo. (Analogamente ao estilo arquitetônico cliente-servidor. Não há padrão cliente-servidor.) Enquanto o REST não é um padrão, ele usa padrões:

  • HTTP
  • URL
  • XML / HTML / GIF / JPEG / etc (Representação de recursos)
  • texto / xml, texto / html, imagem / gif, imagem / jpeg, etc. (Tipos MIME)

O sistema Classic REST

A Web é um sistema REST! Muitos desses serviços da Web que você usou esses muitos anos - serviços de pedidos de livros, serviços de pesquisa, serviços de dicionário on-line, etc. - são serviços da Web baseados em REST. Infelizmente, você está usando REST, criando serviços REST e você nem sabia disso. REST está preocupado com a "grande imagem" da Web. Não trata de detalhes de implementação (por exemplo, usando servlets Java ou CGI para implementar um serviço da Web). Então, vejamos um exemplo de criar um serviço da Web da perspectiva REST "grande imagem".

Serviços Web Parts Depot

Parts Depot, Inc ( empresa fictícia ) implantou alguns serviços da Web para permitir que seus clientes:

  • obter uma lista de peças
  • Obtenha informações detalhadas sobre uma determinada parte
  • envie uma ordem de compra (PO)

Consideremos como cada um desses serviços é implementado de forma RESTful.

Obter lista de peças

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

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

Observe que "como" o serviço da Web gera a lista de peças é completamente transparente para o cliente. Todo o cliente sabe que se ele enviar o URL acima, um documento contendo a lista de peças é retornado. Uma vez que a implementação é transparente para os clientes, o Parts Depot é livre para modificar a implementação subjacente deste recurso sem afetar os clientes. Este é um acoplamento solto .Aqui está o documento que o cliente recebe:

 <? xml version = "1.0"?>
<p: Peças 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: Peças>

[Suponha que, através da negociação de conteúdo, o serviço determinou que o cliente quer a representação como XML (para o processamento máquina-máquina).] Observe que a lista de peças possui links para obter informações detalhadas sobre cada parte. Esta é uma característica fundamental do REST. O cliente transfere de um estado para outro examinando e escolhendo entre os URLs alternativos no documento de resposta.

Obter dados de peças detalhadas

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

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

Aqui está o documento que o cliente recebe:

 <? xml version = "1.0"?>
<p: Parte xmlns: p = "http://www.parts-depot.com"   
        xmlns: xlink = "http://www.w3.org/1999/xlink">
      <ID da peça> 00345 </ Part-ID>
      <Nome> Widget-A </ Nome>
      <Descrição> Esta parte é usada dentro da montagem frap </ Description>
      <Specification xlink: href = "http://www.parts-depot.com/parts/00345/specification" />
      <UnitCost currency = "USD"> 0.10 </ UnitCost>
      <Quantidade> 10 </ Quantidade>
</ p: Part>

Observe novamente como esses dados estão vinculados a mais dados - a especificação para esta parte pode ser encontrada atravessando o hiperlink. Cada documento de resposta permite que o cliente drill down para obter informações mais detalhadas.

Enviar PO

O serviço da Web disponibiliza uma URL para enviar um PO. O cliente cria um documento de instância de PO que está em conformidade com o esquema de PO que o Depósito de peças foi projetado (e divulgado 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 um URL para o PO enviado. Assim, o cliente pode recuperar o PO em qualquer momento depois (para atualizá-lo / editá-lo). O PO tornou-se uma informação que é compartilhada entre o cliente e o servidor. A informação compartilhada (PO) recebe um endereço (URL) pelo servidor e é exposta como um serviço da Web.

URLs lógicos versus URLs físicos

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

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

é um URL lógico, não um URL físico. Assim, não é necessário, por exemplo, uma página HTML estática para cada parte. Na verdade, se houvesse um milhão de partes, então, um milhão de páginas HTML estáticas não seriam um design muito atraente. [Detalhes da implementação: O Depósito de Peças pode implementar o serviço que obtém dados detalhados sobre uma determinada peça empregando um Servlet Java que analisa a string após o nome do host, usa o número da peça para consultar o banco de dados de peças, formula os resultados da consulta como XML e em seguida, devolva o XML como a carga útil da resposta HTTP.] Como uma questão de estilo, os URLs não devem revelar a técnica de implementação utilizada. Você precisa ser livre para alterar sua implementação sem impactar os clientes ou ter URLs enganosas.

Características do REST Web Services

Aqui estão as características de REST:

  • Client-Server: um estilo de interação baseado em pull: componentes de consumo que compõem representações.
  • Apátrida: cada solicitação do cliente ao servidor deve conter todas as informações necessárias para entender o pedido e não pode aproveitar qualquer contexto armazenado no servidor.
  • Cache: para melhorar as respostas de eficiência de rede deve ser capaz de ser rotulado como cacheable ou não-cacheable.
  • 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 usando um URL.
  • Representações de recursos interconectados - as representações dos recursos estão interligadas usando URLs, permitindo assim que um cliente avance de um estado para outro.
  • Componentes em camadas - intermediários, como servidores proxy, servidores de cache, gateways, etc, podem ser inseridos entre clientes e recursos para suportar desempenho, segurança, etc.

Princípios de REST Web Service Design

1. A chave para criar serviços da Web em uma rede REST (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 detalhados das peças, ordem de compra.2. Crie uma URL para cada recurso. Os recursos devem ser substantivos, não verbos. Por exemplo, não use isso:

 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. Categorize seus recursos de acordo com se os clientes podem apenas receber uma representação do recurso ou se os clientes podem modificar (adicionar) o recurso. Para o primeiro, torne esses recursos acessíveis usando um HTTP GET. Para mais tarde, torne esses recursos acessíveis usando HTTP POST, PUT e / ou DELETE. 4. Todos os recursos acessíveis via HTTP GET devem ser livres de efeitos. Ou seja, o recurso deve apenas retornar uma representação do recurso. Invocar o recurso não deve resultar na modificação do recurso. 5. Nenhum homem / mulher é uma ilha. Do mesmo modo, nenhuma representação deveria ser uma ilha. Em outras palavras, coloque hiperlinks dentro das representações de recursos para permitir que os clientes explorem para obter mais informações e / ou para obter informações relacionadas. 6. Design para revelar dados gradualmente. Não revele tudo em um único documento de resposta. Forneça hiperlinks para obter mais detalhes. 7. Especifique o formato dos dados de resposta usando um esquema (DTD, W3C Schema, RelaxNG ou Schematron). Para aqueles serviços que exigem um POST ou PUT para ele, também fornecem um esquema para especificar o formato da resposta. 8. Descreva como seus serviços devem ser invocados usando um documento WSDL ou simplesmente um documento HTML.

Resumo

Este artigo descreveu o REST como um estilo arquitetônico. Na verdade, é o estilo arquitetônico da Web. O REST descreve o que faz com que a Web funcione bem. Aderir aos princípios REST fará com que seus serviços funcionem bem no contexto da Web. Em um futuro artigo, vou escrever sobre a evolução da Web usando os princípios REST.

Reconhecimento

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

Referências

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