Web Services RESTful

Web Services RESTful
Introdução e Conceitos
Por Douglas V. Pasqua
http://douglaspasqua.com

Pasqua Tecnologia - http://douglaspasqua.com 2
Palestrante
● Douglas Pasqua
– Desenvolvedor PHP / Java
– Especialista Linux
– Desde 2002
– LPIC-1, LPIC-2, PHP ZCE, Java
SCJP
– Instrutor e Palestrante
– http://douglaspasqua.com

O que é REST ?
● REpresentational State Transfer (Transferência de
Estado Representacional)
● É um estilo arquitetural para criação de aplicações
distribuídas
● Termo criado por Roy Fielding no ano de 2000 em
uma tese de Doutorado - “Architectural Styles and the
Design of Network-based Software Architectures”
● É totalmente independente do HTTP e da Web
● Sua utilização mais comum são APIs usando HTTP

Restrições do REST
1)Client-server
2)Stateless
3)Cache
4)Uniforme Interface
5)Layered System
6)Code-On-Demand (opcional)

1. Client-Server
● Objetivo é separar as duas arquiteturas
● Desenvolvimento dos dois são independentes
● Cliente não se preocupa com DB, log, cache, etc.
● Servidor não se preocupa com UX, etc.

2.Stateless
● Requisições devem ser
independentes
● O servidor não deve guardar
estado do cliente
● O estado deve ser gerenciado no
lado do cliente (sessions)
● Facilita design da arquitetura
● Facilita escalabilidade
● Facilita
monitoração/depuração

3.Cache
● Informar ao cliente se
os dados de uma
requisição podem ou
não ser guardados
em cache
● Melhorar:
● Escalabilidade
● Performance

4.Uniforme Interface
● Define interface entre
o cliente e servidor
● Simplifica e
desacopla a
arquitetura
● Permitindo as duas
partes evoluir
independentemente
1) Baseado em
Recursos
2) Representação do
Recurso
3)Mensagens auto
descritivas
4)Hypermedia

4.1. Baseado em Recursos
● Recursos individuais devem ser identificados
em requisições usando URIs específicas e
coesas.
http://api.example.net/cantor/michaeljackson
http://api.example.net/album/thisisit

4.2. Representação
● Define a foram como o recurso deve ser
retornado para o cliente
● JSON
● XML
● TXT
● HTML
● ...

4.3. Mensagens Auto descritivas
● Cada representação deve conter a informação
de como ela deve ser processada.
● Mime-types
● application/json
● application/xml
● text/plain

4.4. Hypermedia
● A representação deve fornecer “links” (body ou
headers) que permitem obter o próprio recurso
ou relacionados.

5. Layered System
● Sugere que o cliente não deve conectar diretamente
ao servidor, mas sim em um intermediador.
● Facilita escalabilidade, load-balacing, caches
compartilhados, etc.

6. Code on Demand
● Permite executar lógica no cliente, estendendo
e customizando o código do servidor
– Java applets
– Java script
– Etc.
● Restrição Opcional

Termo RESTful
● Termo RESTFul é usado para referenciar web
services que implementam a arquitetura REST
● Caso o serviço violar qualquer restrição não
pode ser considerado RESTful

Pontos Fortes
● Simplicidade
● Formatos de representação (JSON, XML, TXT,
etc.)
● JSON é enxuto, ideal para o mundo mobile
● Escalabilidade
● Cache

Usando Métodos HTTP para Serviços
RESTFul

Verbos HTTP Operação CRUD
GET Ler
POST Criar
PUT Substituir
PATCH Modificar
DELETE Excluir
Operações CRUD com HTTP

GET
● Deve ser usado somente para leitura (read).
● Idempotente
● Operação considerada “segura"

GET
➔ Itens Específicos
➔ GET http://api.example.net/singer/{id}
➔ GET http://api.example.net/singer/michaeljackson
➔ Coleções
➔ GET http://api.exampl.net/singers

GET - Representações
{
"name":"Michael Jackson",
"birthday":"1958-08-29",
"site":"michaeljackson.com",
"genres":[
"pop",
"rock",
"dance-pop"
]
}
<?xml version="1.0" encoding="UTF-8"?>
<singer>
<birthday>1958-08-29</birthday>
<genres>
<element>pop</element>
<element>rock</element>
<element>dance-pop</element>
</genres>
<name>Michael Jackson</name>
<site>michaeljackson.com</site>
</singer>

GET - Status Code
• 200 (OK)
• 404 (Not Found)

POST
● Usado para criação de novos recursos
● Deve retornar header “Location” com o link
para o novo recurso
● Não é uma operação “segura”
● Não é idempotente

POST - Exemplo
● POST http://api.example.net/singer
{
"birthday":"1958-08-29",
"genres":[
"pop",
"rock",
"dance-pop"
]
}

POST - Exemplo (subordinado)
● POST http://api.example.net/singer/michaeljackson/music
{
"name":"Billie Jean",
"album":"Thriller",
"lancamento":"1982",
"letra":"Billie Jean is not my lover...",
"indicacoes":"Grammy Award, Cancao do Ano, etc."
}

POST - Status Code
● 201 Created (retornar Location)
● 400 Bad Request / 406 Not Acceptable
● 409 Conflict (registro duplicado)

PUT
● Recomendado para realização de atualizações
(updates)
● Permite-se usar PUT para criação de novos
recursos quando informado o ID pelo cliente
● É idempotente

PUT - UPDATE
● PUT http://api.example.net/singer/michaeljackson
{
"birthday":"1958-08-28",
"genres":[
"pop",
"rock",
"dance-pop"
]
}
Deve-se informar uma
nova representação do
recurso

PUT – Novo Recurso
● PUT http://api.example.net/singer/elvispresley
{
"name":"Elvis Presley",
"birthday":"1935-01-08",
"site":"www.elvis.com",
"genres":[
"pop",
"rock",
"blues"
]
}
Pode-se usar para
criar novos recursos
quando cliente informa
o ID

PUT – Status Code
● 200 OK / 204 No Content
● 404 Not Found

PATCH
● Usado para modificação
● Contém apenas as mudanças e não a
representação completa do recurso
● Não é idempotente

PATCH – Exemplo 1
● PATCH http://api.example.net/singer/michaeljackson
{
"birthday":"1958-08-29"
}
idempotente

PATCH – Exemplo 2
{
"change":"birthday",
"from":"1958-08-28",
"from":"1958-08-29"
}
idempotente

PATCH – Exemplo 3
{
"add":"genres",
"value":"blues"
}
idempotente

PATCH – Status Code
● 200 OK / 204 No Content
● 404 Not Found

DELETE
● Usado para deletar um recurso
● É idempotente

DELETE - Exemplos
● DELETE http://api.example.net/singer/michaeljackson
● DELETE http://api.example.net/singer/elvispresley

DELETE – Status Code
● 204 No Content
● 404 Not Found

Richardson Maturity Model

Richardson Maturity Model
● É uma maneira de graduar sua API de acordo
com as restrições do REST
● Quanto mais sua API aderir as restrições mais
pontuação ganha
● Desenvolvido por Leonard Richardson e
apresentando pela primeira vez na Qcon 2008

Protegendo APIs REST

Segurança em APIs REST
● A solução não deve manter estado no lado do
servidor (Restrição Stateless)
● Não utilizar Sessions

Segurança em APIs REST
● Abordagens mais usadas
– Basic
– Digest
– OAuth
– JWT (Json Web Token)

Pontos a Considerar
● Cache
● Versionamento
● Limitar taxa de acesso
● Tratamento de erros
● Documentação
● Ferramentas de Apoio / Frameworks

Cache
● Ideal quando o servidor tiver que lidar com
grande volume de dados
● Usar em Operações GET
● Servidor deve usar Etag(hash) ou Last-
Modified para indicar que cache é possível
● O Cliente deve gerenciar os dados no cache
localmente

Versionamento
● Via URL
GET http://api.example.net/v2/singer/michaeljackson
● Custom Request Header
GET http://api.example.net/singer/michaeljackson
Api-version: 2

Versionamento
● Content type
GET http://api.example.net/singer/michaeljackson
Accept: application/vnd.api.example+json;version=2

Limitar taxa de acesso
● Quantidade de requisições X Tempo
● Limite de acordo com perfil do usuário
– Usuários não logados vs Usuários logados
– Apps pagos
– Perfis de acesso
● Gerenciar carga do servidor

Tratamento de Erros
● Regra -> responda sempre no formato que o
cliente esteja esperando. (Retornar HTML enquanto
estiver esperando JSON ???)
● Mensagens de erro significativas
– Permissão negada ?
– Dados de entrada faltantes/inválidos
– Função inexistente
– Enviar sugestões para o usuário em caso de erro

Documentação
● Boa API => Boa Documentação
● Use Ferramentas para automatizar o processo
– swagger (https://swagger.io)

Ferramentas de Apoio / Frameworks
● Apigility (https://apigility,org) - PHP
● swagger (https://swagger.io)
● Jersey (https://jersey,github.io) – Java
● Amazon API Gateway
● sensedia API Platform (https://sensedia.com)

Referências
● http://restcookbook.com/
● http://martinfowler.com/articles/richardsonMatur
ityModel.html
● http://www.douglaspasqua.com/category/rest/
https://www.ics.uci.edu/~fielding/pubs/dissertat
ion/rest_arch_style.htm
● http://www.restapitutorial.com/httpstatuscodes.h
tml

Web Services RESTful

Mais conteúdo relacionado

Semelhante a Web Services RESTful

Mais de Douglas V. Pasqua

Web Services RESTful