O documento discute APIs, sistemas de integração e suas aplicações em negócios. Aborda tópicos como a diferença entre APIs, bibliotecas e frameworks, como APIs funcionam, requisições HTTP, formatos como SOAP, REST, XML e JSON, segurança e autenticação, criação e consumo de APIs. Também discute opções para sites e aplicativos móveis, além de justificar a exposição de dados via APIs.

1. O MUNDO DAS APIs
Otimizando a integração de Sistemas
HEIDER LOPES
WORKSHOP DO BEM

2. NEGÓCIOS
● QUAL É A DIFERENÇA ENTRE API, BIBLIOTECAS
E FRAMEWORK?
● COMO E ONDE FUNCIONAM?
● QUAIS SÃO AS REGRAS?
● REQUISIÇÕES E CÓDIGOS HTTP
● SOA? RESTFUL? XML? JSON?
● SEGURANÇA E AUTENTICAÇÃO
● VERSIONAMENTO E DOCUMENTAÇÃO
● CRIANDO UMA API E CONSUMINDO SEUS
DADOS
MÓDULO 1
TÓPICOS
ABORDADOS
O MUNDO DAS
APIs

3. HEIDER LOPES
Professor de MBA E Graduação na FIAP

4. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
NOSSO ESTUDO DE CASO

5. QUEM NUNCA PENSOU?

6. QUAIS SÃO AS OPÇÕES?

7. SITE RESPONSIVO
● Possui seu layout para adaptar ao formato da tela que
está sendo visualizado
● O formato se expande e aproveita a tela
● Podem mudar as posições porém preserva o tamanho da
informação.

8. SITE RESPONSIVO

9. SITE MOBILE (WEB APP)
● Similar ao responsivo, normalmente, é mais utilizado para
apresentar informações em formato de lista, para facilitar a
navegação.
● Essa técnica permite ir ainda mais longe na usabilidade
para dispositivos móveis.
● Gera um custo duplicado.

10. WEB APP

11. APP NATIVO
Pode atingir um desempenho muito melhor
Capacidade para utilizar os recursos do dispositivo.
Experiência do usuário é muito superior.
Grandes empresas costumam ter as duas soluções, pois há
usuários resistentes a baixar um aplicativo.
Precisa lidar com as diferenças entre sistemas operacionais.

12. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
COMO ESCOLHER ENTRE APP OU SITE?

13. ESCOLHENDO UM APP

14. ESCOLHENDO UM SITE

15. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
O QUE ISSO TUDO TEM A VER COM NOSSO
TEMA?

16. JUSTIFICATIVA

17. JUSTIFICATIVA
Hoje em dia, é praticamente obrigatório às empresas
oferecerem um website e um aplicativo para dispositivos
móveis com o objetivo de estarem conectadas a seus
clientes.
A expectativa é que o mesmo aconteça com os wearables e a
Internet das Coisas.
Essas novas tecnologias exigem que as empresas
proporcionem mobilidade aos clientes por múltiplas
plataformas.

18. JUSTIFICATIVA
Backend: seria toda a estrutura interna: pilares, armação,
vigas, tubulação de gás e hidráulica, fiação elétrica, etc.
Frontend: seria toda parte visível: acabamento, pisos, pia,
gesso e outros.
APIs: seriam as
tomadas, torneiras,
mangueira do gás e
tudo que permite
instalar ou remover
algo com facilidade.

19. JUSTIFICATIVA

20. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
API? Frameworks? Bibliotecas?

21. APIs? Frameworks? Bibliotecas?

22. Libraries (Bibliotecas)
É um conjunto de subprogramas ou funções, geralmente
organizadas em classes, que podem ser usadas para a
construção de um software ou aplicativo mobile.
Geralmente tornam a utilização de uma linguagem de
programação mais fácil.

23. Frameworks
É uma base sólida e padronizada para a construção de uma
aplicação. Um framework pode ser construído utilizando-se
diversas bibliotecas e integrado a APIs de forma a oferecer
uma estrutura ideal para o desenvolvimento de um aplicativo
mobile, por exemplo.
Utilizando um framework, o desenvolvedor pode se
concentrar em desenvolver as funcionalidades do seu app,
sem se preocupar com tarefas repetitivas e até mesmo com a
construção de componentes de tela, os quais já foram
construídos previamente e já vem prontos para uso.

24. SDKs (Software Development Kits)
Podem assumir a forma de toolkits ou de frameworks e
fornecem tudo o que precisa para programar em cima de uma
plataforma (sistema operacional, banco de dados, aplicação,
etc.).
Estes kits costumam englobar ferramentas adicionais além
das bibliotecas além de documentação e exemplos de
códigos que ajudam a usar a biblioteca adequadamente.

25. API (Application Programming Interface)
Interface de Programação de Aplicações
Criado para oferecer uma interface (caminho) com regras
bem definidas para integração entre sistemas, a fim de obter
informações e, assim, trabalhar com elas.
Na construção de um aplicativo é possível utilizar diversas
APIs com o objetivo de agregar funcionalidades
interessantes.
Para escalar seu negócio, pode investir na construção de
uma API para que seus clientes executem tarefas diretamente
na sua plataforma, sem a sua intervenção. Conhecido como
Economia das APIs.

26. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
Por que expor os dados?

27. Alguns motivos
● Integrar sua plataforma à parceiros
○ E-commerces
○ SaaS
○ Entre outros
● Gerar mais mercado
● Expandir o público-alvo
● Organização do setor de TI, em que os consumidores das
APIs são as outras equipes internas da empresa, e as
APIs expostas funcionam como portais de troca de dados
entre setores.

28. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
Como as APIs funcionam?

29. Como API funciona?

30. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
Requisições

31. Requisições
São os pedidos feitos pelo cliente à API.
Para que uma requisição seja válida, ela deve ter um formato
específico.
O protocolo usado nas requisições é o HTTP (HyperText
Transfer Protocol).
Quando você acessa um site que tem “http://” no começo,
você está dizendo ao seu navegador para usar esse protocolo
ao carregar o site.

32. Requisições
A requisição deve ser composta por 4 partes:
● URL (Uniform Resource Locator)
● Método
● Header
● Body

33. URL
É o endereço que deve ser acessado.
Você sempre tem endereço que navega pelos diferentes
recursos que estão sendo expostos. Por exemplo:
https://alodjinha.herokuapp.com/
Esse endereço é conhecido como o endpoint em que os
recursos estarão disponíveis.
Para visualizarmos os produtos, podemos acessar o seguinte
recurso:
https://alodjinha.herokuapp.com/produto

34. Método
Esse é o verbo que você usará para interagir com o recurso.
Normalmente, temos 4 opções para interagir:
GET: que pede ao servidor o recurso;
POST: que pede ao servidor que crie um recurso novo;
DELETE: que pede ao servidor que apague um recurso;
PUT: que pede ao servidor a atualização ou edição de um
recurso.

35. Header
O Header contém uma lista de detalhes sobre como o cliente
quer que a mensagem seja interpretada. Os diferentes
servidores ou APIs podem aceitar diferentes headers.
Através de uma informação específica no header, o servidor
recebe a informação e pode retornar a versão mobile (tanto
do site como dados)

36. Body
Aqui vão todos os parâmetros que tornam cada requisição
diferente entre si, são os detalhes.
O produto que você quer comprar pode ser playstation4,
televisão, camiseta ou qualquer outro.
Ao invés de criar um recurso chamado /playstation4 e outro
/televisao e assim por diante, existe apenas o /produto e
cada tipo diferente é determinado pelas informações
detalhadas que vão no Body.
Esse é um exemplo que facilita na criação de recursos.

37. Response (Resposta)
Na realidade, a resposta tem uma anatomia bem definida,
parecida com a requisição. Ela é composta por três partes:
Código HTTP;
Header;
Body.
O Header e o Body tem os mesmos princípios dos usados
para as requisições. Um dá certas diretrizes para analisar a
mensagem e o outro dá detalhes.
É importante notar que cada API pode usar suas próprias
regras para definir as informações que serão dadas ao cliente
na resposta.

38. Códigos HTTP
Os códigos seguem uma padronização simples para serem
definidos:
1xx: Informações gerais;
2xx: Successo na requisição e na resposta;
3xx: Redirecionamento para outra URL;
4xx: Erro (por parte do cliente);
5xx: Erro (por parte do servidor).
Portanto, o erro 404 se trata de uma requisição inválida, já
que o cliente está pedindo ao servidor algo que não existe.
Outro código famoso é o 200 OK, que é retornado sempre
que a requisição foi entendida e retornada com sucesso.

39. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
SOAP, Rest, JSON, XML

40. SOAP (Simple Object Access Protocol)
É um protocolo de comunicação entre aplicações, baseado em
XML para uso em ambientes distribuídos, independente de
plataforma. Contém os seguintes elementos:
Envelope: que identifica o document XML como sendo uma
mensagem SOAP
Header (opcional) que contém a informação específicas do
aplicativo, por exemplo, dados de autenticação, pagamento, etc
Body, que é o conteúdo da mensagem e que contém as
informações de chamada e resposta
Fault (opcional), que é utilizado para apresentar mensagens de
erro.

41. REST (REpresentational State Transfer)
REST pode usar quatro diferentes verbos HTTP 1.1 (GET,
POST, PUT e DELETE) para executar as tarefas.
Não tem que obrigatoriamente usar XML para fornecer a
resposta. Os dados de saída podem ser:
Command Separated Value (CSV)
JavaScript Object Notation (JSON)
Really Simple Syndication (RSS)
O REST permite que seja utilizada o formato de saída mais
adequado para a linguagem ou aplicação que está sendo
trabalhado.

42. XML (eXtensible Markup Language)
Foi projetado para armazenar e transportar informações
sendo possível de ser compreendido por pessoas e também
por máquinas. O XML permite armazenar as informações de
modo organizado e estruturado.
Um documento XML é estruturado em formato de árvore,
possui sempre um elemento raiz em que os elementos
seguintes se ramificam e também permite que novos
elementos sejam ramificados a partir destes.
Uma utilização bem conhecida do XML é com os dados da
nota fiscal eletrônica.

43. JSON (JavaScript Object Notation)
É uma sintaxe para armazenamento e troca de informações,
mais fácil de utilizar e uma alternativa mais leve do que o
XML.
O formato do JSON é sintaticamente idêntico ao código para
criação de objetos JavaScript, por isso os dados JSON
podem ser convertidos nativamente pelo JavaScript.

44. XML VS JSON
JSON
{
“produto”: {
“nome”: “PlayStation 4”,
“preco”: 1499.00
}
}
XML
<produto>
<nome>PlayStation 4</nome>
<preco>1499.00</preco>
</produto >

45. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
Autenticação/Autorização

46. De quanto sua segurança precisa?
Sua API é pública ou privada?
Quão sensíveis são os dados?
Uma brecha no seu sistema abre acesso para outros
sistemas internos?

47. Mecanismos de segurança comuns?
● Restrição de acesso pela infraestrutura de rede
● Comunicações HTTPS
● Autenticação/Autorização HTTP basic
● Autenticação/Autorização HTTP Digest
● Autenticação/Autorização através de Certificados
● Token-based authorization
● OAuth

48. Autenticação/Autorização HTTP Basic

49. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
Como criar uma API?

50. Pontos chaves
● Usar padrões web (web standards) quando fizer sentido
● Ser amigável ao desenvolvedor e explorável através da barra de
endereços do navegador
● Ser simples, intuitiva e consistente, a fim de a adoção ser não
somente fácil, mas agradável
● Ser eficiente, ao mesmo tempo que mantém o balanceamento com
outros requerimentos
● O nome do endpoint deve ser no plural
● Respostas em JSON

51. Como deve ser feito um recurso
● Recursos devem ser substantivos (não verbos!) que fazem sentido
do ponto de vista do quem vai “consumir” a API
● Depois da definição dos recursos, é necessário identificar quais
ações se aplicam a eles e como serão mapeados para a API.
● Princípios RESTful fornecem estratégias para lidar com ações
CRUD usando métodos HTTP mapeados, tal como:
○ GET → /clientes → Retorna a lista de clientes
○ GET → /clientes/7 → Retorna um clientes específico
○ POST → /clientes → Cria um novo clientes
○ PUT → /clientes/7 → Atualiza o clientes #7
○ PATCH → /clientes/7 → Atualiza parcialmente o clientes #7
○ DELETE → /clientes/7 → Apaga o clientes #7

52. Como lidar com relacionamentos
● Por exemplo: um cliente possui um certo número de endereços
para entrega. Nesse caso poderíamos mapear da seguinte forma:
○ GET → /clientes/7/enderecos → Retorna a lista de endereços do
usuário
○ GET → /clientes/7/enderecos/5 → Retorna o endereço #5 do cliente
#7
○ POST → /clientes/7/enderecos → Cria um novo endereço para o
cliente 7.
○ PUT → /clientes/7/enderecos/5 → Atualiza o endereço #5 do
cliente #7
○ DELETE → /clientes/7/enderecos/5 → Apaga o endereço #5 do
cliente #7

53. O que fazer quando não se encaixa em um CRUD?
Reestruturar a ação para aparecer um campo de um recurso. Isso
funciona se a ação não tem parâmetros.
Por exemplo, uma ação “favoritar” poderia ser mapeada para um
campo booleano "favorito" e atualizado através de um PATCH para o
recurso.
Porém podemos tratá-lo como um sub-recurso, por exemplo, a API do
GitHub:
PUT → /gists/:id/star → Favorita
DELETE → /gists/:id/star → "Desfavoritar"

54. Documentação
● Facilitar o acesso para o desenvolvedor que irá consumir a API
● Mostrar exemplos completos de ciclos de requisição/resposta
● Não quebrar a API sem aviso prévio

55. Ferramentas para documentação
● Swagger
○ http://swagger.io/

56. Ferramentas para documentação
● RAML
○ http://raml.org/

57. Filtragem de resultados, ordenação e busca
● Manter os URLs de recursos-base tão enxutos (lean) quanto
possível
○ Ordenação e pesquisas avançadas podem ser
implementadas como parâmetros

58. Filtragem
● Usa-se um parâmetro de consulta exclusivo para cada campo que
implementa a filtragem.
○ Por exemplo, ao solicitar uma lista de clientes a partir do
endpoint /clientes, pode-se querer limitar o resultado para
apenas aqueles no estado “ativo”
○ Isto poderia ser conseguido com um pedido GET
/clientes?status=ativo, no qual status é um parâmetro de
consulta que implementa um filtro.

59. Ordenação
Utilizamos um parâmetro genérico sort para descrever regras de
ordenação, permitindo requisitos complexos de ordenação deixando
este parâmetro em classificações em que cada campo é separado por
vírgula, cada um com um possível unário negativo para indicar ordem
descendente.
Por exemplo:
GET → /clientes?sort=-idade → Retorna uma lista de clientes
em ordem descendente de idade.
GET → /clientes?sort=-idade,data_criacao → Retorna uma lista
de clientes em ordem descendente de idade com uma prioridade
específica de clientes antigos primeiro

60. Busca
Pode expor na API como um parâmetro de consulta no nó de
extremidade do recurso.
Considerando q, as consultas de pesquisa devem ser passados
diretamente para o motor de busca e o retorno da API deve ser no
mesmo formato, como resultado normal em lista.
Por exemplo:
GET /clientes?q=heider&status=ativo&sort=data_criacao → Retorna
clientes ativos com prioridade a data de criação e que tenha o nome Heider.

61. Limitando os campos de retorno
O consumidor da API nem sempre precisa da representação completa
de um recurso. Podemos expor a capacidade de selecionar e escolher
campos retornados permitindo que o consumidor minimize o tráfego de
rede e acelere sua própria utilização da API.
Por exemplo:
GET → /clientes?fields=id,nome

62. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
Criando uma API Rest na prática

63. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
O que é NodeJS?

64. Definição
É uma plataforma para desenvolvimento de aplicações server-side
baseadas em rede utilizando JavaScript e o V8 JavaScript Engine, ou
seja, com Node.js podemos criar uma variedade de aplicações Web
utilizando apenas código em JavaScript.

65. Express.JS
• Framework para NodeJS que possui robusto conjunto de recursos para
desenvolver aplicações web, com sistemas de Views intuitivo (MVC),
robusto sistema de roteamento, um executável para geração de
aplicações e muito mais.

66. Começando o projeto
• Criar uma pasta chamada server
• Criar um arquivo chamado server.js
• Digitar npm init para criar o arquivo package.json

67. Começando o projeto

68. Começando o projeto
• Instalação do framework express
• npm install express --save
• Instalação da biblioteca de basic auth
• npm install basic-auth --save

69. Import
var express = require('express');
var app = express();
var basicAuth = require('basic-auth');

70. Autenticação
var auth = function (req, res, next) {
function unauthorized(res) {
res.set('WWW-Authenticate', 'Basic realm=Authorization
Required');
return res.sendStatus(401);
};
var user = basicAuth(req);
if (!user || !user.name || !user.pass) {
return unauthorized(res);
};
if (user.name === 'foo' && user.pass === 'bar') {
return next();
} else {
return unauthorized(res);
};
};

71. Começando o projeto
//ROTA SEM AUTENTICACAO
app.get('/', function(req, res) {
res.send('Benvindo ao mundo das APIs');
});
//ROTA COM AUTENTICACAO
app.patch('/led/:ledId/ligar', auth, function(req,
res) {
res.sendStatus(200);
});

72. Rodando nossa aplicação
• Abrir o terminal
• Acessar a pasta onde encontra-se o nosso servidor (ex.: server.js)
• Digitar o comando node <<nomedoarquivo>>
• Por exemplo: node server.js

73. Acessar nosso serviço
• Através do browser
• http://localhost:3000
• Através do curl
• curl http://localhost:3000

74. Johnny Five
• Framework de código aberto que nos permite controlar o hardware
utilizando JavaScript, desenvolvido pela Bocoup
• Documentação disponível em:
• http://johnny-five.io/
• Para instalar
• npm install johnny-five --save

75. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
Montando o projeto no Arduino

76. Johnny Five
• O "StandardFirmata" é uma implementação do protocolo "Firmata", que
serve para programar microcontroladores como o Arduino.
• Abra a IDE do Arduino
• Carregue o exemplo: "StandardFirmata":
• Clique no botão "Upload"
• Agora, você já pode executar
programas Javascript, com Node.js,
para controlar o seu Arduino!

77. Arduino

78. “COMO O ROCK PODE
AJUDAR VOCÊ A
EMPREENDER”.
COAUTOR MARCO
BEZZI
Nosso APP Android

79. build.gradle (module)
//Retrofit
compile 'com.squareup.retrofit2:retrofit:2.1.0'
compile 'com.squareup.retrofit2:converter-gson:2.1.0'
//Stetho
compile 'com.facebook.stetho:stetho:1.4.1'
compile 'com.facebook.stetho:stetho-okhttp3:1.4.1'

80. Android Manifest
<uses-permission android:name="android.permission.INTERNET"/>

81. Android Manifest
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical"
tools:context="br.com.heiderlopes.mundoapi.MainActivity">
<Button
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="Ligar"
android:onClick="ligar"/>
</LinearLayout>

82. Android Manifest
public void ligar(View v) {
final String credentials = "heiderlopes:android";
final String basicAuthToken = Base64.encodeToString(credentials.getBytes(), Base64.NO_WRAP);
LedAPI ledAPI = ServiceGeneratorBasicAuth.createService(LedAPI.class, basicAuthToken);
Call<Void> call = ledAPI.ligar(1);
call.enqueue(new Callback<Void>() {
@Override
public void onResponse(Call<Void> call, Response<Void> response) {
switch (response.code()) {
case 401:
Toast.makeText(getApplicationContext(), "Nao autorizado",
Toast.LENGTH_SHORT).show();
break;
case 200:
Toast.makeText(getApplicationContext(), "Sucesso",
Toast.LENGTH_SHORT).show();
break;
}
}
@Override
public void onFailure(Call<Void> call, Throwable t) {
Toast.makeText(getApplicationContext(), t.getMessage(),
Toast.LENGTH_SHORT).show();
}
});
}

83. Copyright © 2017 - Prof. Heider Lopes.
Todos direitos reservados. Reprodução ou divulgação total ou parcial deste
documento é expressamente proíbido sem o consentimento formal, por
escrito, do Professor (autor).