DEV Community: Jéssica Félix

O básico de APIs RESTful parte 2 - o ful do RESTful , request, recurso e representação

Jéssica Félix — Mon, 04 Jan 2021 10:48:39 +0000

Texto das anotações sobre o que que estudei e vi no trabalho, continuação da série sobre API RESTful.

RESTful

O que é API RESTful?

Quando um serviço REST é executado na web sobre HTTP para nos dar acesso a um recurso da web, o chamamos de API RESTful.

Se enviarmos uma solicitação por meio de HTTP para um serviço REST que atenda às seis restrições (mencionei elas na parte 1), esse serviço será uma API RESTful.

Nem todas as APIs REST usam o protocolo HTTP mas as APIs RESTful usam.

O que uma API REST faz?

O trabalho da API REST é receber solicitações, processar dados e enviar respostas.

Ela fornece uma interface para que um conjunto de dados seja consumido por qualquer cliente que siga as regras (o próprio site, aplicativos ou dispositivo IoT).

Qualquer cliente pode acessar qualquer API?

APIs REST tem limites (e se ainda não tem, precisam se adequar imediatamente, por segurança) sobre quais recursos podem ser acessados, que clientes pode acessar o que e quantidade de solicitações que podem ser feitas em um determinado período de tempo.

Como posso testar se um recurso de uma API REST funciona, ver seu retorno e etc?

Você vai precisar de ferramentas na sua máquina como o Insomnia ou Postman. Dependendo da IDE que você utiliza, pode encontrar algum client para usar nela mesma. Se assim como eu, você usa VS Code, é possível baixar uma extensão de REST client.
Neste site tem uma lista dos 20 melhores clients, entre gratuitos e pagos.

Request

O que é uma request?

Uma solicitação REST tem duas partes: um método e um URI.

Método - GET, POST, PUT, DELETE, OPTIONS ou outro verbo.

URI - aponta para o recurso que desejamos interagir.
Também podemos enviar metadados no cabeçalho da solicitação.

Além disso, a solicitação pode ficar mais complexa e também precisaremos enviar os dados que queremos modificar (caso de solicitações com métodos POST, PATCH e PUT, por exemplo, que também enviam um body e headers) e o tipo do conteúdo (JSON, por exemplo).

Recurso

Qualquer informação que possa ser nomeada pode ser um recurso(1).
Um recurso é um mapeamento conceitual para um conjunto de entidades. Recursos podem retornar listas de objetos ou um único objeto.

Por exemplo, “clientes” é um recurso de coleção e “cliente” é um recurso singleton (em um domínio bancário). Podemos identificar o recurso de coleta de “clientes” usando o URN “/clientes”. Podemos identificar um único recurso de “cliente” usando o URN “/customers /{customerId}”.(1)

O recurso é qualquer dado que esteja no local para o qual estamos apontando.

Representação

Representação é a representação literal dos dados que obtemos quando acessamos esse recurso.

No retorno da solicitação não acessamos os dados reais, acessamos uma representação destes. Por isso, um recurso REST pode fornecer os mesmos dados a vários clientes, ao mesmo tempo, assim como pode fornecer diferentes variantes desses dados a clientes diferentes mediante solicitação.

Referências

(1)Architectural Styles and
the Design of Network-based Software Architectures - Roy Fielding, 2000

(2)REST API Design Resource Modeling - Prakash Subramaniam, 2014

Outras referências:

Curso online "Learning REST APIs" - Morten Rand-Hendriksen

Livro "Essentials of RESTful Web Services,Java, Spring Boot, Spring MVC and JPA: Top 100 real life project scenarios and tips" - Pagebuzzes Publications

O básico de APIs RESTful parte 1 - definições e restrições

Jéssica Félix — Wed, 30 Dec 2020 19:42:22 +0000

Estou escrevendo esta série enquanto me aprofundo em desenvolvimento de APIs.
Já trabalho com APIs faz quase dois anos mas, sinto que muita coisa não ficou muito consolidada na minha mente. Portanto, vou compartilhando aqui para me ajudar a fixar - e porque talvez possa ser útil para alguém.

Adianto que não me responsabilizo por boa didática. Provavelmente vocês vão encontrar texto muito mais didáticos ou até mesmo, vão ter sugestões de abordagens melhores para o tema. Neste caso, encorajo vocês a escreverem seus artigos que eu os divulgarei com muito prazer <3.
O meu texto vai ser isso aqui mesmo.
No mais, fico a disposição nos comentários.

API RESTful - parte 1

Em resumo, como uma API RESTful funciona?

O cliente faz a solicitação, a API REST recebe a solicitação, coleta e analisa os dados e retorna esses dados e o cabeçalho de resposta ao cliente.

O que significa API REST?

REST e API são acrônimos para Representational State Transfer e Application Programming Interface.

O que é REST?

REST refere-se a um grupo de restrições de design de arquitetura de software que geram sistemas eficientes, confiáveis e escaláveis.

A Transferência de Estado Representacional é uma descrição literal do que acontece: transição entre representações de estados e essas representações sendo transferidas entre o aplicativo e o servidor.

Todas essas idas e vindas são controladas por meio de uma interface de programação de aplicativo - a API.

Lembrando que este estado representacional é transferido como um objeto de dados, não como um novo conjunto de arquivos.

O que é API?

Conjunto de recursos e regras que existem dentro de um programa de software, permitindo a interação entre o software e outros itens, como outro software ou hardware.

No contexto das APIs REST, a API é a coleção de ferramentas usadas para acessar e trabalhar com recursos REST por meio de seus verbos, como GET, PULL, PUT e DELETE.

Analogia para fixar:

Você pode pensar no recurso REST como uma bibliotecária e a API como a forma de solicitar um livro (o que você precisa passar para a bibliotecária te entregar aquilo que necessita? O que precisa: colocar um novo livro na biblioteca? Solicitar os mais recentes? Tirar um livro permanentemente?).

Que mais preciso saber?

URI

O URI - Identificador de Recurso Universal - é descrito como uma "seqüência compacta de caracteres", é o método mais genérico para nomear e localizar um recurso da web.

URL

O URL - Universal Resource Locator - não apenas identifica um recurso, mas também explica como acessar esse recurso, fornecendo um método explícito como HTTP ou FTP.

Todos os URLs são URIs, mas nem todos os URIs são URLs.

URN

O URN - Universal Resource Name - se refere a ambos os URIs e a qualquer outro com as propriedades de um nome.

Analogia:

A diferença entre um URN e um URL é dizer que o URN é um identificador de nome exclusivo, como o nome completo de uma pessoa, enquanto a URL fornece a localização física real.

Para lembrar:

URL também pode ser um URN e ambos são URIs.

As 6 Restrições em REST

Arquitetura cliente-servidor

Garante a separação adequada entre o conteúdo e sua apresentação e interação.

O cliente gerencia as questões da interface do usuário, enquanto o servidor gerencia as questões de armazenamento de dados.

Não guardar estados

Nenhum contexto ou informação do cliente (estado) pode ser armazenado no servidor entre as solicitações.

Se o estado de sessão do cliente for relevante, ele deve ser enviado junto com uma solicitação.

Se o servidor precisar armazenar esse estado, ele deve passá-lo para um banco de dados ou serviço semelhante por um tempo específico.

O "estado" é o que determina 'onde' o usuário está no processo de conclusão de uma tarefa(1).

Capacidade de armazenamento em cache

Armazenar em cache respostas que não mudarão ou provavelmente não sofrerão alterações, as alteradas raramente ou periodicamente por períodos de tempo razoáveis e bloquear o cache para respostas em constante mudança.

Sistema em camadas

O sistema deve ser projetado de forma que o cliente não saiba e não se importe se está conectado diretamente ao servidor ou a um intermediário.

Código sob demanda

Os servidores têm permissão para transferir código executável na forma de JavaScript do lado do cliente e para transferencia de componentes compilados, com o objetivo de estender e personalizar a funcionalidade.

Interface uniforme

Se divide em mais quatro restrições, portanto, não é realmente uma única restrição, mas apenas mais quatro restrições:

O que REST retorna é uma representação do recurso, que pode ter um formato diferente do recurso no servidor. Exemplo: Dados armazenados como uma tabela no banco, mas representação de retorno pode ser JSON, XML ou HTML;
O cliente com o nível de acesso correto pode controlar o que está armazenado no servidor;
Cada representação deve descrever seu próprio formato de dados;
O serviço REST descreve seu próprio uso com cada recurso retornado, por meio dos hiperlinks fornecidos.

A API só é REST se atender a estas restrições, lembrando que a restrição de código por demanda é considerada por alguns autores como opcional.

Referências:
(1)Hypermedia in RESTful applications - Mark Baker, 2008

Outras referências:

Curso online "Learning REST APIs" - Morten Rand-Hendriksen

Livro "Essentials of RESTful Web Services,Java, Spring Boot, Spring MVC and JPA: Top 100 real life project scenarios and tips" - Pagebuzzes Publications

Quanto tempo eu vou demorar até entrar na área de t.i.?

Jéssica Félix — Wed, 26 Feb 2020 12:30:17 +0000

Já ouvimos/lemos essa pergunta várias vezes, mas minha questão é: estamos falando a realidade ou estamos só querendo "animar" a pessoa?

É bem legal dizer para alguém que, em seis meses de estudo, ela já consegue arrumar um emprego na área de tecnologia, né? Mas, neste caso, estamos fazendo igual ao medico que não nos examina e diz que o diagnóstico é virose.

Responder essa pergunta de quanto tempo alguém demora para estar apta e conseguir um emprego é um eterno "depende". Vou elencar algumas perguntas que acredito ajudar nessa orientação:

1 - Você tem acesso a computador e internet?

2 - Quanto tempo por semana você tem disponível para estudar?

3 - Como é o mercado de t.i. na região que você mora?

4 - Qual a remuneração mínima que você precisa para viver?

5 - Qual método de estudo funciona melhor com você? Online, Presencial, sozinho, em turma?

6 - Você se sente a vontade usando um computador?

7 - Consegue separar dinheiro para investir em curso?

8 - Como você lida com frustrações?

E podemos desenhar mais perguntas, inclusive. Mas meu ponto é: são muitas variáveis!

Ai você vai dizer assim pra mim: "ah, mas você tá colocando impecilhos, se eu tivesse pensando em tudo isso, não tinha nem começado. É tudo questão de ter força de vontade". Desculpem pelo exemplo, mas, mudar de area/aprender a programar não é igual cagar, que a gente só faz força e sai. Toda mudança exige tempo e tem muita coisa envolvida.

A expectativa falsa e mal fundamentada que a gente planta nos outros, floresce como frustração amanhã. Na primeira dificuldade, começam a pensar coisas como:
" eu não sirvo pra isso, não consegui emprego em 6 meses", " não sei nada", "tenho insegurança".

Portanto,acredito que dizer um número solto pra alguém não ajuda, na maioria dos casos. Nos casos onde as pessoas querem um numero de todo jeito, ao menos para ter uma ideia, eu falo de acordo com a média das pessoas que já conversei (sempre de 1 ano e meio há 4), mas sempre acho melhor alinhar expectativas e ajuda-la a montar um plano de estudos, por exemplo.

Ainda sobre o tempo, eu prefiro dar uma estimativa mais conservadora e com base no tempo de duração de curso técnico, tecnólogo e faculdade, até porque, eu sou dev, não sou professora e nem estudo processo de aprendizado, então, prefiro usar a régua de quem entende do que colocar todas as pessoas na minha régua.

Mas porque preciso de tanto tempo?
Listei as coisas principais para alguém que começa do zero (de verdade):

Comandos básicos de um computador;
Básico de um sistema operacional (sistema de pastas, instalação de programas, gestão de recursos computacionais);
Fazer pesquisas na internet;
Conceitos básicos de lógica;
Muita, mas muita prática;
Paradigma de programação procedural e de Orientação a Objeto;
Estrutura de um projeto (seja frontend ou backend);
Conhecimentos de infra básica;
Uso recorrente de ferramenta de versionamento;
Começar com uma linguagem;

É bastante coisa né?

E isso é o básico do básico, ainda tem muito mais coisas "básicas" e todas muito importantes. Diria que a parte da linguagem de programação é a mais rápida, em comparação a toda preparação que fazemos antes. Então, não se cobrem em aprender algo que vocês nunca viram na vida, em apenas 3 meses.

Procure aprender de forma sólida e sustentável, criando uma boa base. Embora o começo seja mais chatinho, quanto mais sólido ele for, lá na frente você vai sofrer menos (palavras de quem sofreu muito por desdenhar o básico)

Para encerrar, o mais importante em qualquer processo de mudança: aprender a lidar com frustrações. Até porque, esta será uma constante na vida.

Sou mulher, hackathon é pra mim?

Jéssica Félix — Wed, 12 Feb 2020 02:28:56 +0000

Acho que você já imagina o que eu vou dizer que sim, mas hoje queria ir mais fundo do que apenas dizer que vai dar tudo certo, quero te contar as partes boas e a parte que ninguém te conta.

Também quero te dar dicas que usei na prática durante um ano indo em hackathons todo mês, muitas vezes mais de um por mês e em outros estados. Já participei como participante, mentora, jurada e organizadora.

Hackathon é pra você sim, e pra quem mais quiser também. Nem por um minuto acredite que é um esporte de performance ou algo só para um X público. Porém, procure pesquisar muito bem em qual está se inscrevendo para não passar por situações desconfortáveis.

Já vi muita participante chorar no meu ombro de stress. Porém, já vi muita participante se descobrir como dev ali dentro, conseguir emprego, mudar de cidade, ganhar prêmio, vencer sua síndrome do impostor...não tem como traçar uma regra do tipo "é bom/é ruim". Depende! E dar informação é a melhor forma de ajudar alguém a entender e fundamentar sua decisão.

Como escolher quais devo me inscrever?

É repetitivo dizer que você precisa ler o regulamento, isso você já sabe. Te sugiro ir um pouco além: quem é a empresa ou pessoa que está organizando? Qual o comportamento dela nas redes sociais? Já fizeram outros hackathons? Veja as fotos e entenda se o padrão de equipe que você vê ali é diverso, não apenas de mulheres.

Também dê uma olhada nas empresas patrocinadoras e os e parceiros - são empresas que você concorda com a conduta? Por que elas também influenciam no ambiente que você vai encontrar.

Como me inscrever?

Você vai encontrar um formulário cheio de perguntas - algumas que você pode interpretar com intimidadoras - e nessa hora, pode te dar a sensação de que hackathon é algo avançado demais para o seu nível de conhecimento. Gostaria de te dizer que, justamente por isso, você deveria se dar uma chance e participar. O primeiro evento que participei eu não sabia nem usar Github, mas consegui colaborar com a equipe de outras maneiras e sai de lá com um projeto, aliás, meu primeiro projeto.

Porém, vou ser bem honesta com você: nem toda equipe gosta de quem vem "zerada", portanto, não tenha medo de explicar que você realmente está aprendendo, isso inclusive vai evitar que você fique chateada durante o evento, caso entre em uma equipe extremamente competitiva que vai te exigir o que você não sabe.

Ah, sobre a inscrição: mesmo que você esteja começando, jamais escreva algo de duas linhas ou menos na parte de falar sobre si. Está aprendendo? Escreva o nome das tecnologias que esta aprendendo e as que você quer aprender. Não trabalha na área? Não se preocupe, isso não é vergonha e nao faz de você uma pessoa menos qualificada, todo mundo tem um início e, no primeiro hackathon que participei, eu também não trabalhava como desenvolvedora. Se dedique a escrever pelo menos um parágrafo grandinho, heim? Fale sobre você, inclusive!

Como vai ser durante o evento? Quais desafios técnicos eu vou enfrentar?

O primeiro desafio e, eu considero este o maior de todos, é a comunicação. Prepare-se para defender seu ponto de vista, discordar, pedir para te explicarem novamente, dizer para esperar você terminar de falar...e nao estou dizendo que isso vai acontecer apenas em times com homens, porque já passei por isso em times apenas de mulheres também.

Existem equipes que se dão super bem, se ouvem, se entendem, mas eu seria muito desonesta com você se dissesse que todas são assim. Existem equipes difíceis, ou pessoas difíceis. Mas isso não deve ser um impedimento, sabe porquê? A vida é cheia de pessoas difíceis: trabalho, escola, comunidade...e essa é uma boa oportunidade pra você procurar aprender com isso, ou pelo menos se dar uma chance de aprender.

Mas você jamais deve aceitar que te tratem mal nem engolir birra de gente mimada: exponha sua opinião e seja firme! Você pode não precisar fazer isso, mas esteja emocionalmente preparada caso precise. Não se esqueça que vai lidar com pessoas desconhecidas em ambiente sobre certa pressão. Mas não demonize o evento: você pode encontrar equipes e pessoas que vai levar pra vida!

Sobre a parte mais técnica, procure entender junto com o seu time qual a funcionalidade que vai agregar mais valor e trabalhe primeiro nela. No mais, não fique paranoica com o seu trabalho: primeiro faça funcionar, teste e, depois, ai você procura deixar "bonito".

Vou ficar sem dormir?

De verdade, não tem necessidade, digo de experiência própria. Ainda mais se isso for algo desconfortável pra você. Se preferir, procure hackathons online pra começar, pois neles você tem mais tempo para trabalhar e não compromete um fim de semana inteiro.

O que pode acontecer é o projeto do seu time atrasar porque vocês demoraram pra fechar a ideia e precisarem correr com o desenvolvimento, deixando todos bem pressionados com o tempo. Por isso,fiquem atentos com horário e, caso surjam dificuldades, peçam para uma pessoa mentora intervir e ajudar. Não espere chegar na última hora pra isso.

Porém, se você se sente à vontade pra ficar sem dormir e isso não vai te prejudicar, viva a experiência completa. Muita gente gosta da adrenalina e pode ser divertido :D Mas faça apenas se estiver com vontade, não por pressão de alguém.

E se alguém me tratar mal?

Para se prevenir de passar situações ruins, verifique se o evento possui código de conduta bem visível e que realmente o colocam para funcionar. Na dúvida se você deve se inscrever ou não, pergunte para outras mulheres nas suas redes sociais ou em grupos de mulheres na tecnologia sobre como a empresa organizadora é e se alguém já teve alguma experiência ruim, como a organização agiu.

Durante o evento, procure alguém da organização, não se cale! Não guarde pra você e nem fique com medo. As pessoas vão te acolher, se realmente seguirem o código de conduta.
Caso a organização não tome providências e não procure te acolher, não se sinta na obrigação de permanecer num evento que faz descaso de algo tão importante quanto lugar seguro.

E se eu não ganhar?

É muito bacana ganhar prêmio e tudo mais, porém, sendo bem honesta, é muito melhor se você sair de lá com uma boa oportunidade, projeto ou aprendizado.

Eu sempre fui visando construir meu nome como dev, vencer estava em segundo plano e nunca me arrependi de ser assim. Como consequência, as equipes que participei ganharam 4 dos 5 hackathons que fui como participante. Então, procure se focar em criar um bom projeto, fazer um bom código, fazer contatos, conversar bem com as pessoas, fazer um bom trabalho em equipe e se destacar sem apagar as outras pessoas.

O que eu faço agora que o hackathon acabou?

Muitas equipes deixam a ideia morrer, mesmo que ganhem. Isso acontece por uma série de fatores, porém, não quer dizer que seja regra. Não tem problema nenhum se você não quiser continuar o projeto, mas fique de olho para saber quais serão os próximos passos, se a empresa que patrocinou o evento está interessada na ideia ou algo assim. No mais, faça um texto bem bonito para contar a sua rede do grande evento! Lembre-se sempre de evitar o excesso de "eu" no texto,não esqueça que você chegou lá com ajuda de um time :)

E atenção: saiba a hora de parar

Tem gente que vai se divertir, tem gente que vai pra aprender...mas independente do seu proprósito ali, cuidado para não exagerar. Você não precisa ir em todos, vá apenas nos que te façam sentido. Não esqueça que você tem uma vida, saúde (principalmente!), seu trabalho e seus estudos. O hackathon é um complemento pra tudo isso, então,participe de uma forma saudável e sustentável pra você mesma ♥️

Gostou? Tenho alguns materiais de apoio para esse assunto. Espero que de agora pra frente, você tenha descoberto o que é hackathon, se faz sentido pra você - se não fizer, tá tudo bem - e que você perceba que lá é nosso lugar também ♥️

Como criar uma descrição para inscrição em hackathons (e redações de ‘quem sou eu’)

Como montar boas equipes para hackathons

O que é um hackathon?*

Dicas para hackathons (vídeo)

10 serviços AWS que todo dev precisa conhecer

Jéssica Félix — Tue, 04 Feb 2020 00:40:20 +0000

Você é dev, tem vontade de conhecer os serviços AWS, mas fica intimidada com 161 serviços e não faz ideia por onde começar?

Fiz uma lista dos 10 serviços que eu considero indispensáveis para Devs que querem começar a aprender AWS :)
Além de ser um diferencial real para o seu currículo, ainda vai te trazer muita agilidade no dia a dia.

Escrevo esse texto com base no que eu estou usando e testando (ou seja, eu conheço os serviços que estou indicando, trabalho usando eles diariamente).

A ideia é te dar um overview dos serviços de um jeito bem simples e objetivo, assim você já fica mais confortável para procurar curso e documentação ou, até mesmo, só pra matar curiosidade sobre o que as ferramentas fazem - sem precisar ler toda a documentação para descobrir.

Vou separar os serviços de acordo com sessões que estão hoje no console AWS:

Segurança, Identidade e Conformidade

1-IAM : Ferramenta de autorização, fornece os meios para acesso e restrição de diferentes serviços. Usando o IAM, você pode permitir que uma função Lambda acesse seu bucket S3.

2- Cognito: Ferramenta de autenticação, autorização e gerenciamento de usuários para os seus aplicativos. Criar grupos de usuário e de identidade são muito úteis para apps com diferentes tipo de usuários.
Você também consegue criar login com redes sociais de um jeito bem rápido.

Armazenamento

3 - S3: Serviço de armazenamento de objetos em recursos chamados "buckets". Oferece um jeito simples de armazenar e recuperar qualquer volume de dados de qualquer parte da web.

Banco de Dados

4- DynamoDB: Serviço de banco de dados NoSQL. Útil para aplicações que precisam de latência constante e compatível com modelos de armazenamento de documentos e de chave-valor.

Computação

5 - Lambda: Plataforma serveless que executa funções de código, sem que nós precisemos nos preocupar com configuração de servidor. Nos oferece agilidade em projetos com arquitetura de microserviços.

6 -Elastic Beanstalk: Serviço de deploy que ajuda a implantar e dimensionar aplicativos e serviços da web. Administra automaticamente implantação do provisionamento da capacidade, do balanceamento de carga, do Auto Scaling e do monitoramento da integridade do aplicativo.

Integração de Aplicativos

7-SQS: Serviço de filas de mensagens que permite desacoplamento e a escalabilidade de micro serviços, sistemas distribuídos e outros.
Envia, armazena e recebe msgs entre componentes em qualquer volume, sem precisar que outros serviços estejam disponíveis.

8 - SNS: Serviço de envio de mensagens de publicação/assinatura. Nos permite enviar mensagens para um grande número de endpoints de assinantes para processamento em paralelo. Pode ser usado para enviar notificações para usuários finais usando push para celular, SMS e e-mail.

Gerenciamento e Governança

9- Cloud Formation: Serviço de modelagem e configuração de recursos, com base no modelo que criarmos para modelar nossa infraestrutura. Assim, criamos uma coleção de recursos relacionados da AWS, provisionando e atualizando esses recursos.

10 -CloudWatch: Serviço de monitoramento de recursos. Ajuda gerenciamento, nos permitindo criar alarmes e ações automatizadas, nos ajudando a manter a integridade do sistema e ter alerta de custos dos recursos.

Bonus

Como complemento, quero sugerir a leitura de um artigo bem honesto sobre o tema,o"13 coisas que aprendi em um ano usando Serverless em produção"
e um artigo recomendado pelo Ramon H. Ornelas sobre Cold Start.

Tem algum serviço que você sentiu falta? Complementos são super bem vindos!Aqui, eu anotei os mais recorrentes no meu uso e nos cursos que procurei. Reforçando que é melhor conhecer bem 4 ou 5 serviços do que se desesperar para aprender todos os 161 em um fim de semana. #vaicomcalma

Ah, não deixa de olhar a sessão "Ferramentas do Desenvolvedor" da AWS que tem mais coisas úteis por lá!

Viu como AWS não é tão distante da nossa realidade? Depois,me conta se você avançou nos estudos de algum destes serviços :D