.NET - Apresentando os fundamentos do REST

 Neste artigo vou apresentar os princípios básicos do REST - Representational  State Transfer.

Já ouviu falar em REST ?

E em RESTful ?

Sabe o que significam esses termos ?

Indo direto ao ponto, RESTful é a capacidade de implementar REST.

REST ou Representational  State Transfer é uma estilo de arquitetura que é composta por um conjunto de restrições aplicadas a componentes e conectores e elementos de dados em um sistema de hipermídia distribuído. ( https://pt.wikipedia.org/wiki/REST)

Deu para clarear um pouco ?

Resumindo : REST consiste em princípios, regras e restrições que, quando seguidas, permitem a criação de um projeto com interfaces bem definidas para comunicação.

A seguir veremos os 5 princípios que tornam sua aplicação HTTP uma aplicação REST.

1 - Tudo é um recurso

Para entender esse princípio, é preciso conceber a idéia de representar dados por um formato específico e não por um arquivo físico.

Cada dado disponível na Internet possui um formato que poderia ser descrito por um tipo de conteúdo.

Por exemplo, imagens JPEG, Vídeos MPEG, HTML, XML, documentos de texto, e dados binários são todos os recursos com o seguinte conteúdo : imagem / jpeg, video / mpeg, texto/html, texto/xml e stream.

2 - Cada recurso é identificável por um único identificador

Como a Internet contém tantos recursos diferentes, todos eles devem ser acessíveis através de URIs e devem ser identificados de forma exclusiva. Além disso, as URIs podem ser legíveis por humanos, apesar do fato de que seus consumidores são mais propensos a ser programas de software.

As URI legíveis por humanos mantêm os dados auto-descritivos e facilitam o desenvolvimento e isso ajuda você a reduzir ao mínimo o risco de erros lógicos em seus programas.

A seguir temos alguns exemplos de exemplos de URIs:

Essas URIs expõem diferentes tipos de recursos de forma direta.

No exemplo, é bastante claro que os tipos de mídia desses recursos são : imagens, videos, documentos XM e, de documentos de arquivos binários.

3 - Utiliza os métodos HTTP padrão

O protocolo HTTP (RFC 2616) define oito ações também conhecidos como verbos HTTP:  GET, POST,  PUT,  DELETE, HEAD, OPTIONS, TRACE e CONNECT.

Os quatro primeiros (GET, POST, PUT e DELETE) atuam no contexto dos recursos, especialmente ao definir ações para manipulação de dados de recursos.

Aplicando os princípios REST corretamente esses verbos devem ser usados da seguinte forma:

Verbo HTTP Ação Código de Status da Resposta
GET Requisita um recurso existente "200 OK" se o recurso existir
"404 Not Found se o recurso não existir
"500 Internal Server Error" para outros erros
POST
Cria um recurso com um identificador gerado do lado do servidor ou atualiza um recurso com um identificador existente fornecido pelo cliente 		 "201 CREATED" se um novo recurso for criado
"200 OK " se o recurso foi atualizado
"500 Internal Server Error" para outros erros
PUT Atualiza um recurso ou cria um recurso com um identificador fornecido pelo cliente "201 CREATED" se um novo recurso for criado
"200 OK " se o recurso foi atualizado com sucesso
"404 Not Found se o recurso a ser atualizado não existir
"500 Internal Server Error" para outros erros
DELETE Deleta um recurso "200 OK "  ou "204 No Content se o recurso foi deletado com sucesso
"404 Not Found se o recurso a ser deletado não existir
"500 Internal Server Error" para outros erros

Observe que um recurso pode ser criado usando os verbos POST e PUT.

Quando o recurso tem que ser criado em uma URI específica com um identificador fornecido pelo cliente o verbo PUT é a ação apropriada. Porém sua aplicação pode querer deixar para aplicação REST do servidor decidir onde colocar o novo recurso criado e dessa forma criá-lo em um local desconhecido.

4 - Recursos podem ter múltiplas representações

Uma das principais características de um recurso é que ele pode ser representado de forma diferente daquela na qual foi armazenado. Assim, ele pode ser solicitado ou postado em diferentes representações.

Assim que o formato especificado for suportado, o end-point REST habilitado deve usá-lo.  Como exemplo podemos postar uma representação no formato XML de um saldo, mas se o servidor suportar o Formato JSON, uma requisição no formato JSON pode ser enviada.

5 - Comunicação sem estado

As operações de manipulação de recursos através de solicitações HTTP devem sempre ser consideradas atômicas. Todas as modificações de um recurso devem ser realizadas dentro de uma solicitação HTTP em
isolamento.

Após a execução do pedido, o recurso é deixado em um estado final, o que implicitamente significa que as atualizações parciais de recursos não são suportadas. Você sempre deve enviar o
estado completo do recurso.

Outro requisito para a sua aplicação RESTful é ser sem estado; O fato de que uma vez implantado em um ambiente de produção, é provável que os pedidos recebidos sejam atendidos por um balanceador de carga, garantindo escalabilidade e alta disponibilidade.

Uma vez exposto através de um balanceador de carga, a idéia de manter o estado do seu pedido no lado do servidor fica comprometida. Isso não significa que você não tem permissão para manter o estado da sua aplicação. Isso significa que você deve mantê-lo de uma maneira RESTful. Por exemplo, mantenha uma parte do estado dentro do URI.

A falta de estado na sua API RESTful isola o chamador contra mudanças no lado do servidor. Assim, o chamador não é esperado para se comunicar com o mesmo servidor em solicitações consecutivas e isso permite uma fácil aplicação de mudanças dentro da infraestrutura do servidor.

E estamos conversados...

(Disse Jesus) Todo o que o Pai me dá virá a mim; e o que vem a mim de maneira nenhuma o lançarei fora.
 João 6:37

Veja os Destaques e novidades do SUPER DVD Visual Basic (sempre atualizado) : clique e confira !

Quer migrar para o VB .NET ?

Quer aprender C# ??

Quer aprender os conceitos da Programação Orientada a objetos ?

Quer aprender o gerar relatórios com o ReportViewer no VS 2013 ?

Referências:

José Carlos Macoratti