Confira umas dicas de desenvolvimento de software em áudio. Explicações e discussões de temas de programação, engenharia de código, aplicativos, web, etc.

Dicas de Desenvolvimento de Software em Áudio

O que é JSON (Dica de Software em Áudio)

O que é JSN, no inglês JavaScript Object Notation, notação de objeto de JavaScript?
A gente fala JSON no inglês.
JSN é um formato de dados multi utilizado hoje, especialmente no desenvolvimento web.
Por exemplo, você tem um site, você acessa o site do navegador.
Esse site se comunica com um ou mais servidores.
Essa comunicação tem o uso de um certo formato.
Normalmente a gente usa o protocolo HTTP, Hypertext Transfer Protocol.
Mas a informação tem que estar escrita em um certo formato.
E esse formato de texto pode ser no formato JSON.
Então, é muito comum hoje em dia essa comunicação entre clientes e servidores usar o formato JSON.
Mas como é esse formato?
Bem, esse formato é bem parecido com um objeto de JavaScript.
Se você já programou JavaScript, nós criamos objetos, normalmente são representados com as chaves.
Abra a chave, fecha a chave.
E as propriedades, os pares de chave e valor.
Propriedade e valor dentro dessas chaves.
Normalmente tem duas partes para cada par.
O lado esquerdo, que é o nome da propriedade e o lado direito que é o valor.
Então, o nome da propriedade sempre é uma string.
Isto é uma sequência de caracteres.
E essa string sempre tem que estar dentro de aspas duplas.
E a gente separa a chave e o valor com os dois pontos.
Por exemplo, abre aspas, o nome da propriedade fecha aspas, dois pontos.
Então, fica no lado direito, depois dos dois pontos, o valor.
O valor pode ser vários tipos.
E normalmente são os tipos primitivos do JavaScript, se você conhece.
Por exemplo, podemos ter número, string, boolean, array, ou até o próprio objeto.
Então, a propriedade tem que ser sempre string, mas o valor pode ser esses tipos que eu acabei de falar.
Então, a gente pode ter um objeto dentro de outro objeto, dentro de outro objeto e assim por diante.
As vezes é negócio.
Caso disso, tem uma hierarquia.
Então, a JSON tem como você fazer uma hierarquia.
Então, o formato JSON é bem fácil para a gente ler, interpretar.
Bem simples, é legível para humanos.
O formato também é flexível.
O processo de conversão na Englishfella parsing, ou também se chama serialização, é bem rápido.
Então, essas condições são favoráveis para que o JSON seja o formato popular hoje em dia.
Antes do JSON, se usava muito xml, mas hoje é mais JSON.
Então, Json, JavaScript Object Notation.
A gente usa os formatos de dados para comunicação entre clientes e servidores.
Então, no formato JSON, abre as chaves, aspas, o nome da propriedade, feche aspas, dois pontos.
Valor, por exemplo, um, dois, três, como o número.
Para poder ter várias pares, a gente separa eles por uma vírgula.
Então, depois que eu acabei de falar um, dois, três, vírgula, você pode adicionar mais outro par de propriedade e valor.
O espaço não importa no JSON, se for fora das aspas de string.
Então, você pode ter um texto em formato JSON em uma só linha, ou pode ser várias linhas.
Normalmente, quando você envia os dados, normalmente seria só uma linha para você economizar, tirar todo o espaço,
porque a máquina não se porta com o espaço, e o espaço só ocupa o espaço.
E se você mandar os espaços, você está mandando mais dados do que é necessário.
Isso custa na banda larga, né?
Bandwidth.
Então, normalmente você tira os espaços, mas a gente gosta de adicionar espaço e indentação só para ser elegivo para humanos,
para a gente que é programador.
Então, normalmente quando você formata para humanos, você adiciona espaço e indentação,
normalmente é pares por linha, um par por linha, né?
E adiciona indentação para cada chave que você abre.
Certo?
Um detalhe no formato JSON.
A última, o último par de propriedade de valor, depois do lado direito dele, não tem vírgula.
No JavaScript, o objeto JavaScript pode ter a vírgula, no final, depois do último par de propriedade de valor.
E no formato JSON, que é um formato em texto, não pode ter essa vírgula no final.
Isso é um erro comum que você pode ter se você é acostumado a adicionar vírgula
depois de cada par de propriedade e nome no JavaScript.
Tá certo? Então, se você quiser, é muito comum hoje nós temos, tivemos várias APIs,
a Apliquecha Program Interface, que servem formato JSON, que para se comunicar com aquela API,
você tem que escrever o seu texto na maneira JSON.
Tá muito comum hoje em dia.
A gente chama API JSON, né? JSON API.
Tá bom? Então, Json JavaScript Object Notation, formato de dados.
Obrigado por ouvir e até a próxima.


001b-01 O que é JSON (Dica de Software em Áudio)

O que é SPA (Dica de Software em Áudio)

O que é SPA? SPA significa no inglês Single Page Application, aplicação de uma página
única.
Então SPA é o marco da Web 2.0.
Tradicionalmente, antes da Web 2.0, cada página que você acessa um navegador, seria um pedido
para o servidor e o servidor mandava a página inteira, o arquivo HTML.
E para cada link que você clicava, aquele link fazia outro pedido para o servidor.
O servidor gerava o conteúdo para a página e mandava todo aquele conteúdo em sua totalidade.
De volta para o cliente.
O cliente pegava aquilo e teria que renderizar toda a página do zero novamente.
Certo?
Então, sempre assim, cada página nova um novo pedido para a página inteira que você
recebe.
Isso mudou com o conceito de SPA, Single Page Application, aplicação de página única.
No conceito do Single Page Application, em vez de você fazer o pedido ao servidor
pela nova página inteira, você só faz um pedido por partes.
Por exemplo, vamos dizer que você carrega na primeira vez a página inteira, o site
inteiro.
E você clica, você tem uma caixa de comentário e tem uma lista de comentários.
Você digita na caixa de comentários e você clica para enviar o comentário ao servidor.
Tradicionalmente isso seria uma nova página inteira carregada.
Mas no SPA o que acontece?
Você manda só informação do comentário para o servidor.
Servidor manda de volta a resposta.
Isso é, teve êxito na criação do comentário.
Se esse foi o caso, o cliente pega aqueles dados e coloca, cria uma nova, um novo elemento
e esse elemento tem o texto alterado com o novo comentário.
E esse elemento é injetado na lista de comentários da página.
Então o cliente foi responsável ao processamento, nesse caso, pela manipulação do DOM.
DOM é o document object model.
É o modelo de objetos e documento.
Então não houve um carregamento da página inteira.
Então houve um envio de certa peça de informação ao servidor e uma resposta de certa peça
de informação e através dessa resposta o cliente interpreta e manipula a página existente,
a estrutura existente para poder refletir o novo estado da interface de usuário.
SPA, single page application.
Então é TV emergency na chamada web 2.0, quando antigamente páginas escritas em HTML, CSS
e algum JavaScript.
Então a web era mais para documentos estáticos.
O que é documentos estáticos?
Era só texto que a gente lia para compartilhar os documentos.
Tinha uma página, tinha um site e o site era só informativo.
A gente lia, tinha vários textos, explicava em outro link, ia para outro local e lia mais
coisas.
Ao mesmo tempo a gente tinha os desktop, os computadores, tinha aplicativos de desktop,
se os programas.
O que aconteceu?
A web se tornou muito popular e o pessoal começou a tornar os sites interativos, começar a
adicionar mais scripts, mais a coisa no servidor, armazenamento de informação, armazenamento
dos estados, das coisas, assim por diante.
Então cada vez mais os sites se tornaram mais interativos.
Os sites começaram a receber impulsos do usuário, receber entrada e começou a ter
mais processamento.
E essa interação levou ao site se tornarem aplicativos de web.
E a SPA, um dos fins da SPA, é tornar o site, tornar ele mais parecido com o programa
de desktop.
Então foi por isso que um dos motivos da existência do SPA.
Porque o programa de desktop é bem... não há aquele lance de carregar tudo do zero
novamente.
Isso é só no navegador.
E o programa de desktop roda bem, como você fala.
Bem suave.
É, não há nenhum...
Nenhum... como é que se diz?
Não é interrupção, né?
No caso da navegador, a interrupção seria... você clica no link e ele carrega uma nova
página e você tem que esperar para tudo do zero ser reconstruído.
Então SPA resolve esse problema e com SPA emerge a web 2.0, os aplicativos web.
E esse processo começou através de uma coisa chamada XML HTTP request, XML HTTP request.
A sigla XHA.
XHA, XHR.
Então foi esse XML HTTP request, foi o processo de você enviar a... que queria informação
ao servidor sem recarregar a página.
Então você tem no nosso exemplo para voltar o exemplo da lista de comentários de uma
caixa para digitar um novo comentário.
Quando você clicava para enviar o comentário, ele fazia uma XML HTTP request, uma requisição
HTTP de XML.
Então ele fazia essa requisição sem recarregar a página, sem recarregar a página.
E o servidor respondia com uma peça de informação.
Agora esse formato de texto antigamente era XML e hoje é JSON, essa troca de informação.
Então o cliente passa a processar mais as coisas.
Antigamente, tradicionalmente, antes da web 2.0, quem fazia a maioria do processamento era o servidor.
O servidor era responsável por gerar a página HTML, para servir os recursos.
De CSS, JavaScript.
Então ele já mandava a página já pronta, o texto com HTML tudo pronto.
Agora muda o paradigma, você dá mais, você muda e o servidor vai passar a fazer menos processamento da manipulação,
menos processamento da geração de HTML.
E agora quem tem o modelo, o papel da manipulação do HTML, do DOM, é o cliente.
Então o cliente passa a processar mais coisas.
Então o cliente vai começar a manipular os elementos da página,
começar a mudar os estilos, começar a fazer os comportamentos,
tornar a página dinâmica, mover as coisas.
Então é isso.
É claro que com o SPA também tem alguns desafios.
E um dos desafios grandes era, você sabe que toda vez que você clica no link, você vai para a nova página.
E no navegador tem os botões de voltar e avançar, anterior ou próximo.
Então um dos desafios do SPA era o lance do histórico de navegação,
porque o histórico era o obtido de cada link que você clicava, cada nova estabelecimento de uma página.
E você sabia através da URL que mudava, o caminho mudava.
Por isso que dava saber o histórico.
Agora com o SPA, ele não vai mais recarregar a página.
E isso, a URL não vai mudar.
E como é que a gente vai fazer para mandar, se você quer copiar o link para uma certa parte do aplicativo ou da página,
não vai dar para fazer isso, não dava.
Então isso foi o grande desafio do SPA.
E antigamente eles usavam o jogo da velha para poder simular uma sessão a parte diferente, uma página diferente,
embora que não era realmente uma página diferente, era a mesma página sempre.
Então tinha esse lance do jogo da velha.
Mas hoje em dia não se faz mais isso, hoje em dia a gente faz da maneira normal,
porque esse problema já foi resolvido através da API de histórico.
Nós temos um API de histórico que você chama no código JavaScript.
E você pode manipular e controlar o histórico através da API.
No caso do SPA, toda vez que você vai para uma sessão diferente, uma página diferente,
não realmente não é uma página diferente, mas é como se fosse,
você escreve no código JavaScript para poder adicionar um novo caminho ao histórico.
No caso na terminologia da API de histórico é push state, colocar um estado novo.
Você coloca uma pilha de papel, quando vai clicar em uma coisa você dá o push state para adicionar
uma folha em cima das folhas que já existiam e assim por diante.
E quando você clicar o botão de voltar, você é só ele tira a folha do topo e mostra a folha de baixo.
O pop, na terminologia do histórico.
Outro lance também que era um desafio da SPA é de SEO, SEO Search Engine Optimization.
Optimização da busca.
O lance do problema é que o servidor manda o HTML do aplicativo, mas esse HTML tem muita pouca coisa.
Por quê? Porque o cliente é que é responsável pela manipulação e controle dos elementos de HTML.
Então quando você recebe o servidor você recebe o esqueleto.
E quem aqui adiciona tudo os infeites e tudo mais é o cliente.
Mas quando as buscas rastreiam a web e fazem requisições para os servidores que servem os sites ou aplicativos
esses buscadores só vão receber aquele esqueleto que não tem nenhum conteúdo.
Então a buscador não vai saber o que é que é sobre o seu site.
Não tem dizendo nada aqui porque só tem o esqueleto.
Não tem nenhuma informação sobre o site.
E aí?
Esse é o lance, o problema da SPA.
Você teria que esperar o cliente organizar o site inteiro e construir no cliente para depois poder obter informação.
Então esse problema também foi resolvido.
Uma das madeiras de resolver isso é você já pré-compilar todos os sites, todas as páginas do site.
Ou você pode usar, tem gente que gosta de server-side rendering, SSR,
em que o servidor gera, já constrói o site de uma vez e manda para o cliente.
E o cliente ainda é SPA, mas ele já recebe tudo já pronto,
em vez do cliente ser responsável para construir as coisas depois de receber o servidor.
Então há umas maneiras de você resolver o problema de SIE, search engine optimization.
Então eu acho que já falei muita coisa sobre SPA.
Para concluir SPA single page application, um novo paradigma que emergiu da web 2.0,
em que os sites se tornaram interativos e passaram a ser aplicativos.
E para poder os aplicativos de web ficarem mais parecidos com programas de desktop.
E para interação, a experiência do usuário ser suave, temos esse novo conceito.
Tivemos os problemas do conceito que emergiram, problema de histórico, problema de SL,
mas que agora foram resolvidos com APD histórico, com precompilação ou o uso de server-side rendering,
renderização no lado do servidor.
Essa é só, então obrigado por ouvir e até a próxima.


001b-02 O que é SPA (Dica de Software em Áudio)

Confira umas dicas de desenvolvimento de software em áudio. Explicações e discussões de temas de programação, engenharia de código, aplicativos, web, etc.


O que é XSS (Dica de Software em Áudio)

O que é XSS? XSS é uma abreviação que no inglês significa cross-site scripting.
Se usa X porque o X parece com a cruz e cross é cruzar. Então cross-site scripting, scripting
de sites cruzados. XSS é um tipo de vulnerabilidade em aplicativos web. Era muito comum, ainda
é como hoje, mas era muito comum, tempos atrás, tinha muitas dessas vulnerabilidades.
Vou te dar um exemplo bem simples. Supou que você tem um site e tem uma lista de comentários
e tem uma caixa para você enviar um comentário, caixa de texto. Bem, normalmente a pessoa
quer digitar um texto e enviar um comentário, mas como você quer criar ou tomar vantagem de uma
vulnerabilidade, nesse caso, XSS, você faria o seguinte. Bem, vamos pensar no
que é bem. Vamos supor que a pessoa não tem intuição maligra. Antigamente, quando eu usava o site,
quando eu era criança, eu queria colocar fonte negrita. Aí eu descobri que era só botar o sinal
menor que b, maior que e botar o texto e fechar tag menor que barra b, maior que. E eu vi que
alguns sites funcionavam. Então esse é um exemplo bem, bem simples. Tio que isso pode ser XSS. Nesse
momento, você envia o comentário, na caixa de texto, você escreve a tag b, o texto e fecha tag de
HTML e b. E envia esse comentário. Esse comentário é enviado ao servidor, que é armazenado no banco
de dados. Quando você pega a lista de comentários, você recebe do servidor. E quando recebe do
servidor, você injeta os comentários no DOM, document object model, nos elementos da parte.
Então, um elemento é criado com o comentário. E no conteúdo do elemento tem aquele texto que eu
digitei na caixa de comentários. Nesse caso, eu tinha digitado uma tag b, bold, para deixar o
inegrito. Se não tiver nenhuma proteção contra XSS, nesse caso, a gente chama a limpeza da entrada,
em inglês, sanitization, ele vai deixar, quando já está no HTML, ele vai deixar o texto que eu
decidi. A minha mensagem, o meu comentário, vai aparecer em inegrito. Bem, esse exemplo foi bem
simples, mas poderia ser algo pior. Talvez alguém poderia ter digitado, por exemplo, alguém poderia ter
digitado uma tag de script menor que script maior que e fiz essa alguma coisa. Provavelmente coisa
ruim, né? E fecha tag de script e manda isso para o como comentário. E as outras pessoas que abrem a
página para ver os comentários, elas vão carregar o seu comentário. E o seu comentário, como tinha
uma tag de script, ninguém nem vai perceber porque uma tag de script não aparece nada na página que
é renderizada. A não ser que você tenha digitado também um comentário do lado do script só para
poder falsificar o comentário. Não, como se diz, forjar, né? Para se dizer que só comentou alguma
coisa, mas além do comentário tem também o script que seria executado também no navegador dessas
outras pessoas que acessam a mesma página. Se fosse algo bem fácil, poderia ser, por exemplo, obter
informações das pessoas. Por exemplo, se eu entro no site, eu sei que certas informações, quando eu
logo no site, né, quando eu entro, certas informações são pessoais minhas. Pode até ter
informação que é valiosa, né? Aí o que acontece? Como eu sei que essas informações estão na página?
Eu poderia, com o intento malicioso, criar um script que iria rastrear ou obter todas as
informações da estrutura do HTML e compilar uma mensagem e essa mensagem seria enviada a um
servidor meu para eu poder obter esses dados de outras pessoas. Esse script seria rodado
no navegador de cada pessoa que acesse, que acessa a página e vê os mesmos comentários.
Como são pessoas diferentes, elas logam com outro perfil, com outra conta. Então, você teria
acesso às informações dessas pessoas e essas informações seriam enviadas ao seu servidor
para você coletar dados roubados, né? Então, essa é a vulnerabilidade de
xss cross-site scripting, né? Tem também outras variações. Pode-se também tomar vantagem
da query string que tem, por exemplo, quando você faz uma busca,
normalmente aparece na URL, na barra de endereço do navegador, o sinal de interrogação, né?
E com a par de propriedade e valor que tem o valor da busca ou algum parâmetro da busca,
esse também pode ser um alvo de xss e você pode fazer alguma coisa lá que
vai causar alguma coisa de ser rodada, se não houver nenhuma proteção.
Tá bom? Então, essa é o xss. Hoje em dia, várias maneiras de se proteger é muito menos,
mas hoje em dia a incidência desse problema é muito menor porque já houveram vários
investimentos para poder na segurança de combater a vulnerabilidade de xss. Se você
fazer site ou aplicativos, você sempre deve sanitizar, que a gente fala em inglês, sanitize
as entradas. O que é isso? Cada mecanismo que você tem no seu aplicativo, que
qualquer usuário pode entrar algum tipo de informação, você tem que verificar se ele não
tentou colocar algo malicioso como um antag descript e assim por diante. Normalmente,
vários frameworks de desenvolvimento web de servidores de back-end e tal, eles já tem
embutido essa verificação,
verificação e ele, se você tentar, se alguns usuários tentam digitar um antag e tal,
ou pode ser, normalmente, a tag é removida ou algo assim acontece, então ele previne esse problema
de até ser armazenado no banco de dados, nesse caso.
Isso também, eu acho que ocorre no front-end frameworks como o videoatecas, react, view.
Deve ter também esse mecanismo de proteção já embutido, eu acho.
Até, por exemplo, se você escrever HTML puro, desculpa, JavaScript puro, você tem que
tocar em qual tipo de funções você usar, por exemplo, você não vai usar inner HTML,
normalmente, inner HTML pode ser um alvo de causar xs, de rodar o script.
Em vez de usar inner HTML, quando você quer modificar o conteúdo de um elemento de
HTML, você usa, por exemplo, text content. O text content, essa propriedade do
elemento, só muda o texto e não permite que rode script ou que use tags.
A navegadores hoje em dia também teve muito investimento nos navegadores e os próprios
navegadores bloqueiam essas tentativas de xss, então já vem embutido também no navegador,
embora que talvez o hacker pode também conseguir ultrapassar essa proteção no navegador,
porque é só para usuário comum que tem a proteção de habilitar, então ela pode ser
desabilitada do navegador. A outra coisa para remediar esse problema é content
security policy, CSP. Contents security policy, você pode enviar do servidor um header de
HTTP que determina a, como é que fala, policy, political, policy de segurança de
conteúdo, CSP, content security policy. E você pode determinar que o servidor, quando
manda a página de HTML, o navegador vê que tem o header de CSP e ele vai bloquear
por exemplo a execução de script inline, se você tiver algum script rodando lá que foi
adicionado por exemplo dentro do bar e você cria uma tag de script com um conteúdo dentro da tag sem ser
externo que oficial que você já tinha determinado que iria rodar e tal e tal. Se você quiser saber
mais sobre isso, pesquise CSP, content security policy. E assim por diante, então xss cross-site script
vão na habilidade que afeta aplicativos web, sites web, os hackers estão a vontade de isso porque
no navegador tem a execução de script de JavaScript, então devido a essa execução
desses programas de código, você pode injetar um script malucioso que acidentalmente pode
se tornar parte da estrutura da página presente, né? A injação de, você coloca um, por exemplo,
um tag de script com um script malucioso e esse script roda não só no seu
navegador, mas de outras pessoas, né? Tem também outro exemplo da página de support, por exemplo.
Acho que é parecido com os comentários, você tem, sabe que você vai nos sites, às vezes tem uma chat,
uma salinha de bate-papla, tem um ícone em um dos lados da tela que você clica aí,
ele vai para o suporte, né? Assistência ao consumidor e tal, você pode falar com alguém
e mandar mensagem, você também tem um risco de você colocar xss, tomar vantagem de xss aí.
Seria o seguinte, do seu perfil, não tem nenhuma informação,
mas do perfil da pessoa que oferece o suporte, né? O representante de suporte,
ele tem acesso no sistema dele, normalmente, há várias informações de vários clientes,
então quando ele vai ajudar o pessoal, ele tem uma lista de pessoal para ajudar
e quando ele está acessando o site do lado dele, tem várias informações confidenciais que
a pessoa do outro lado que ele está oferecendo ajuda, não tem acesso, então você poderia
tomar vantagem de xss se você escrevesse o script malecioso do lado da sua mensagem,
mandar essa mensagem e se esse aplicativo não tivesse proteção contra xss, né? Ele deixava,
mandava e armazenava no banco de dados essa mensagem, apareceria lá para o suporte e esse
cara do suporte veria a mensagem, mas não veria o script que está executando, nem dava,
nem ele nem iria se tocar que o script estaria sendo executado porque se você colocar a tag de script
lá na caixa de texto, não aparece na página, só o que aparece ao texto, não as tags,
script, então poderia rodar o script lá no background enquanto o cara estava oferecendo
suporte e esse script iria rastrear toda a estrutura da HTML, DOM que ele tem e procurar
e achar informação, né? Nesses casos você teria que saber onde é que está
as informações ou você poderia já mandar logo fazer um dump, né? De tudo e mandar para o seu
servidor malecidoso e lá você analisaria aquelas informações que foram enviadas para ver se
tem alguma informação confidável, que eu tenho certeza que tem, né? Porque é o navegador dos
representantes de suporte, ele tem acesso à informação que você não tem acesso.
Tá bom pessoal, então se você quiser se aprofundar mais aí pesquisa em xss, uma vulnerabilidade
de sites e aplicativos web. Era muito como antigamente, hoje ainda se faz se você não
não se toca, né? Mas saiba dessa vulnerabilidade e sempre tome cuidado quando você tomar entrada
de usuários e não deixe eles sempre teste, não deixe eles enviarem tags, né? Outra coisa que você
pode fazer é se eles enviaram os tags e você não tiver protegido o seu banco de dados, você pode
também rastrear, fazer uma query no seu banco de dados e procurar pelo padrão, né? Faz um regx
da tag das tags e html e vê se alguém não digitou ou armazenou a tag e você pode limpar,
não precisa de uma querida dessa maneira. Então por essa é só, até a próxima, espero que
tenham gostado dessa dica e até mais. Tchau.


001b-03 O que é XSS (Dica de Software em Áudio)

O que é REST (Dica de Software em Áudio)

O que é REST?
No inglês, representational state transfer, transferência de estado representacional.
O que é REST?
O REST é uma maneira de se escrever um API.
API Application Programming Interface.
O padrão REST é um dos mais populares hoje para se escrever um API no lado do servidor.
E quais são os pontos principais de um API REST?
Então, vamos falar disso.
Então, tem que haver uma separação entre o cliente e o servidor.
Essa separação tem que ser clara.
Outro fator é, não pode haver a existência de estado nessa transferência de servidor ao cliente.
É o conceito no inglês stateless sem estado.
Não significa que você não pode armazenar as coisas.
Claro que pode.
Coisas ficam armazenadas no banco de dados do servidor.
Mas essa transferência, essas mensagens que são trocadas, só se tem mensagem sobre o recurso.
Por exemplo, você tem uma livraria.
Então, o recurso é livro.
Então, há várias operações no livro.
A gente pode criar um recorde de um livro, pode alterar um recorde, pode delatar um recorde,
ou pode obter uma lista de todos os records.
Então, há uma operação e um recurso.
Isso diz o servidor que fazer.
Claro que dá para fazer as coisas.
Mas quem armazenar os negócios, quando o servidor pega as informações,
ele vai, ok, você quer que eu crie um recurso,
e você me deu as informações do recurso a ser criado.
E o servidor vai fazer essa operação.
Mas depois que termina essa operação do lado do servidor,
ele não vai armazenar nenhum estado para saber...
Assim, ele termina a operação, pronto, terminei.
Vou para a próxima operação, não importa quem.
Não armazenar metodia, estado nesse sentido.
Claro que a gente pode autenticar, pode autorizar e fazer tudo isso.
Mas a sessão em si própria não é armazenada no corpo, assim se dizer, da transferência.
Normalmente se usa tokens, que a gente passa no header de HTTP chamado authorization.
Então, como a gente acabou de falar de recursos,
tem essa interface que é uniforme e padrão de uma espécie de hierarquia de recursos,
que você identifica os recursos através da URL do caminho.
Por exemplo, no caso dos livros, se a gente quiser obter uma lista de livros,
a gente usaria o verbo get, o método get de HTTP, seguido do caminho barra livros.
Então, o verbo, que é get, também chamado de método, HTTP,
aqui identifica a operação de obter alguns dados.
Nesse caso, barra livros é o recurso.
Nesse caso, seria a lista de recursos no plural.
Então, o get barra livros é usado para obter uma lista de livros, de recordes de livros.
Agora, se você quiser criar um recorde de livros, em vez de obter, você muda o verbo.
Nesse caso, vai de get para post.
Então, para poder criar um livro através dessa API, você utilizaria post barra livros.
Para poder obter só um livro específico, você pode usar o verbo get, seguido do barra livros,
barra um identificador do livro.
Normalmente, o id do banco de dados, do livro, id do livro.
Isso aparece só no caminho.
Então, para poder obter informações de um certo livro específico,
o get barra livros, barra um, dois, três, por exemplo, onde um, dois, três é o id do livro.
Então, você vê uma hierarquia, lá da esquerda, o nome do recurso, barra o id específico de um recurso específico.
E esse lance de hierarquia também pode adicionar mais e mais caminhos e a coisa se torna mais específica.
Por exemplo, no exemplo do livro, eu posso pensar também de exemplo de autores.
Então, se eu quiser acessar uma lista de autores, seria o caminho get, o caminho do barra autores.
Se eu quiser um ator específico, o barra autores, o barra o id do autor.
Se eu quiser saber os livros desse autor, eu posso dizer, por exemplo, a get barra autores, barra um, dois, três,
onde um, dois, três é o id do autor, barra livros.
Nesse caso, o barra autores, barra um, dois, três, barra livros, nos daria a lista de livros que são associados ao autor.
Então, se eu fosse em um caso e seria os livros que foram escritos pelo autor,
então você vê que na hierarquia, no lado mais esquerdo, é o dono de alguma coisa, e aí fica mais específico do lado direito.
Você vê que os livros pertencem ao coisa do lado esquerdo, que é o autor.
Então, também essa hierarquia que você pode fazer mais e mais, mais e mais.
Mas, normalmente, se tiver muita, fica pesado. Normalmente, a gente tem no máximo dois níveis.
Se formar de um nível, é melhor você cortá-lo da esquerda e deixar só o que é principal mesmo.
Outro fator de uma API REST é que quando você conversa com o servidor, a API, através de REST,
no caso do REST, o cliente não precisa saber da implementação do servidor.
Ele só precisa saber da interface, das operações através da interface.
Isso é um conceito comum da media API.
Então, se o servidor usa linguagem A ou B, ou se o servidor chama outro servidor, ou chama esse banco de dados,
para isso, o cliente não importa para o cliente como o servidor vai processar as coisas.
O que importa é que eu te dou uma entrada, o servidor me dá saída.
Só isso, o cliente só vai saber disso, não vai saber de nada específico do lado do servidor, de como ele faz aquela operação.
Tá bom, pessoal?
Então, eu acho que os mais importantes para saber a separação entre cliente e servidor, você não pode manter o estado.
O estado, o status, tem também o lance de ter...
...da negócio de cache, que é para poder economizar na banda larga.
Nesse caso, tem também que ter a API REST, deve ter uma habilidade para você fazer cache.
Cache significa que se você faz o mesmo pedido para a mesma coisa, mais de uma vez,
a mesma entrada e a mesma saída, e a mesma coisa repetida, repetida, repetida,
em vez de você sempre fazer a mesma coisa, tem que ter uma maneira de fazer cache,
porque para que você não precise fazer o mesmo processamento de novo, de novo, de novo, de novo,
e você já fez uma vez e é só mandar essa resposta repetida, sem precisar gastar com o processamento novamente.
Tem também esse lance de habilidade de criar cache.
A Monta também olhamos na negócio do lance da interface uniforme, que é a hierarquia dos recursos,
esse conceito da identificação do recurso através do caminho da URL, usando um método de HTTP,
também chamado verbo, nesse caso, deixa eu te dizer de novo os verbos,
eu acho que eu esqueci de dizer o delet e o put.
Então, por exemplo, no exemplo dos livros, obter todos os livros, get, barra, livros.
Obter um livro específico, get, barra, livros, barra, ID do livro.
Criar um livro, post, barra, livros.
Deletar um livro, delet, que é o método, delet, barra, livros, barra, ID do livro.
Para poder alterar ou substituir um livro.
Put, que é o verbo, put, barra, livros, barra, ID do livro.
P, t, put, para poder criar ou substituir, nesse caso, alterar, por si como um todo.
Tem também o patch, que o patch é mais específico de você alterar, só uma parte do recurso.
Normalmente se usa mais put, mas se você quiser também pode usar patch.
Nesse caso, seria na mesma maneira de alterar, mas só uma parte específica.
Put, barra, livros, barra, ID do livro.
Patch, barra, livros, barra, ID do livro.
Certo?
Tá bom, então temos get, post, put, delete, patch, como os métodos de HTTP.
E tem o caminho, dependendo do caminho você precisa adicionar o identificador ou não.
No caso de criar um livro, não precisa de identificar o identificador.
No caso de obter todos os livros, não precisa.
Só no caso de uma coisa bem específica que você adiciona o barra, ID do recurso,
aí, imediatamente a sua esquerda no caminho.
Também olhamos o lance da abstração, que o cliente não precisa saber da implementação específica do servidor.
E um lance mais próprio terminar, também opcionar, mas não é um ponto muito...
que a gente se lembra muito não, pode também mandar a código.
O servidor pode transferir código a ser executado no cliente, por exemplo, JavaScript.
Tá bom, então, por isso é só rest, representational, state transfer,
transferência de estado representacional, uma maneira de você criar sua API,
Application Programming Interface.
É um dos métodos mais populares hoje, senão o mais popular de se escrever API,
que todo mundo, quando você vê o API, já vê que tem os lanços do recurso no caminho,
e os verbos de HTTP hoje já sabem, acho que está usando rest, deve estar usando rest.
Então, todo mundo já entende, é o padrão que familiar com muitos e permite a gente identificar API,
e já usar API de maneira bem rápida, né?
Você já sabe na hora, oh, rest, eu já sei que os verbos não são esses, os caminhos são esses,
e o deduzo que são esses devem ser esses, porque estão seguindo o padrão rest.
Então, por essa... é só, espero que tenham gostado e até a próxima.


001b-04 O que é REST (Dica de Software em Áudio)

O que é DOM (Dica de Software em Áudio)

O que é DOM?
No inglês document object model.
Model de objeto do documento.
Então quando a gente fala de DOM, né, DOM no inglês DOM, a gente só se isso ao navegador
e ao documento de HTML.
Então o DOM, document object model, é a representação dos dados do estado de um documento no navegador.
Então aquele documento HTML, que tem as tags e etc.
A gente pode representar ele através desse modelo de objeto, né, desse documento DOM.
E através do DOM, a gente pode manipular o documento.
Então basicamente isso, a gente usa o DOM para poder manipular o documento de HTML na parte do cliente.
Quando você acessa o site e você quer mudar o comportamento, manipular o documento para que se torne interativo, se torne um aplicativo e tal.
Então se você já programou JavaScript, você já usou os objetos window, janela, documento, documento.
Esses todos pertencem ao DOM, tá? Do padrão DOM.
Então o DOM tem uma especificação, né?
A instituição WOTWG que tem, que mantém esse spec, né, especificação de como o DOM, como essa interface deve ser.
E a gente tem lá no site deles, se você quiser ver, DOM.spec.wotwg.org.
DOM.sps.whtwg.org.
Entendo em mostra lá as várias coisas, as especificações.
Então os navegadores, olham para essa especificação e implementam nesse padrão.
Então você vai no Firefox, vai no Chrome, vai no Edge e você tem acesso a essas funções do DOM,
como por exemplo se você já usou document.getElementById,
document.createElement, document.querSelector, addEventListener, assim por diante.
Isso é parte da interface do DOM, né? Tudo parte do DOM.
Então de certa maneira, o DOM é como se fosse uma espécie de biblioteca no JavaScript, na parte do cliente, no navegador.
Ele já tem várias funções que a gente pode usar.
E essas funções já são disponibilizadas para a gente usar e elas são disponíveis nos navegadores de hoje, né?
A maioria segue quase o mesmo padrão, né?
Então hoje o dia está muito mais consistente nos navegadores seguiria mesmo comportamento em respecto às funções do DOM da especificação.
Então de novo, o DOM é essa interface através da qual a gente manipula o documento.
E essa interface nesse modelo de objeto composto da árvores, de árvores de nodes, né?
Nodes, né? Nodes.
E essa árvore tem os elementos de HTML que está dentro dos elementos assim por diante.
E a maneira de a gente manipular esses elementos é através das funções do DOM, né?
DocumentObjectModel.
Tá bom?
Então é isso. DocumentObjectModel, o modelo de objeto do documento, várias funções para a gente poder manipular o documento de HTML,
as páginas, os sites, os aplicativos.
Muito, muito usado, né? Você programa no frontend, você sempre está usando as funções do DOM.
Para poder manipular os elementos, as nodes, para poder lidar com eventos, né?
Você observa os eventos e faz uma coisa de acordo com o evento e todas essas coisas, né?
Então os objetos mais usados, né?
Se você é o window, tem documento, né?
E toda parte do DOM.
E tem várias, várias funções.
Tem elemento para ID do documento, create elemento documento, evento listener, query selected documento e assim por diante, tá?
Então tem várias, várias APIs através do DOM.
Então por essa só, espero que tenham gostado e até a próxima.
