API

Application programming interface

Interface de programação de aplicações

 API

Linguagens de
Framework
programação

Sistemas
Dispositivos
operacionais
 API

Linguagens de
Framework
programação

Sistemas
Dispositivos
operacionais
APIs HTTP
Cliente
get /treinaweb/cursos
API HTTP

200 OK
Content-Type: application/json
{[curso1, curso2, cursoN]}
 post /treinaweb/cursos
Content-Type: application/json
{
“nome”: “PHP”,
“carga”: 10
Cliente }

API HTTP

200 OK
Content-Type: application/json
{
“id”: 1234
“nome”: “PHP”,
“carga”: 10
}
 REST
REpresentational State Transfer

Transferência de Estado Representacional

Roy Fielding
 Características do REST
● Stateless
● Modelo cliente servidor
● Transparente a tecnologia, linguagem e framework
● Cacheavel
● Independente do formato de transmissão de dados
 O que utilizamos no REST

● Recursos
● Métodos HTTP
● Códigos de status
● hypermedia
 Princípios REST

● Dividir a aplicação em recursos

● Definir as ações usando os métodos HTTP
● Retornar adequadamente os status code nas respostas
● Usar Hypermedia para guiar os clientes
● Permitir que nossas APIs sejam cacheaveis
 REST
X
RESTful
Como estruturamos nossas APIs
com REST
 Recursos

São elementos do mundo real abstraídos na

aplicação

Sempre usamos substantivos para representar e

nunca verbos
 Exemplos de Recursos
http://meusistema.com.br/api/ cursos

http://meusistema.com.br/api/ clientes

http://meusistema.com.br/api/ funcionarios

http://meusistema.com.br/api/ produtos
 Métodos HTTP
Obter dados http://meusistema.com.br/api/cursos GET

Criar novo http://meusistema.com.br/api/cursos POST

Atualização
http://meusistema.com.br/api/cursos PUT
total
Atualização
http://meusistema.com.br/api/cursos PATCH
parcial

Exclusão http://meusistema.com.br/api/cursos DELETE

 Status Code HTTP
100 - 199 Respostas de informações

200 - 299 Respostas de sucesso

300 - 399 Redirecionamento

400 - 499 Respostas de erro do cliente

500 - 599 Respostas de erro do servidor

 Status Code HTTP

200 401 405

201 402 422

301 403 500

302 404 504

Modelo de maturidade de
Richardson
 Níveis de maturidade

Level 3 Utiliza HATEOAS

Level 2 Usa métodos e status codes HTTP

Level 1 Organiza em recursos

Não utiliza recursos, métodos, status

Level 0
code e HATEOAS
 Nível 0
Obter dados /obterCursos GET 200

Criar novo /salvarCurso POST 200

Atualização
/atualizarCurso POST 200
total
Atualização
/atualizarParcialCurso POST 200
parcial

Exclusão /excluirCurso POST 200

 Nível 1
Obter dados /cursos/obter GET 200

Criar novo /cursos/salvar POST 200

Atualização
/cursos/atualizar POST 200
total
Atualização
/cursos/atualizar/parcial POST 200
parcial

Exclusão /cursos/excluir POST 200

 Nível 2
Obter dados /cursos GET 200

Criar novo /cursos POST 201

Atualização
/cursos PUT 200
total
Atualização
/cursos PATCH 200
parcial

Exclusão /cursos DELETE 200

Nível 3
Diferenças entre autenticação e autorização

Autenticação Autorização
Diz quem você é Diz o que você pode fazer
Diferenças entre autenticação e autorização
 Autenticação e autorização para APIs
● Autenticação básica HTTP
● Chave de API
● OAuth
● Tokens JWT
Operações além do CRUD
 Tratar relacionamentos
Obter aulas
/cursos/1/aulas GET 200
do curso

Criar aula no
/cursos/1/aulas POST 201
curso

Atualizar uma
/cursos/1/aulas/1 PATCH 200
aula no curso

Excluir uma
aula no curso
/cursos/1/aulas/1 DELETE 200

Excluir todas
aulas no curso
/cursos/1/aulas DELETE 200
 Tratando como atributo

Estado do
/cursos/1/ativo PATCH 200
curso

Aprovação
/cursos/1/aprovado PATCH 200
do curso
 Tratando como recurso
Definir Detalhes
de um curso
/cursos/1/detalhes PATCH 200

Obter Detalhes
de um curso
/cursos/1/detalhes GET 200

Definir Endereço
de um cliente /clientes/1/enderecos PATCH 200

Obter Endereço
de um cliente /clientes/1/enderecos GET 200
Autenticação e autorização em
APIs
 Dicas de segurança
● Sempre utilize HTTPS
● Não passe dados de segurança via URL
● Utilize Rate Limit
● Sempre validar todos os dados recebidos
● Utilizar um API Gateway