REST. Representational State Transfer. É um estilo arquitetural usado por muitas aplicações Web para estender as suas funcionalidades.

Transcrição

1 REST Representational State Transfer É um estilo arquitetural usado por muitas aplicações Web para estender as suas funcionalidades. Não é um padrão.

2 Exemplo ASP.NET Web API namespace WebAPIApp.Models { public class Produto { public int Id { get; set; } public string Nome { get; set; } public string Descricao { get; set; } } }

3 ProdutosController namespace WebAPIApp.Controllers { public class ProdutosController : ApiController { private static List<Produto> produtos = new List<Produto>() { new Produto() {Id = 1, Nome = "Produto 1", Descricao = "Descrição do Produto 1" }, new Produto() {Id = 2, Nome = "Produto 2", Descricao = "Descrição do Produto 2" }, new Produto() {Id = 3, Nome = "Produto 3", Descricao = "Descrição do Produto 3" }, new Produto() {Id = 4, Nome = "Produto 4", Descricao = "Descrição do Produto 4" }, new Produto() {Id = 5, Nome = "Produto 5", Descricao = "Descrição do Produto 5" } };

4 ProdutosController // GET: api/produtos public IEnumerable<Produto> Get() { return produtos; } // GET: api/produto public Produto Get(int id) { Produto prod = produtos.find(p => p.id == id); if (prod == null) throw new HttpResponseException(HttpStatusCode.NotFound); else return prod; }

5 ProdutosController // POST: api/produtos public HttpResponseMessage Post([FromBody]Produto p) { if (p == null) return new HttpResponseMessage(HttpStatusCode.BadRequest); produtos.add(p); return new HttpResponseMessage(HttpStatusCode.Created); } // PUT: api/produtos/5 public HttpResponseMessage Put(int id, [FromBody]Produto p) { Produto prod = produtos.find(pr => pr.id == id); if (prod == null) throw new HttpResponseException(HttpStatusCode.NotFound); prod.id = id; prod.nome = p.nome; prod.descricao = p.descricao; return new HttpResponseMessage(HttpStatusCode.OK); }

6 ProdutosController // PUT: api/produtos/5 public HttpResponseMessage Patch(int id, [FromBody]Produto p) { Produto prod = produtos.find(pr => pr.id == id); if (prod == null) throw new HttpResponseException(HttpStatusCode.NotFound); prod.id = id; if (p.nome!= null) prod.nome = p.nome; if (p.descricao!= null) prod.descricao = p.descricao; return new HttpResponseMessage(HttpStatusCode.OK); }

7 ProdutosController } } // DELETE: api/produtos/5 public void Delete(int id) { Produto prod = produtos.find(pr => pr.id == id); if (prod == null) throw new HttpResponseException(HttpStatusCode.NotFound); produtos.remove(prod); }

8 Princípios REST 1. Uniform Interface 2. Stateless 3. Cacheable 4. Client-Server 5. Layered System 6. Code on Demand (opcional)

9 1. Uniform Interface Um Recurso é qualquer coisa que pretendemos expor, tal como um documento, um blog, etc. e que pretendemos gerir usando a API. Um Recurso tem um identificador, um URI, tal como um registo de uma base de dados tem uma chave primária. O URI é um identificador que podemos usar para aceder ao Recurso, não é a representação do recurso. Pedindo o Recurso com o URI obtemos uma representação num formato negociado entre o cliente e o servidor. O cliente pode manipular o estado do recurso usando o servidor. Exemplos: (URIs para acesso aos Recursos devem ser construídos de um modo uniforme) todos os clientes cliente 5 encomendas do cliente 3 encomenda 2 do cliente 3

10 2. Stateless O servidor nunca deve guardar informação acerca dos clientes. O estado para tratar o pedido está completamente contido no pedido. Outros sistemas mantêm o estado entre diferentes pedidos usando Sessões ou outros mecanismos, mas em REST o estado é mantido apenas no cliente.

11 3. Cacheable O cliente pode efetuar cache do Recurso. Assim como os browsers podem efetuar cache das respostas, os clientes também podem fazer cache das respostas. Cada resposta deve definir-se explicitamente como cacheable ou não.

12 4. Client-Server O que o cliente vê é o URI e a representação do recurso. O interface uniforme separa o cliente do servidor. Há separação de responsabilidades. O cliente não trata de armazenamento dos dados nem da geração do estado. O servidor não trata da interface com o utilizador nem de manter o estado. Desde que não se altere a interface uniforme entre cliente e servidor, o cliente ou o servidor podem ser substituídos em qualquer altura.

13 5. Layered System O Cliente não conhece as camadas do sistema. O cliente não sabe se está diretamente ligado ao servidor final. 6. Code on Demand opcional O servidor pode estender as funcionalidades do cliente passando-lhe código executável, tal como código JavaScript

14 Estes princípios constituem restrições arquiteturais Estes princípios focam na escalabilidade A própria Web é REST: temos um URL que é o identificador de uma página, um browser com o URL dá-nos a representação no formato HTML e usámos um link para transferir o estado para outra página. Em REST a operação num Recurso é baseada no Verbo HTTP usado em combinação com o URI. O browser gere os dois verbos: Get e Post.

15 Verbos HTTP e significado: Post cria um Recurso Create Get obtém um recurso ou lista de Recursos Read Put atualiza um Recurso Update Delete remove um Recurso Delete Head Options retorna o cabeçalho HTTP retribui as operações disponíveis no Recurso Patch atualiza apenas alguns atributos do Recurso Partial Update

16 Verbos HTTP e significado: Operação GET para ler um recurso A operação Get é usada para ler um Recurso ou Recursos. A operação Get é considerada segura, nunca deve modificar o estado de um recurso. Operação POST para criar um recurso A operação Post é usada para criar um Recurso. Os valores do Recurso são enviados para o servidor como parte do corpo do pedido. Operação PUT para atualizar um recurso A operação Put é usada para modificar um Recurso. O URI especifica o Recurso que pretendemos modificar e o body contém os novos valores do Recurso. Operação DELETE para remover um recurso A operação Delete é usada para apagar um Recurso. O URI especifica o Recurso.

17 HTTP status Um pedido é enviado ao servidor. O servidor constrói a resposta. Cada resposta é representada com um estado (http status) para informar o cliente. 5 códigos de estados http: 1xx Informação 2xx Sucesso 200 Ok, 201 Created 3xx Redireção 4xx Erro do cliente 403 Forbidden, 404 Not Found 5xx Erro do servidor

18 ASP.NET Web API ASP.NET Web API é um Framework para construir Serviços HTTP em cima do Framework.Net. Sistema de Routing na web API: api/{controller}/{id} Registado na classe WebApiConfig, no método Register. Em Mvc o routing é {controller}/{action}/{id} Em Mvc no routing temos a ação. Em Web API a ação não está presente. Em Web API a ação é determinada pelo Verbo do método HTTP: Post, Get, Put, Delete, etc.

19 Classes Controller As classes Controller herdam de ApiController (classe base usada para todos os recursos expostos via a API). Dentro da classe temos métodos para manipular o recurso de acordo com o Verbo do método HTTP invocado. O nome dos métodos é importante porque o runtime de ASP.NET Web API usa convenções para encontrar a ação a invocar para responder a pedidos HTTP.

20 Classes Controller O método Get() é usado para obter uma coleção de valores do recurso; O método Get(int id) é usado para obter um único valor do recurso dado o seu id; O método Post() é usado para inserir um valor do recurso; O método Put() é usado para modificar um valor do recurso; O método Delete(int id) é usado para apagar um valor do recurso;

21 Classes Controller A regra, por omissão, para os métodos num Controlador é que o nome do método de ação deve começar com o nome da ação: Pedido POST -> nome do método de ação deve começar por Post (ação Create) Pedido GET -> nome do método de ação deve começar por Get (ação Read) Pedido PUT -> nome do método de ação deve começar por Put (ação Update) Pedido DELETE -> nome do método de ação deve começar por Delete (ação Delete)

22 Postman programa utilitário para testar pedidos HTTP específicos Chrome > Mais Ferramentas > Extensões > Obter mais extensões: Postman REST Client shortcut > Instalar