Category Archives: NodeJS

Estilo REST { Arquitetural }

O Modelo Arquitetural : Step One

Entendendo os conceitos e as características sobre o estilo arquitetural REST. Vamos lá:

Modelo Arquitetural

REST (Transferência de Estado Representacional) é um estilo de arquitetura projetado para a concepção de sistemas distribuídos, permitindo a comunicação entre serviços distribuídos entre plataformas e tecnologias diferentes.

Em resumo, o REST é um padrão de projeto de software a ser seguido na criação de uma webapp. Desenhado para permitir que programas/plataformas consigam conversar/trocar informações na web.

Roy Fielding

Proposto por Roy Fielding, um dos autores da especificação do protocolo HTTP e definiu o termo REST em 2000 (na sua dissertação de doutorado).

rest_intro_roy

O REST é baseado nos conceitos de Recursos e utilização de requisições HTTP. Hoje é a principal arquitetura utilizada com WebServices.

Leveza e Simplicidade

Apresentado como uma alternativa para a troca de dados.

O REST chega como uma opção mais LEVE e SIMPLES quando comparada ao SOAP. Embora o SOAP ainda seja bastante utilizado, o REST vem aumentando novos adeptos a cada dia.

Implementações HTTP

Atualmente possui implementações apenas relacionada ao HTTP, porém, ele não está restrito apenas ao HTTP.

Implementações Existentes

Grandes players como Node.js, .NET, Java e Ruby, já possuem as suas implementações REST. Isso mostra o poder do REST.

No universo .NET por exemplo, podemos construir serviços HTTP baseados em REST com WCF e o Asp.Net Web API Framework.

ASP.NET Web API por exemplo, é um framework para a construção de web APIs NET(Serviços HTTP) em cima da plataforma .NET, permitindo com isso que uma aplicação possa ser acessada por vários clientes em muitas plataformas.

Os 3 pilares

RESTfull Web Services, serviços que seguem esta arquitetura.

O REST é baseado em 3 pilares:

rest_intro

Na representação esquemática do modelo REST temos:  Resources, URI e Representação.

Resources

O REST se contrapõe a arquitetura SOAP.

Diferente do SOAP que é baseado em Ações, o REST é baseado em Recursos, um elemento (conjunto de dados) do qual uma aplicação depende, representando normalmente um item do negócio.

Resources pode ser qualquer coisa que tenha um URI, sendo um mapeamento conceitual para uma ou mais unidades.

Um recurso pode ser um Serviço que interage com qualquer coisa:

  • Catalog Web
  • ECommerce ou Sistema interno (tipo CRM)
  • Dispositivo (tipo Impressora)
  • etc…

URI

Quando realizamos requisições Web, precisamos dizer o caminho da mesma, o URI (Unified Resource Identifier) um identificador único de um recurso.

Representação

A representação é um estado instantâneo de um recurso em um ponto no tempo.

Sempre que um cliente HTTP for requisitar um resource, a sua representação será  retornada, e NÃO o próprio recurso.

{
"nome": "Aldo",
"email": "wa@gmail.com"
}

É isso mesmo! utilize JSON ou XML para representar os dados associados a um recurso.

A representação do resource será retornado para o cliente como HTML, XML, JSON, TXT, etc…

As Regras do Jogo

O REST NÃO É uma tecnologia ou padrão, mas, sim um conjunto de restrições e regras proposto por Roy Fielding como:

  • Stateless (sem estado), não deve haver monitoração de estado *
  • Cliente Servidor deve possuir um relacionamento modelo cliente/servidor
  • Cache
  • Interface Uniforme
  • Layered System dividido em Camadas
  • Código sob demanda (opcional)

(*) As Interações sem estado não armazenam nenhum contexto de cliente no servidor entre as requisições. O cliente mantém o estado da sessão.

Estilo REST / StatusCode

Restful : Http Status Code

Continuando a saga Web Services RESTfull. Entenda o conceito de Http Status Code, essencial para o desenvolvimento de serviços que seguem este tipo de Arquitetura.

rest_esquematica

HTTP StatusCode

Durante a conversação RESTFul, toda request HTTP irá receber um código de resposta, ou seja, receberemos um status sinalizando o resultado da solicitação HTTP.

Os Status Code comuns

  • 1XX   Informativo
  • 2XX   Sucesso
  • 3XX   Redirecionamento
  • 4XX   Erro do cliente
  • 5XX   Erro do Servidor

Note que para cada código há um significado específico.

  • 200 OK – Request bem sucedida
  • 404 Not Found – Server não localizou nenhuma URI correspondente
  • 500 Internal Server Error – Server não concluiu a request devido a um erro inesperado

Mais exemplos

Aqui um status code 200 informando que tudo ocorreu bem.

rest_statuscode

201

Indo para o lado mais prático do StatusCode.

Aqui se o POST for OK, o server responderá um StatusCode HTTP 201 (Criado).

rest_statuscode_api

A localização do objeto recém-criado será retornada como Uri no header de local da resposta. Executando o Uri de localização, as informações dos objetos podem ser solicitadas.