Introdução à Web e API @analu.io

@analu.io Antes eu fazia partos, hoje eu faço bugs desenvolvo softwares Prazer, Analu. Sou desenvolvedora back-end, instrutora de programação, tech lead na {Reprograma}, community manager no Java Girls JUG e Engenheira de Software no Itaú Unibanco eu 27 anos, São Paulo Engenheira de Softwares

Objetivos Consumindo APIs Iniciando com Node.js APIs produtivas to-do API Modelo Server/Client URI, URL, URN, Dominio, IP e DNS API e API Rest Protocolo HTTP @analu.io

antes de começar garanta que você tem acesso a sua conta github, o gitbash na sua maquina configure e garanta que você consegue acessar sua conta do github pelo gitbash você tem o vscode, gitbash e insomnia na sua maquina @analu.io Se tem dúvidas sobre git e github veja meu material em: https://github.com/analuizasampaio/ apostila-github-basico

Como funciona a Internet? @analu.io

Servidor/Cliente @analu.io Usuários Client Server Banco de dados

Servidor/Cliente @analu.io Usuários Client Server https://tfunicamp.com.br/ 23.146.231.43 DNS

Client @analu.io usuários Client Server Algumas tarefas a serem realizadas pelo Cliente: Manipulação de tela Interpretação de menus ou comandos Entrada e validação dos dados Recuperação de erro Manipulação de janelas Gerenciamento de som e vídeo (em aplicações multimídia) Client é a interface que os usuários interagem, é essa camada que é responsável de solicitar serviços e informações de um ou mais servidores.

Server @analu.io O processamento do servidor geralmente inclui: Acessar Organizar os dados compartilhados Fazer a comunicação com o Banco de Dados Atualizar dados previamente armazenados Gerenciamento dos recursos compartilhados. O Servidor é o responsável pelo processo, organização e gerenciamento das informações. É ele que responde às solicitações feitas pelo Client. Ele é um processo reativo, disparado pela chegada de pedidos de seus clientes Client Server Banco de dados

1 2 3 4 A URI é processada É feita uma requisição A pagina é renderizadas e aparece na tela É dada uma Resposta @analu.io O que acontece quando acessamos um site? https://tfunicamp.com.br/

1 A URI é processada @analu.io Todo site tem um domínio, normalmente é por ele que acessamos e conhecemos o Site. Porém, no Server esse site não está registrado pelo nome de domínio, e sim pelo endereço de IP Internet Protocol Address é o endereço exato de onde o site está dentro do servidor. Então, antes de uma requisição ser feita o dominio deve virar o IP, e pra isso, usamos o DNS, o Domain Name System (Sistema de Nome de Domínio) que é como um grande dicionario de domínio para IP que já vem "de fábrica" no browser www.reprograma.com.br 128.195.116.204 www.google.com www.gov.br 23.146.231.43 162.29.146.27

1 A URI é processada: URL @analu.io URL - Uniform Resource Locator (localizador de recurso uniforme). Ela representa o local/Host que estão localizados os recursos www.reprograma.com.br 23.146.231.43 tfunicamp.com.br/ Para entendermos uma URI precisamos entender a URL e a URN. URL

1 A URI é processada: URN @analu.io URN – Uniform Resource Name (Nome de Recursos Universal). Ela representa um recurso específico na web que está sendo acessado www.reprograma.com.br 23.146.231.43 /contato /cronograma /patrocinadores URN

1 A URI é processada: URI @analu.io Pode ser uma página html, imagem, video ou qualquer outro arquivo web tem um endereço dentro da internet, esse endereço é a URI URI – Uniform Resource Identifier (Identificador de Recursos Universal). É o identificador contendo que une o protocolo http + o localizador do recurso (URL) + nome do recurso (URN) www.reprograma.com.br 23.146.231.43 https:// tfunicamp.com.br /cronograma protocolo URL URN

2 O Request é enviado @analu.io Agora com endereço certo, o Client faz uma requisição, ou Request, cheio de informações desejadas. Pra que isso aconteça, tanto o Server quando o Client devem "falar a mesma lingua". 23.146.231.43 Client Server Banco de dados Na maioria dos casos, essa comunicação entre Server e Client é feita a partir do Protocolo HTTP

2 O Request é enviado: HTTP @analu.io Protocolo de Transferência de Hipertexto, o HTTP, é um protocolo usado dentro do modelo Client/Server é baseado em pedidos (requests) e respostas (responses). HTTP request Client HTTP response Server O protocolo HTTP define um conjunto de métodos de requisição responsáveis por indicar a ação a ser executada. Eles são chamados de Verbos HTTP ou Métodos HTTP.

2 O Request é enviado: CRUD @analu.io Cada um deles corresponde a uma ação real no banco de dados. Os verbos HTTP mais utilizados são: GET POST PUT PATCH DELETE GET POST PUT PATCH DELETE ler criar substituir modificar excluir CRUD é a composição da primeira letra de 4 operações básicas de um banco de dados, e são o que a maioria das aplicação faz ✅ C: Create (criar) - criar um novo registro 👁 R: Read (ler) - exibir as informações de um registro ♻️ U: Update (atualizar) - atualizar os dados do registro ❌ D: Delete (apagar) - apagar um registro

3 O Server responde @analu.io Quando o Client faz um Request o Server envia um Response. E na resposta tem, além do resultado do que foi pedido, um código de status numérico padronizado 100-199 informação sucesso redirecionamento erro do cliente erro de servidor 200-299 300-399 400-499 500-599 código tipo de resposta

4 Finalmente! O site aparece na tela @analu.io

Ai, que canseira 10 min @analu.io

@analu.io Client Server GET POST PUT PATCH DELETE HTTP request HTTP response HTTP request HTTP response 100-199 informação sucesso redirecionamento erro do cliente erro de servidor 200-299 300-399 400-499 500-599 código tipo de resposta GET POST PUT PATCH DELETE ler criar substituir modificar excluir verbo ação

E quem faz tudo isso? @analu.io

A gente, as Devs Back-end @analu.io

São as pessoas que são responsáveis muito mais do que construir as telas bonitas e funcionais focadas no usuário. Elas tem que criar aplicações preparadas para enviar Requests corretamente e receber as Responses, também disponibilizar de forma performática para os usuários Dentro desse fluxo, são as pessoas que constroem toda a dinâmica do recebimento de Requests, o envio das Responses corretas, o tratamento das Responses, as solicitações de execuções de ação no Banco de Dados, conexão com outras aplicações ou sistemas e ainda a disponibilização de tudo da forma mais simples possível para a Dev Front. Dev Front @analu.io Dev Back

tá, mas o que realmente é isso? Interface de Programação de Aplicativos API @analu.io

Imagine um rádio o I da API Interface @analu.io

o I da API Interface @analu.io

o I da API Interface @analu.io O mesmo contece com nosso celular

O mesmo contece com nosso celular o I da API Interface @analu.io

O mesmo contece com nosso celular o I da API Interface @analu.io

@analu.io Assim como a interface do rádio, a API busca criar formas e ferramentas de se usar uma funcionalidade ou uma informação sem realmente ter que "reinventar a tal função." Interface de Programação de Aplicativos Ela não necessariamente está num link na Web, ela pode ser uma lib ou um framework, uma função já pronta em uma linguagem especifica, etc.

São um conjunto de instruções e padrões de programação para acesso a um aplicativo de software. Uma empresa de software lança sua API para o público de modo que outros criadores de software possam desenvolver produtos acionados por esse serviço. Web APIs @analu.io

São aquelas que são disponibilizadas gratuitamente para desenvolvedoras e usuarios com restrição minima. Podem precisar de cadastro, o uso de API Key ou ser completamente abertas. Elas estão relacionadas com uso externo de dados ou serviços. APIs Publicas @analu.io

São oposto das APIs públicas. Elas estão ligadas à serviços sigilosos, dados sensiveis, transações de empresas privadas, comunicação e ferramentas interna da empresa, etc APIs Privadas @analu.io

Rest, que é a abreviatura de Representational State Transfer, é um conjunto de restrições e boas praticas utilizadas para que as requisições HTTP atendam as diretrizes definidas na arquitetura. APIs REST e RESTfull @analu.io todas as APIs RESTful são APIs REST, mas nem todas as APIs REST são necessariamente RESTful API REST refere-se à abordagem arquitetural em si, descrevendo os princípios gerais que guiam a criação de serviços web. API RESTful é uma implementação específica de uma API que adere aos princípios do REST, seguindo as diretrizes e boas práticas estabelecidas.

Usa os métodos HTTP (GET, POST, PUT, DELETE) para realizar operações em recursos. Usa URIs (Uniform Resource Identifiers) para identificar e acessar recursos. Retorna dados no formato JSON ou XML. Stateless: Cada solicitação HTTP contém todas as informações necessárias para ser processada pelo servidor. Os métodos HTTP são mapeados para operações CRUD no servidor. APIs REST e RESTfull @analu.io Foca em recursos (entidades de negócio) e ações sobre esses recursos usando métodos HTTP. Utiliza URIs amigáveis e semânticas para identificar e acessar recursos. Fornece respostas bem estruturadas e padronizadas usando os códigos de status HTTP apropriados. Pode implementar a negociação de conteúdo, permitindo que os clientes solicitem dados em diferentes formatos (JSON, XML, etc.). Pode oferecer suporte a HATEOAS (Hypertext As The Engine Of Application State), permitindo a descoberta dinâmica de recursos relacionados por meio de links.

Ai, que canseira 10 min @analu.io

@analu.io

Objetivos Consumindo APIs Iniciando com Node.js APIs Produtivas to-do API Modelo Server/Client URI, URL, URN, Dominio, IP e DNS API e API Rest Protocolo HTTP @analu.io

Notação de Objetos JavaScript. JSON é uma formatação leve de troca de dados. É em formato de texto e completamente independente de linguagem, pois usa convenções que são familiares às linguagens C e familiares, incluindo C++, C#, Java, JavaScript, Perl, Python e muitas outras. Estas propriedades fazem com que JSON seja um formato ideal de troca de dados. JSON @analu.io JSON é baseado em duas estruturas: Uma coleção de pares de nome / valor. Em várias linguagens, isso é realizado como um objeto, registro, estrutura, dicionário, tabela de hash, lista de chaves ou matriz associativa. Uma lista ordenada de valores. Na maioria das linguagens, isso é realizado como um array, vetor, lista ou sequência. .

Documentação https://ghibliapi.vercel.app/ Consumindo API @analu.io

Você pode incluir os mesmos tipos de dados básicos como em um objeto JavaScript padrão. Porem, diferente das Arrays e Objetos os nomes das propriedades devem ser strings com aspas duplas e as vírgulas à direita são proibidas. JSON @analu.io

curl Consumindo API @analu.io

Consumindo com curl Consumindo API @analu.io

Consumindo com Postman Consumindo API @analu.io

Consumindo como um Front Consumindo API @analu.io

Objetivos Consumindo APIs Iniciando com Node.js APIs Produtivas to-do API Modelo Server/Client URI, URL, URN, Dominio, IP e DNS API e API Rest Protocolo HTTP @analu.io

Criando servidores com Node.js finalmente @analu.io

antes de começar criar repositório no github clonar na sua máquina criar o arquivo server.js @analu.io

Antes de tudo, um pouco de história! Tudo começou em 2009... Node.js Interpretador JavaScrypt que não precisa de navegador. Ele pode: Ler e escrever arquivos no seu computador Conectar com um banco de dados Se comportar como um servidor @analu.io node -v

e os gerenciadores de pacotes Node.js @analu.io

e a guerra dos 100 anos... npm X yarn @analu.io

npm init -y @analu.io

npm init @analu.io

só um pouquinho delas Dependências @analu.io

Express @analu.io

a grande. Não, não! A GIGANTESCA! node_modules @analu.io

a grande. Não, não! A GIGANTESCA! node_modules @analu.io

vamo ignorar ela gente .gitignore @analu.io

@analu.io GET Dentro do CRUD o método GET é representado pela letra R 👁 R: Read (ler) - exibir as informações de um registro O Client manda um request solicitando realizar um GET e o Server deve estar preparado para receber esse GET e responde-lo com um response. Client Server GET todos HTTP request HTTP response HTTP request HTTP response GET por id GET por nome

@analu.io POST Dentro do CRUD o método POST é representado pela letra C ✅ C: Create (criar) - criar um novo registro Client Server HTTP request HTTP response HTTP request HTTP response POST O Client manda um request solicitando realizar um POST e envia no Body o registro que quer cadastrar, o Server deve estar preparado para receber esse POST, incluir o novo item solicitado e responde-lo com um response.

pra parar de ficar atualizando nodemon @analu.io

{ Reprograma } @analu.io Body são usados nos métodos POST, PATCH e PUT enviam dados a serem cadastrados no banco de dados request.body

@analu.io Parâmetros usado para pesquisa simples, enviado diretamente na rota request.params usado para pesquisa de uma ou multiplas strings request.query usado para enviar dados que serão cadastrados no banco, podem ser combinados com o query ou o path params request.body Tanto o body quando o query e o path são parâmetros enviados na requisição e podem ser acessados pelo servidor afim de definir a requisição e as ações.

@analu.io Parâmetros são aqueles que são adicionados diretamente na URL "/rota/:id" request.params.id bons, porem limitantes, por exemplo, se quisermos filtrar por uma string Path params são aqueles que são adicionados a chave e o valor desejados "/rota?id=1234" request.query.id a forma mais efetiva de fazer requests com strings ou diversos valores Query params

@analu.io DELETE Dentro do CRUD o método DELETE é representado pela letra D ❌ D: Delete (apagar) - apagar um registro O Client manda um request solicitando realizar um DELETE e o Server deve estar preparado para receber esse DELETE e responde-lo com um response. Client Server DELETE por id HTTP request HTTP response HTTP request HTTP response

{ Reprograma } @analu.io HTTP - PUT & PATCH Client Server HTTP request HTTP response HTTP request HTTP response ♻️ U: Update (atualizar) - atualizar os dados do registro PATCH modificar PUT substituir

É tudo a mesma coisa? PUT x PATCH NÃO! O PUT substitui todo o objeto que você deseja modificar, já o PATCH modifica somente uma propriedade dentro do seu objeto. { Reprograma } @analu.io PUT "idade": 24 DADO "idade": 24 DADO INICIAL "nome": "ana", "idade": 18, "cor": "preta" DADO "nome": "ana", "idade": 24, "cor": "preta" PATCH "idade": 24

Mas então por que ainda usamos o PUT? PUT x PATCH Muitas vezes ainda usamos o PUT pela performance que ele tem quando relacionado o banco de dados. Substituir um dado inteiro é mais rápido do que somente uma propriedade dele. Por exemplo, vamos simular a uma edição do campo idade no dado de id=4 { Reprograma } @analu.io id: 1 "nome": "ana", "idade": 18, "cor": "preta" procure id =4 id: 2 "nome": "ana", "idade": 18, "cor": "preta" id: 3 "nome": "ana", "idade": 18, "cor": "preta" id: 4 "nome": "ana", "idade": 18, "cor": "preta" id: 5 "nome": "ana", "idade": 18, "cor": "preta" id: 6 "nome": "ana", "idade": 18, "cor": "preta" id: 7 "nome": "ana", "idade": 18, "cor": "preta" id: 8 "nome": "ana", "idade": 18, "cor": "preta"

Mas então por que ainda usamos o PUT? PUT x PATCH Por exemplo, vamos simular a uma edição do campo idade no dado de id=4. No banco de dados nosso programa tem que percorrer pela memória procurando pelo id que queremos { Reprograma } @analu.io id: 1 "nome": "ana", "idade": 18, "cor": "preta" procure id =4 id: 2 "nome": "ana", "idade": 18, "cor": "preta" id: 3 "nome": "ana", "idade": 18, "cor": "preta" id: 4 "nome": "ana", "idade": 18, "cor": "preta" id: 5 "nome": "ana", "idade": 18, "cor": "preta" id: 6 "nome": "ana", "idade": 18, "cor": "preta" id: 7 "nome": "ana", "idade": 18, "cor": "preta" id: 8 "nome": "ana", "idade": 18, "cor": "preta"

Mas então por que ainda usamos o PUT? PUT x PATCH Por exemplo, vamos simular a uma edição do campo idade no dado de id=4. No banco de dados nosso programa tem que percorrer pela memória procurando pelo id que queremos. Ele procura somente pelo índice que indicamos. { Reprograma } @analu.io id: 1 "nome": "ana", "idade": 18, "cor": "preta" procure id =4 id: 2 "nome": "ana", "idade": 18, "cor": "preta" id: 3 "nome": "ana", "idade": 18, "cor": "preta" id: 4 "nome": "ana", "idade": 18, "cor": "preta" id: 5 "nome": "ana", "idade": 18, "cor": "preta" id: 6 "nome": "ana", "idade": 18, "cor": "preta" id: 7 "nome": "ana", "idade": 18, "cor": "preta" id: 8 "nome": "ana", "idade": 18, "cor": "preta"

Mas então por que ainda usamos o PUT? PUT x PATCH Se estivéssemos escolhido um método PUT, a procura pararia aqui e o dado seria substituído por inteiro! { Reprograma } @analu.io id: 1 "nome": "ana", "idade": 18, "cor": "preta" procure id =4 id: 2 "nome": "ana", "idade": 18, "cor": "preta" id: 3 "nome": "ana", "idade": 18, "cor": "preta" id: 4 "nome": "ana", "idade": 24, "cor": "preta" id: 5 "nome": "ana", "idade": 18, "cor": "preta" id: 6 "nome": "ana", "idade": 18, "cor": "preta" id: 7 "nome": "ana", "idade": 18, "cor": "preta" id: 8 "nome": "ana", "idade": 18, "cor": "preta"

Mas então por que ainda usamos o PUT? PUT x PATCH Porém estivéssemos escolhido um método PATCH, a procura continuaria, agora dentro do dado { Reprograma } @analu.io procure id =4 id: 1 "nome": "ana", "idade": 18, "cor": "preta" idade

Mas então por que ainda usamos o PUT? PUT x PATCH Porém estivéssemos escolhido um método PATCH, a procura continuaria, agora dentro do dado. Quando encontrado a propriedade ai sim o dado seria modificado. Tudo isso seriam frações de segundos para um computador, mas se tivéssemos dezenas de milhares de dados sendo modificados o tempo todo, como uma rede social, por exemplo, isso poderia causar certa lentidão no banco de dados @analu.io procure id =4 id: 1 "nome": "ana", "idade": 24, "cor": "preta" idade

Mas então por que ainda usamos o PUT? PUT x PATCH Porém estivéssemos escolhido um método PATCH, a procura continuaria, agora dentro do dado. Quando encontrado a propriedade ai sim o dado seria modificado. Tudo isso seriam frações de segundos para um computador, mas se tivéssemos dezenas de milhares de dados sendo modificados o tempo todo, como uma rede social, por exemplo, isso poderia causar certa lentidão no banco de dados @analu.io procure id =4 id: 1 "nome": "ana", "idade": 24, "cor": "preta" idade

Objetivos Consumindo APIs Iniciando com Node.js APIs Produtivas to-do API Modelo Server/Client URI, URL, URN, Dominio, IP e DNS API e API Rest Protocolo HTTP @analu.io

Como funciona na vida real? @analu.io

@analu.io Até agora nós estávamos fazendo tudo dentro de um arquivo só, o server.js Projeto atual acessando o JSON conectando com express criando as rotas criando as lógicas configurando a porta e iniciando o servidor criando as rotas criando as lógicas

@analu.io E tudo isso faz muito sentido se a gente tiver um projeto simples, mas... como a gente faz quando temos um projeto mais complexo? Projeto atual acessando o JSON conectando com express GET /rota logica configurando a porta e iniciando o servidor acessando o JSON acessando o JSON GET /rota logica POST/rota logica POST/rota logica GET /rota logica PATCH/rota logica DELETE/rota logica GET/rota logica acessando o JSON

Arquitetura Monolítica vs. Arquitetura Escalável APIs na Vida Real Monolítica: Toda a lógica e funcionalidades em um único código base. Simples, mas difícil de escalar conforme cresce. Escalável: Arquitetura moderna separa responsabilidades, melhora a manutenibilidade e escalabilidade @analu.io MVC (Model-View-Controller): Separação entre dados (Model), interface (View), e lógica de controle (Controller). Amplamente usado para aplicações web. Arquitetura Hexagonal: Isola a lógica de negócio da infraestrutura externa (banco de dados, APIs, etc.). Foco em independência e fácil manutenção. Facilita a troca de componentes sem afetar o núcleo da aplicação. DDD (Domain-Driven Design): Enfatiza a modelagem da aplicação baseada nos domínios de negócio. Alta coesão de lógica de negócios e separação de responsabilidades

Separação de Responsabilidades e escalabilidade Microservices Microsserviços são uma abordagem arquitetural onde uma aplicação é dividida em vários serviços menores, cada um responsável por uma funcionalidade específica. Esses serviços são independentes, podem ser desenvolvidos, testados e implantados separadamente. @analu.io Escalabilidade Independente: Cada microservice pode ser escalado conforme a necessidade, otimizando o uso de recursos. Flexibilidade Tecnológica: Cada serviço pode ser desenvolvido em diferentes linguagens e tecnologias. Manutenção e Deploy: Atualizações e correções são feitas em serviços individuais, sem impacto no sistema completo. Resiliência: A falha de um microservice não compromete toda a aplicação, mantendo outros serviços operacionais.

Cloud Cloud Computing é a entrega de recursos de computação (servidores, armazenamento, bancos de dados, redes, software) pela internet, em vez de ter servidores físicos locais. @analu.io Elasticidade: A capacidade de aumentar ou diminuir automaticamente os recursos conforme a demanda, garantindo que sua API consiga lidar com picos de tráfego sem sobrecarregar a infraestrutura. Alta Disponibilidade: Serviços em cloud oferecem replicação de dados e redundância para garantir que a API esteja sempre disponível, mesmo em caso de falhas. Custo-Efetividade: Você paga apenas pelos recursos que realmente usa, o que otimiza o investimento, especialmente em sistemas escaláveis

APIs Produtivas @analu.io

@analu.io Client Server GET POST PUT PATCH DELETE HTTP request HTTP response HTTP request HTTP response 100-199 informação sucesso redirecionamento erro do cliente erro de servidor 200-299 300-399 400-499 500-599 código tipo de resposta GET POST PUT PATCH DELETE ler criar substituir modificar excluir verbo ação

Objetivos Consumindo APIs Iniciando com Node.js APIs Produtivas to-do API Modelo Server/Client URI, URL, URN, Dominio, IP e DNS API e API Rest Protocolo HTTP @analu.io

Obrigada! @analu.io