Estação de serviço

Introdução aos serviços RESTful com o WCF

Jon Flanders

Código disponível para download na MSDN Code Gallery
Navegue pelo código online

Sumário

Aprendendo sobre o REST
Um exemplo abstrato
Por que se importar com o REST?
WCF e REST
WebGetAttribute e WebInvokeAttribute
UriTemplate e UriTemplateTable
WebHttpBinding e WebHttpBehavior
WebServiceHost e WebServiceHostFactory
Usando o código de exemplo

Esta é a primeira de uma série de colunas sobre como compilar serviços WCF (Windows Communication Foundation) usando o estilo de arquitetura conhecido como REST (Representational State Transfer). Pode-se dizer que 2009 será o ano do REST aqui na coluna Estação de serviço e, na minha opinião, isso já deveria ter acontecido há muito tempo. O REST é um estilo popular há muitos anos, desde seu lançamento em 2000.

Nesta primeira coluna, quero abordar alguns dos princípios básicos do REST, bem como apresentar uma implementação de um serviço RESTful usando o WCF. Nas próximas colunas, vou detalhar mais as idéias básicas do REST e das tecnologias desenvolvidas com base nele.

Aprendendo sobre o REST

Um estilo de arquitetura é um conjunto de restrições que podem ser aplicadas quando se cria algo. E um estilo de arquitetura de software é algo que descreve os recursos que podem ser usados para orientar a implementação de um sistema de software. O REST é um estilo de arquitetura que pode ser utilizado para compilar software em que os clientes (agentes de usuário) podem fazer solicitações de serviço (pontos de extremidade). O REST é uma forma de implementar um estilo de arquitetura cliente/servidor — na verdade, o REST é explicitamente baseado nesse estilo.

Um homem chamado Roy Thomas Fielding cunhou o termo REST pela primeira vez como um conceito em sua dissertação de doutorado ("Estilos de arquitetura e o projeto de arquiteturas de software baseadas em rede"). Ele foi uma das pessoas a trabalhar na especificação que hoje movimenta grande parte da Internet: o protocolo HTTP. Normalmente, as credenciais das pessoas que descrevem um estilo de arquitetura não é relevante para uma análise do estilo, mas neste caso considero importante porque creio que uma das melhores maneiras de ter um entendimento básico do REST é pensar na Web e como ela funciona.

Presumo que você, como desenvolvedor, esteja familiarizado com a Web (e provavelmente, como eu, é um usuário/viciado pesado diário da Internet). Discutivelmente, a Web pode ser considerada o maior, mais escalonável e mais popular aplicativo distribuído de todos os tempos. As restrições do REST são baseadas nos mesmos princípios básicos que regem a Web. Esses princípios são os seguintes:

• Agentes de usuário interagem com recursos, e recursos são tudo o que pode ser nomeado e representado. Cada recurso pode ser endereçado através de um URI exclusivo.
• A interação com recursos (localizados por meio de URIs únicos) é feita usando-se uma interface uniforme dos verbos HTTP padrão (GET, POST, PUT e DELETE). Também importante na interação é a declaração do tipo de mídia do recurso, o que é designado usando-se o cabeçalho de tipo de conteúdo HTTP. (XHTML, XML, JPG, PNG e JSON são alguns tipos de mídia bastante conhecidos.)
• Os recursos são auto-descritivos. Todas as informações necessárias para processar uma solicitação em um recurso estão contidas na própria solicitação (o que permite que os serviços não tenham monitoração de estado).
• Os recursos contêm links para outros recursos (hipermídia).

Um exemplo abstrato

Um serviço que usa o estilo de arquitetura do REST geralmente é chamado de serviço ou ponto de extremidade RESTful. Só para entendermos um pouco as idéias existentes por trás desse estilo, vou mostrar um pequeno exemplo. Vamos supor que eu precise criar um serviço que funcione com os dados da MSDN Magazine — um serviço que me informe todos os anos em que a revista foi publicada e cada um dos artigos de cada edição. Digamos que a exigência é de que os editores da revista possam usar o serviço para adicionar novos artigos e gerenciar os dados para as próximas edições.

Ao criar serviços RESTful, você pode seguir um conjunto muito simples de etapas básicas para projetar o serviço:

1. Quais serão os recursos?
2. Quais são os URIs que serão usados para representar esses recursos?
3. Que partes da interface uniforme (verbos HTTP) cada URI irá suportar?

Estes são os elementos básicos de um ponto de extremidade RESTful. recursos e suas representações, os URIs desses recursos e as partes da interface uniforme para a qual cada URI responderá. Há recursos mais avançados que você pode aproveitar, como o uso mais explícito de códigos de status e o uso de hiperlinks para gerenciar o estado dos recursos, mas neste exemplo vou me limitar ao básico.

Agora posso utilizar estas etapas para projetar o meu serviço hipotético. Os recursos são todos os anos em que a MSDN Magazine foi publicada, todas as edições publicadas em cada ano e todos os artigos publicados em cada revista. Para este exemplo em particular, usarei um aplicativo de tipo de mídia/xml (XML) para representar estes recursos, mas é importante lembrar que os serviços RESTful não estão de maneira alguma limitados a XML como o tipo de mídia.

Em seguida, preciso determinar os URIs de cada recurso. Agora, só preciso determinar os URIs relativos, uma vez que o URI absoluto será determinado conforme o local em que eu hospedar o ponto de extremidade. A lista de anos será o URI raiz do serviço (/). Usando esta sintaxe, /{ano} retornará todas as edições de cada ano; /{ano}/{edição} será o URI de cada edição (identificarei cada uma pelo mês de publicação); e /{ano}/{edição}/{artigo} representará cada artigo (supondo que cada artigo esteja enumerado de 1 a n em cada edição).

A próxima etapa é o mapeamento de URIs para a interface uniforme. Como o histórico da revista deve ser mesmo somente para leitura, o recurso raiz só irá expor GET. É possível adicionar um novo ano fazendo um PUT para o URI /{ano}. PUT é usado para criar novos recursos quando o URI do novo recurso é conhecido pelo cliente, da mesma forma que seria neste caso. PUT também pode ser usado para atualizar recursos existentes quando o URI é conhecido. POST é usado para criar um recurso quando o cliente não conhece o URI do novo recurso; portanto, POST será o verbo que usarei quando adicionar um novo recurso de artigo, que será enviado para o URI /{ano}/{edição}.

Posso prosseguir com cada recurso e cada verbo, mas felizmente você entendeu as etapas necessárias para determinar o projeto de um ponto de extremidade RESTful. A lista completa de recursos, URIs e verbos pode ser vista na Figura 1.

Se eu quisesse consumir os artigos da edição de janeiro de 2006 como um cliente, faria um HTTP GET para /2006/Janeiro. Se eu fosse o editor e quisesse adicionar um artigo à edição de dezembro de 2008, o cliente faria um POST de um recurso de artigo para /2008/Dezembro, e um novo artigo seria adicionado a essa edição. Este é o padrão que eu continuaria a usar repetidamente para poder consumir este serviço como cliente.

Por que se importar com o REST?

Então, depois de eu ter falado um pouco sobre o REST, você deve estar se perguntando por que deve se importar com ele. Como desenvolvedor, você precisa de motivação para aprender e adotar qualquer estilo, tecnologia ou padrão. Se você está lendo esta revista, provavelmente é um desenvolvedor que trabalha com várias tecnologias da Microsoft. E, para implementar aplicativos cliente/servidor, provavelmente utilizou outro estilo de arquitetura: a RPC (chamada de procedimento remoto). Independentemente de ter usado sistemas RPC proprietários, como DCOM ou .NET Remoting, ou tecnologias RPC interoperáveis, como SOAP, via ASMX ou WCF, estas são as implementações do estilo cliente/servidor que temos na plataforma Microsoft. Então por que aprender ou usar o REST?

No meu entender, há duas razões principais para isso. A primeira delas é que, em muitas situações, o REST oferece alguns recursos e benefícios importantes em comparação com as tecnologias RPC. A segunda razão é que a Microsoft está tirando muitas de suas implementações das tecnologias RPC (como SOAP) e migrando para o REST. Ou seja, mesmo que você não esteja convencido ou motivado a usar o REST para criar seus próprios sistemas, à medida que mais estruturas e tecnologias da Microsoft (e de outros fabricantes) migrarem para o REST, você terá de saber interagir com eles.

A lista a seguir mostra outras vantagens, mas não a considere completa:

Armazenamento em cache Quando os pontos de extremidade RESTful são solicitados a informar dados via HTTP, o verbo HTTP utilizado é GET. Os recursos retornados em resposta a uma solicitação GET podem ser armazenados em cache de várias formas diferentes. O GET condicional, forma de o cliente verificar junto ao serviço se esta versão dos dados ainda é a atual, é um detalhe de implementação opcional que um ponto de extremidade RESTful pode implementar para melhorar ainda mais a velocidade e a escalabilidade.

Expansão O REST incentiva cada recurso a conter todos os estados necessários para processar uma determinada solicitação. Os serviços RESTful são bem mais fáceis de expandir quando atendem a esta restrição e podem não ter monitoração de estado.

Efeitos colaterais Os serviços RESTful não devem ter efeitos colaterais quando você solicita um recurso usando GET (infelizmente, esta restrição é mais fácil de violar do que algumas das outras restrições do REST).

Idempotente Os outros dois principais verbos HTTP normalmente usados como parte da interface uniforme são PUT e DELETE. PUT é usado com mais freqüência quando um agente de usuário quer modificar um recurso, e DELETE é auto-descritivo. A parte importante (e o que a palavra idempotente descreve) é que você pode usar estes dois verbos em um determinado recurso mais de uma vez que o efeito será o mesmo obtido na primeira vez — ou pelo menos não haverá outros efeitos. Isso é reconfortante quando você cria sistemas distribuídos confiáveis nos quais erros, falhas de rede ou latência podem fazer com que o código seja executado várias vezes.

Interoperabilidade Muitas pessoas vendem o SOAP como a maneira mais interoperável de implementar programas cliente/servidor. Mas alguns ambientes e linguagens ainda não têm kits de ferramentas SOAP. E alguns dos que têm são baseados em padrões mais antigos que nem sempre conseguem se comunicar com os kits de ferramentas que implementam novos padrões. O REST só requer que uma biblioteca HTTP esteja disponível para a maioria das operações (claro que uma biblioteca XML também costuma ser útil) e certamente é mais interoperável do que qualquer tecnologia RCP (inclusive o SOAP).

Simplicidade Esta vantagem é mais subjetiva do que as outras e pode ter diferentes significados para diferentes pessoas. Para mim, a simplicidade de usar o REST está relacionada aos URIs que representam recursos e a interface uniforme. Na condição de exímio surfista da Web, entendo isso como digitar diferentes URIs no meu navegador para obter diferentes recursos (o que às vezes é chamado de hacking de URI ou URL, mas não é algo abominável). Por causa desta experiência de usar URIs há muitos anos, para mim, criar URIs para recursos é algo bastante natural. Usar a interface uniforme simplifica o desenvolvimento porque eu não preciso criar uma interface, um contrato ou uma API para cada serviço que tenho de desenvolver. A interface (como os clientes interagem com o meu serviço) é definida pelas restrições da arquitetura.

Como disse antes, esta não é uma lista completa nem você deve considerá-la uma prova conclusiva de que o REST é a única verdadeira tecnologia a ser usada sempre. Você deve conhecer as vantagens para aproveitá-las quando for apropriado.

WCF e REST

O WCF é a estrutura da Microsoft para criar aplicativos que se comunicam através de uma rede, independentemente do estilo ou protocolo. O conceito por detrás do WCF era criar uma estrutura que fosse extensível e conectável para que os desenvolvedores pudessem aprender um modelo de programação e configuração e aplicar essas habilidades a muitos tipos diferentes de sistemas distribuídos.

Embora seja fato que muito do WCF é voltado para o RPC (usando SOAP), na verdade ele tem tido a capacidade de expor e consumir serviços REST desde quando foi lançado como parte do .NET Framework 3.0. O que faltava era um modelo de programação que facilitasse o uso do REST com o WCF. Também havia algumas partes da infra-estrutura que era preciso desenvolver para fazer o REST funcionar com o .NET Framework 3.0. Tanto um modelo de programação quanto essas partes da infra-estrutura foram adicionados ao WCF no assembly System.ServiceModel.Web do .NET Framework 3.5. Além disso, o .NET Framework 3.5 SP1 adicionou alguns pequenos aperfeiçoamentos.

O modelo de programação está centralizado em torno de dois novos atributos, WebGetAttribute e WebInvokeAttribute, e de um mecanismo de modelo de URI que permite declarar o URI e o verbo a que cada método irá responder. A infra-estrutura vem na forma de uma associação (WebHttpBinding) e de um comportamento (WebHttpBehavior) que oferecem a pilha de rede correta para usar o REST. Também existe uma pequena ajuda sobre infra-estrutura de hospedagem de um ServiceHost personalizado (WebServiceHost) e de um ServiceHostFactory (WebServiceHostFactory).

WebGetAttribute e WebInvokeAttribute

Uma das maneiras pela qual o WCF simplifica a criação de sistemas conectados é roteando mensagens de rede para métodos em instâncias das classes que você define como implementações do seu serviço. Assim, você pode se concentrar na lógica do código dos seus serviços e não na infra-estrutura necessária para processar o tráfego de rede.

Por padrão, o WCF faz esse roteamento (também chamado de expedição) baseado no conceito de ação. Para que a expedição funcione, deve haver uma ação em cada mensagem que o WCF recebe em seu nome. Cada ação única é mapeada para um determinado método Action.

O valor é Action baseia-se no nome do método (e no namespace do serviço) ou em um valor personalizado (definido através da propriedade OperationContractAttribute.Action). Este sistema de roteamento está estritamente atrelado ao SOAP, uma vez que o cabeçalho Action da especificação do SOAP é usado por padrão. Felizmente, como a maioria das outras partes do WCF, esta infra-estrutura de expedição padrão é substituível.

Quando você usa a infra-estrutura do REST com o WCF, o dispatcher padrão é substituído por um que faz o roteamento não com base em Action, mas no URI da solicitação recebida e no verbo HTTP que está sendo usado. Este roteamento (feito por uma classe chamada WebHttpDispatchOperationSelector) permite implementar facilmente um ponto de extremidade RESTful. Este dispatcher é configurado em cada ponto de extremidade por um comportamento chamado WebHttpBehavior, que deve ser adicionado a cada ponto de extremidade do qual você quer usar este modelo de programação (embora não precise fazer isso com freqüência manualmente, como verá mais adiante).

O segredo para isso funcionar é que o WebHttpDispatchOperationSelector deve saber como mapear diferentes URIs e verbos para os seus métodos. Para tanto, os atributos WebGetAttribute e WebInvokeAttribute devem ser adicionados aos métodos do seu tipo WCF ServiceContract.

WebGetAttribute informa ao dispatcher que o método deve responder a solicitações HTTP GET. Por padrão, WebInvokeAttribute é mapeado para HTTP POST, mas a propriedade WebInvokeAttribute.Method pode ser configurada para aceitar qualquer um dos outros verbos HTTP (os dois mais comuns são PUT e DELETE). Por padrão, o URI é determinado pelo nome do método (adicionado ao URI de base do ponto de extremidade).

Na verdade, isso não é muito RESTful, uma vez que os nomes de método não são exatamente aquilo com o que você gostaria de tratar no REST porque eles representam verbos. O que você deseja expor como URIs são substantivos. Por isso, o modelo de programação REST do WCF permite personalizar URIs para cada método usando modelos que podem ser definidos através da propriedade UriTemplate em WebGetAttribute ou WebInvokeAttribute.

UriTemplate e UriTemplateTable

Para possibilitar a personalização do URI a cada combinação de método e verbo, o WCF acrescentou a capacidade de definir o URI para cada recurso usando uma sintaxe de modelo especial, como a que usei no início desta coluna para descrever o ponto de extremidade de serviço da MSDN Magazine. Esta sintaxe permite definir, com tokens substituíveis, a estrutura de URI que você gostaria que cada método representasse junto com o verbo HTTP (via WebGetAttribute ou WebInvokeAttribute). Entrarei em mais detalhes da sintaxe em uma próxima coluna.

A Figura 2 mostra a definição de WCF ServiceContract para o serviço da MSDN Magazine (com os atributos e personalizações de UriTemplate apropriados) e aplica os recursos que mencionei anteriormente. Ela estende o sistema de definição de contrato WCF existente com o WebGetAttribute para as operações que devem responder a GET. Também adiciona o atributo WebInvokeAttribute à operação a fim de responder a qualquer outro verbo.

Figura 2 Definição de WCF ServiceContract

[ServiceContract]
public interface IMSDNMagazineService
{
    [OperationContract]
    [WebGet(UriTemplate="/")]
    IssuesCollection GetAllIssues();
    [OperationContract]
    [WebGet(UriTemplate = "/{year}")]
    IssuesData GetIssuesByYear(string year);
    [OperationContract]
    [WebGet(UriTemplate = "/{year}/{issue}")]
    Articles GetIssue(string year, string issue);
    [OperationContract]
    [WebGet(UriTemplate = "/{year}/{issue}/{article}")]
    Article GetArticle(string year, string issue, string article);
    [OperationContract]
    [WebInvoke(UriTemplate = "/{year}/{issue}",Method="POST")]
    Article AddArticle(string year, string issue, Article article);

}

Neste caso, no método AddArticle eu adicionei Method="POST" para facilitara a leitura, pois o verbo padrão para WebInvokeAttribute é POST. Ambos os métodos GET e POST têm personalização de URI usando o atributo UriTemplate. Observe que a sintaxe de UriTemplate possibilita vários segmentos de caminho de variável, e cada um deles é passado para o método como argumento.

WebHttpBinding e WebHttpBehavior

No WCF, uma associação determina como o WCF irá se comunicar. Na verdade, uma associação é a configuração que diz ao WCF como criar o que é chamado de pilha de canal, que consiste no conjunto de objetos que trabalharão juntos para oferecer o tipo de comunicação desejada para um ponto de extremidade específico.

No caso de um ponto de extremidade RESTful, a associação usada é WebHttpBinding. Ao contrário de muitas outras associações, WebHttpBinding é bastante simples e tem apenas dois componentes: o transporte HTTP e o codificador de mensagem de texto (definido para não esperar nem usar SOAP, apenas XML básico).

Como disse anteriormente, WebHttpBehavior é o objeto que faz com que o dispatcher de URI-mais-verbo seja usado, por isso WebHttpBinding e WebHttpBehavior quase sempre são utilizados juntos. Este é o código para criar um ponto de extremidade como esse caso você esteja hospedando internamente um ponto de extremidade WCF RESTful:

ServiceHost sh = 
  new ServiceHost(typeof(MSDNMagazineServiceType));
string baseUri = "http://localhost/MagazineService";
ServiceEndpoint se = 
  sh.AddServiceEndpoint(typeof(IMSDNMagazineService),
  new WebHttpBinding(), baseUri);
se.Behaviors.Add(new WebHttpBehavior());
sh.Open();

Não só tenho de especificar o WebHttpBinding quando adiciono o ponto de extremidade ao ServiceHost, como também devo adicionar WebHttpBehavior explicitamente ao ponto de extremidade para fazer o sistema de expedição de URI-mais-verbo funcionar. É claro que também posso fazer isso com configuração (consulte a Figura 3).

Figura 3 Expedição de URI-mais-verbo em configuração

<configuration>
  <system.serviceModel>
    <services>
      <service name="MSDNMagazine.MSDNMagazineServiceType">
        <endpoint 
          address="http://localhost/MagazineService" 
          binding="webHttpBinding" 
          contract="MSDNMagazine.IMSDNMagazineService" 
          behaviorConfiguration="webby"/>
      </service>
    </services>
    <behaviors>
      <endpointBehaviors>
        <behavior name="webby">
          <webHttp/>
        </behavior>
      </endpointBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

WebServiceHost e WebServiceHostFactory

Uma das reclamações a respeito do WCF é que às vezes ele é muito complexo, principalmente em termos de configuração. Para amenizar essa inquietação com pontos de extremidade RESTful (novamente, a simplicidade é uma das vantagens mais citadas do REST), a Microsoft acrescentou dois novos tipos ao .NET Framework 3.5: WebServiceHost e WebServiceHostFactory.

WebServiceHost é um tipo derivado de ServiceHost que simplifica cenários de hospedagem interna de pontos de extremidade RESTful. O código para hospedagem interna com WebServiceHost é parecido com este:

string baseUri = "http://localhost/MagazineService";
WebServiceHost sh = 
  new WebServiceHost(typeof(MSDNMagazineServiceType),
  new Uri(baseUri));
sh.Open();

Esta é uma bela otimização, pois evita o código repetitivo de adicionar WebHttpBinding e WebHttpBehavior manualmente. A classe WebServiceHost automaticamente cria o ponto de extremidade e o configura com WebHttpBinding e WebHttpBehavior.

Nos cenários de hospedagem gerenciada com WCF, dentro do Internet Information Services (IIS), o WCF normalmente pede um arquivo .svc que aponte para o tipo de serviço, além de entradas no arquivo web.config que informem o WCF sobre o ponto de extremidade (a associação e os comportamentos entre outras configurações).

Visando simplificar o cenário de hospedagem gerenciada, a Microsoft adicionou WebServiceHostFactory, que usa um ponto de extensibilidade WCF aberto (através de um tipo ServiceHostFactory personalizado) nesse cenário para criar uma experiência sem configuração para muitos serviços RESTful. O arquivo .svc é parecido com este:

<%@ ServiceHost Factory=
  "System.ServiceModel.Activation.WebServiceHostFactory"   
  Service="MSDNMagazine.MSDNMagazineServiceType" %>

WebServiceHostFactory cria uma instância de WebServiceHost e, uma vez que este irá auto-configurar o ponto de extremidade usando WebHttpBinding e WebHttpBehavior, não precisa haver configuração para este ponto de extremidade em web.config. (É óbvio que, se você tiver de personalizar a associação, deverá usar o sistema de configuração ou criar uma classe derivada de WebServiceHost/WebServiceFactory). Se eu realmente precisasse personalizar a associação, ainda poderia adicionar as entradas apropriadas no arquivo de configuração. A Figura 4 mostra um arquivo de configuração que ativaria a autenticação básica HTTP no meu ponto de extremidade de serviço.

Figura 4 Ative a autenticação básica HTTP

<configuration>
<system.serviceModel>
  <services>
    <service name="MSDNMagazine.MSDNMagazineServiceType">
      <endpoint 
        address="http://localhost/MagazineService" 
        binding="webHttpBinding" 
        contract="MSDNMagazine.IMSDNMagazineService" 
        behaviorConfiguration="webby"/>
    </service>
  </services>
  <bindings>
    <webHttpBinding>
      <binding name="secure">
        <security mode="Transport">
          <transport clientCredentialType="Basic"/>
        </security>
      </binding>
    </webHttpBinding>
  </bindings>
  <behaviors>
    <endpointBehaviors>
      <behavior name="webby">
        <webHttp/>
      </behavior>
    </endpointBehaviors>
  </behaviors>
</system.serviceModel>
</configuration>

Usando o código de exemplo

Ao longo da explicação sobre os recursos do WCF em relação ao REST, eu mostrei a maior parte da implementação do serviço proposto no início da coluna. Deixe-me explicar a interação com este serviço.

Uma vez que o serviço esteja pronto para funcionar, posso acessar o URI raiz com qualquer cliente, inclusive com um navegador da Web como o Internet Explorer. A maioria das pessoas há de concordar que a capacidade de executar testes rápidos em pontos de extremidade RESTful com um navegador é uma conseqüência bastante útil de o estilo de arquitetura REST ser baseado no funcionamento da Web. Você pode ver o resultado na Figura 5.

Figura 5 URI raiz do recurso

Neste caso, estou hospedando no Visual Studio 2008 Web Development Server, o que determina o URI de base. O Issues.svc é o arquivo necessário para o WCF no cenário de hospedagem gerenciada. Se quero ver o resultado de um ano específico, basta adicionar esse ano ao endereço (o URI) no navegador (consulte a Figura 6).

Figura 6 O recurso que representa o ano 2007

Se eu solicitasse o mês de outubro de 2008, o URI seria localhost:1355/Issues.svc/2008/October, que, neste ponto, seria um conjunto vazio. E, se eu quisesse adicionar um artigo, faria um HTTP POST para esse URI com a representação XML de um artigo como o corpo da solicitação HTTP.

Outro recurso legal do HTTP são todas as ferramentas disponíveis para interagir com ele. Uma das minhas favoritas é o Fiddler, que me permite "espionar" solicitações HTTP e respostas. Mas ele também tem um recurso que me permite fazer operações HTTP arbitrárias. Assim, posso usar a guia Request Builder (Construtor de Solicitação) do Fiddler para fazer meu HTTP POST (consulte a Figura 7). A Figura 8 mostra uma solicitação pelo recurso Outubro de 2008 após o POST.

Figura 7 Fazendo uma solicitação HTTP POST para criar um recurso de novo artigo com o Fiddler

Figura 8 Recurso de artigo adicionado

Embora se possa argumentar que o Internet Explorer e o Fiddler são clientes reais, criar uma implementação cliente/servidor propriamente dita é uma extensão destas etapas simples que acabei de explicar (um exemplo mais complexo da criação de um cliente RESTful será dado em uma próxima coluna). Um cliente precisa saber o URI de cada recurso e que partes da interface uniforme devem ser usadas para cada URI. Dessa forma, ele poderá interagir com o serviço usando essas informações para desenvolver sua funcionalidade.

O que mostrei para você nesta primeira coluna é o conjunto de base de recursos do WCF que permitem usar facilmente o estilo de arquitetura REST nos seus aplicativos .NET. Esta base possibilita outras tecnologias interessantes, como Web feeds (RSS e Atom) e suporte para recursos codificados por JSON para interação com AJAX.

Nas próximas colunas, vou aproveitar essa base de dados de conhecimento sobre REST e WCF e me aprofundar nos detalhes de vários outros recursos da plataforma Microsoft que se baseiam neste estilo e tecnologia. Também abordarei algumas das perguntas mais comuns sobre o REST, como dúvidas sobre segurança e a idéia de implementar pontos de extremidade de processamento.

Envie suas dúvidas e seus comentários para sstation@microsoft.com.

Jon Flanders é consultor independente, palestrante e instrutor da Pluralsight. É especializado em BizTalk Server, Windows Workflow Foundation e Windows Communication Foundation. Você pode entrar em contato com Jon em masteringbiztalk.com/blogs/jon.