CONSTRUINDO APLICAÇÕES RESTful

Arquitetura REST, RMM e HATEOAS

por Ricardo Plansky

QUEM SOU EU

Ricardo Plansky - Analista Desenvolvedor @ Leroy Merlin Brasil

- Formado em Análise e Desenvolvimento de Sistemas

- 09 anos de experiência com programação

- 07 anos com PHP OO

- Áreas: Marketing Digital, Business Intelligence, Telecom e, agora, e-commerce varejista.

AGENDA

- O que é REST

- Como funciona este modelo

- Quais são as restrições

- O que é RESTful 

- Richardson Maturity Model

- Níveis do RMM 

- HATEOAS

- JSON SCHEMA

- CONSIDERAÇÕES FINAIS

O QUE É REST

Modelo de Arquitetura criado por Roy Fielding em meados de 2000 em sua tese de Doutorado

COMO FUNCIONA ESTE MODELO

Conjunto de regras de arquitetura para aplicações web

REGRAS

1) Client-Server

REGRAS

1) Client-Server

• Evolução independente dos ambientes
• Separação de responsabilidades
• Recursos divididos

REGRAS

2) Stateless

REGRAS

2) Stateless

• Toda requisição deve ser independente
• Os servidores não devem guardar estados dos seus clients
• O client deve mandar toda informação necessária para o servidor entender e processar a requisição

REGRAS

3) Cacheable

REGRAS

3) Cacheable

• Evitar processamento desnecessário
• Ganho de performance
• Tempo de resposta para os clients
• Menor uso de recursos do servidor

REGRAS

4) Uniform Interface

REGRAS

4) Uniform Interface

• Contrato de comunicação entre cliente e servidor
• Coesão em endpoints e respostas
• Estrutura clara de organização
• RMM
• HATEOAS

REGRAS

5) Layered System

REGRAS

5) Layered System

• Clientes não se comunicam diretamente com servidores
• Camada de abstração
• Load Balancer
• Escalabilidade

REGRAS

6) Code-on-Demand

REGRAS

6) Code-on-Demand

(opcional)

• Execução de código do lado do cliente
• Necessidades variantes de acordo com o cliente
• JavaScript, Applets, Flash, etc.

O QUE É RESTful

1) Seguir estritamente as regras do modelo de arquitetura REST (com exceção da 6 que é opcional)

2) Possuir um certo nível de coesão e maturidade

RICHARDSON MATURITY MODEL

• Um modelo simples que define o nível de 'maturidade' RESTful da sua app.
• Possui 3 níveis (mais o nível zero)
• Aplicado basicamente na quarta regra do REST (Uniform Interface)

RMM - Nível 0

É a ausência de qualquer regra.

• Basicamente usar o HTTP como transporte de informações
• Possui apenas um endpoint e um verbo HTTP
• Comum em SOAP

RMM - Nível 0 - Exemplo

POST http://api.meetuplaravelsp.com/call

{
    "action": "createUser",
    "parameters": {
        "username": "rplansky",
        "password": "letmein",
        "hobbies": ["football", "drawing", "skating"]
    }
}

{
    "action": "deleteUser",
    "parameters": {
        "username": "rplansky"
    }
}

{
    "action": "removeHobbie",
    "parameters": {
        "username": "rplansky",
        "hobbie": "football"
    }
}

RMM - Nível 0 - Exemplo

<?php

class MagicController
{
    public function call($action, array $parameters = array())
    {
        switch ($action) {
            case 'createUser':  
                // Some code
                break;    
            case 'deleteUser':  
                // Some code
                break;    
            case 'removeHobbie':  
                // Some code
                break;
            ...
        }   
    }
}

RMM - Nível 1

Aplicação de resources

• São criadas diversos endpoints para representar os resources
• Melhor estruturação

RMM - Nível 1 - Exemplo

POST http://api.meetuplaravelsp.com/user/create

{
    "username": "rplansky",
    "password": "letmein",
    "hobbies": ["football", "drawing", "skating"]
}

POST http://api.meetuplaravelsp.com/user/delete

{
    "username": "rplansky"
}

RMM - Nível 1 - Exemplo

POST http://api.meetuplaravelsp.com/user/rplansky/hobbie/remove

{
    "hobbie": "football"
}

RMM - Nível 1 - Exemplo

class UserController 
{
    public function create($parameters)
    {
        // Some code
    }

    public function delete($username)
    {
        // Some code
    }
}

class HobbieController
{
    public function remove($username, $hobbie)
    {
        // Some code
    }
}

RMM - Nível 2

Aplicação de verbos HTTP

• Além dos endpoints criados no nível 1, agora há coesão entre verbos e ações executadas

RMM - Nível 2 - Exemplo

POST http://api.meetuplaravelsp.com/user

{
    "username": "rplansky",
    "password": "letmein",
    "hobbies": ["football", "drawing", "skating"]
}

DELETE http://api.meetuplaravelsp.com/user/rplansky

{
}

DELETE http://api.meetuplaravelsp.com/user/rplansky/hobbie/football

{
}

RMM - Nível 3

HATEOAS

Hypermedia As The Engine Of Application State

HATEOAS

É prover uma maneira do cliente interagir com o serviço inteiramente por hipermídia.

Deixar claro como é feita a comunicação com os seus recursos e fornecer as informações necessárias para isso

HATEOAS

GET http://api.meetuplaravelsp.com/

HATEOAS

POST http://api.meetuplaravelsp.com/user

POST HTTP/1.1 201 Created
content-type:application/json; charset=UTF-8
date:Wed, 01 Apr 2015 18:06:36 GMT
status:201 Created
version:HTTP/1.1
Location: http://api.meetuplaravelsp.com/user/rplansky

HATEOAS

POST http://api.meetuplaravelsp.com/user

HATEOAS

POST http://api.meetuplaravelsp.com/user/rplansky/hobbie

HATEOAS

GET http://api.meetuplaravelsp.com/user/page/2

NÍVEL HARD

http://www.json-schema.org

JSON SCHEMA

{
    "title": "Example Schema",
    "type": "object",
    "properties": {
    	"firstName": {
	    "type": "string"
	},
	"lastName": {
	    "type": "string"
	},
	"age": {
	    "description": "Age in years",
	    "type": "integer",
            "minimum": 0
	}
    },
    "required": ["firstName", "lastName"]
}

CONSIDERAÇÕES

• Utilizem o HEADER das requisições.
• Status Code de resposta
• Analise as respostas dos seus serviços. É coeso? Tem todas as informações necessárias para interação?

OBRIGADO!

PERGUNTAS?

CONTATO

Facebook

Twitter

GitHub

Google+

LinkedIn

www.rplansky.com

ricardo.plansky@yahoo.com