Pausa para café #31. 9 erros de carreira que todo desenvolvedor deve evitar. Por que a arquitetura REST API está ganhando popularidade?

9 erros de carreira que todo desenvolvedor de software deve evitar

Fonte: Infoworld Sejamos honestos. Alguns de vocês começaram a aprender programação porque vocês ou seus pais pensaram que seria mais fácil ganhar muito dinheiro. Você não gostava muito de computadores na escola e não gostava muito de desenvolvimento de software. Se isso for verdade, significa que você sempre será um programador medíocre. Sim, você ganhará um bom dinheiro porque nossa indústria o favorece, mas este artigo não é para você. Mas se você fosse punido quando criança por desmontar eletrônicos para descobrir como eles funcionavam... Se você passasse metade da noite na Internet para aprender como criar um videogame... Se você gastasse um precioso tempo livre aprendendo sobre o que ninguém te perguntou... este artigo é para você. Você precisa mudar a percepção de sua carreira. Você não escreve mais código por diversão: você o faz por dinheiro. Para se divertir, você pode apoiar seus projetos pessoais. Mas certifique-se de pelo menos aproveitar seu trabalho diário. Caso contrário, encontre um lugar melhor, se possível. Seu objetivo deve ser abrir seu fundo de aposentadoria, investir nele todo o seu dinheiro após os impostos, comprar uma casa, um carro e fazer o que quiser. Talvez viajar. Ao mesmo tempo, você precisa pensar na sua carreira, não apenas no seu trabalho atual. Para fazer isso, você precisa evitar nove armadilhas, que discutiremos agora.

Armadilha nº 1: não permaneça em uma tecnologia por muito tempo

Eu entendo. Você gosta de C# ou Java ou JavaScript, Python ou Cobol. Mas a maioria das tecnologias tem um ciclo de vida de adoção, pico, terceirização, nicho e obsolescência. Quero dizer, se você conhecesse o Cobol na década de 1980, teria sido legal. Mas os programadores Cobol não ganham muito dinheiro atualmente. Ou seja, a questão é que conhecendo apenas uma linguagem de programação, mais cedo ou mais tarde você terá que cortar gastos, mudar para uma cidade mais barata, porque vai ganhar menos.

Armadilha nº 2: não seja um monopolista de TI

Você precisa proteger seus investimentos. Pode parecer que você só precisa se tornar um especialista nas tecnologias que atualmente dominam o mercado. Mas então você enfrentará muita concorrência. Além disso, quando a demanda por sua especialidade diminuir, você já deverá ter um plano de saída em vigor. Por exemplo, eu era um geek em C++ quando o Java foi lançado. Eu aprendi Java. Há alguns anos, todos começaram a falar sobre Ruby como a nova estrela em ascensão entre as linguagens de programação. E em algum momento parecia que Perl alcançaria o mesmo nível que Java. Prever o futuro é difícil, por isso proteger as suas apostas é a forma mais segura de garantir relevância no mercado de trabalho.

Armadilha nº 3: não se apegue às modas

Mais cedo ou mais tarde a magia desaparece. As pessoas não contratam desenvolvedores Groovy ou Ruby. Se o seu chefe permite que você use linguagens legadas em um projeto, será porque ele não se importa ou simplesmente é ignorante. Certamente, aprenda e use a tecnologia mais recente. Esteja preparado para ser um dos primeiros a saber sobre eles e se tornar um especialista no assunto. Por outro lado, esteja preparado também para fazer mudanças drásticas se a demanda pela sua especialidade diminuir. Sempre há outras novas tecnologias pelas quais se apaixonar, seja uma linguagem ou um banco de dados.

Armadilha nº 4: alergia a regras

Cada organização, não importa quão grande ou pequena, tem suas próprias regras de escritório. Você terá que estudá-los e segui-los. Caso contrário, você se tornará um peão no jogo de outra pessoa ou ficará isolado no time. Se você está interessado em uma carreira e em relacionamentos produtivos no trabalho, aprenda a seguir táticas defensivas nas regras do escritório.

Armadilha nº 5: desinteresse pelos negócios

“Sou apenas um desenvolvedor, não estou interessado em negócios.” Esta é uma estrada para lugar nenhum. Você precisa aprender a contar. Sua empresa está indo bem? Quais são seus principais objetivos de negócios? Quais são seus projetos mais importantes? Como a tecnologia ou o software ajudam a alcançá-los? Como sua empresa se enquadra no setor em geral? Se você não souber as respostas para essas perguntas, acabará trabalhando em projetos sem importância, para pessoas sem importância, em empresas sem importância, por uma quantia de dinheiro relativamente insignificante.

Armadilha nº 6: a mentalidade da “solidariedade sindical”

Quando eu era jovem, um dos meus colegas era um homem que planejava quase tudo com seis meses de antecedência. Ele cometeu o erro de sair de férias, então terminei o projeto inteiro em duas semanas, mas deixei para ele uma peça para trabalhar. Eu esperava que ele ficasse feliz com isso. Acontece que ele não estava feliz. Tudo terminou com ele aproveitando todas as oportunidades para me demitir. Este se tornou seu principal objetivo. Ele até reclamou de mim com nosso novo diretor. Claro que fiz todo o meu trabalho. Eu era um inovador. Eu estava sempre encontrando novas maneiras de fazer as coisas melhor e mais rápido e resolver problemas. Ele se aposentou logo depois que saí para outro emprego. Várias vezes o vi em um café e fingimos que não nos conhecíamos. Esta não seria a última vez que encontrei este tipo de trabalho: “Faça as coisas devagar ou as coisas vão piorar.” Meu conselho: escreva o código correto, mas esteja preparado para o inesperado. Se o problema não tiver solução, saia batendo a porta: sua empresa não é a única no mercado.

Armadilha nº 7: você não sabe o seu valor

"Não estou aqui pelo dinheiro." Pois bem, comece um hobby. Não vá trabalhar todos os dias pensando no próximo salário. Você também não deveria trabalhar se ganha 50% menos do que todos os outros. Conheça o seu valor e não o subestime.

Armadilha nº 8: tratar seu trabalho como um trabalho

"É apenas um trabalho." Não, este é um passo na sua carreira. Você não ficará neste trabalho para sempre. Então, o que você pode aprender aqui? Qual será o seu próximo passo? Onde você quer chegar? Como esse trabalho o ajudará a atingir esse objetivo? Aumente sua consciência do que está ao seu redor. Isso irá atendê-lo bem no longo prazo. Não é apenas um trabalho, é uma jornada.

Armadilha nº 9: você acha que é apenas uma questão de dinheiro

Os vendedores gostam de dizer: “Eu trabalho se você jogar uma moeda”. Sim, mas a menos que você trabalhe com vendas, ninguém quer trabalhar com alguém que está nesse emprego apenas por dinheiro. Sei que só quero trabalhar com alguém que seja responsável pelo seu trabalho. E você? Por outro lado, não há necessidade de ser insuportavelmente responsável. Se tudo o que realmente o preocupa é o eterno debate sobre abas ou lacunas, talvez seja necessário tomar um sedativo.

Por que a arquitetura REST API está ganhando popularidade?

Fonte: DZone A comunicação instantânea é algo incrível. Estamos todos acostumados com o fato de podermos nos comunicar instantaneamente com qualquer lugar do mundo. Em computadores desktop ou dispositivos móveis, podemos comprar, postar, anexar e selecionar qualquer coisa, em qualquer lugar. Estamos conectados uns aos outros e ao mundo como nunca antes. Mas como isso acontece? Como os dados chegam até nós “de lá”? Dispositivos e aplicativos se comunicam entre si usando uma interface de programação de aplicativos ou API. Este é exatamente o motor “sob o capô”. Está sempre nos bastidores e tendemos a pensar nisso como algo comum, mas é a API que cria toda a interatividade com a qual contamos.

O que é uma API?

Simplificando, uma API é um mensageiro que aceita solicitações, informa ao sistema o que você deseja fazer e depois retorna uma resposta para você. Para um exemplo visual, imagine a API como um garçom em um restaurante. Imagine que você está sentado à mesa, segurando um cardápio nas mãos, e a cozinha faz parte do sistema que irá preparar seu pedido. A API é o link que vai transmitir seu pedido para a cozinha e entregar a comida na mesa.

Vejamos um exemplo real:

Todos conhecemos o processo de pesquisa de voos online e sabemos que para reservar um voo teremos que interagir com o site da companhia aérea. Você acessa o banco de dados deles para ver se os assentos estão disponíveis em uma data específica e quais custos você pode esperar com base nas necessidades do seu voo. Mas e se você não usar o site de uma companhia aérea que tenha acesso direto às informações? E se você usar um serviço de reservas online que coleta informações de diferentes companhias aéreas? O serviço interage com a API da companhia aérea, onde a API é a interface que, assim como nosso prestativo garçom, solicita informações do serviço online sobre reservas de assentos e a escolha de refeição ou preferência de bagagem do passageiro. A API então pega a resposta da companhia aérea e a devolve ao serviço online, que exibe as informações ao passageiro. Praticamente o mesmo processo ocorre entre todos os outros aplicativos, dados e dispositivos. Todos eles têm APIs que permitem que os computadores os controlem e, em última análise, isso cria comunicação.

Que tipos de APIs existem?

A arquitetura de API pode ser implementada de duas maneiras principais: uma dessas formas de implementar a transferência de informações é SOAP, e a outra forma principal é REST. Já estabelecemos que as APIs fornecem comunicação entre dois aplicativos. Agora aprenderemos exatamente como o SOAP e o REST se encaixam na arquitetura de comunicação.

API SOAP

SOAP (Simple Object Access Protocol) é um serviço web que segue especificações com certos princípios de comunicação que são estabelecidos entre um órgão central chamado W3C e um conjunto básico de especificações. Este conjunto inclui:

• SABÃO
• WSDL
• UDDI

SOAP é um protocolo que define como dois aplicativos se comunicarão entre si. Dois aplicativos devem seguir um formato comum ao se comunicarem, e esse formato comum deve ser baseado na linguagem XML. O XML nas APIs SOAP deve estar em conformidade com o padrão de mensagem SOAP, que consiste em Envelope, Cabeçalho e Corpo.

API REST

Este é um conceito de serviços da web muito importante, mas muitas vezes mal compreendido, então vamos decifrar o que significa REST ou API RESTful. REST é um serviço web que inicia a comunicação entre duas aplicações usando seus próprios princípios de arquitetura. A arquitetura REST é um estilo arquitetônico que não segue nenhum protocolo, não existem especificações rígidas e não existe uma autoridade central que controle as especificações. Isso torna o REST versátil para usar ou criar qualquer tipo de serviço. Quando esses princípios são aplicados ao criar um serviço web, obtemos um serviço web RESTful. Agora vamos nos aprofundar um pouco mais e descobrir os princípios nos quais a arquitetura REST se baseia.

Interface Unificada

Numa arquitetura RESTful, tudo pode ser considerado um recurso. Por exemplo, se você estiver tentando criar um aplicativo para um sistema de gerenciamento de funcionários. Esta aplicação pode ser desenvolvida em qualquer linguagem, em qualquer plataforma e para qualquer plataforma. Da mesma forma, qualquer banco de dados pode ser usado para lidar com serviços internos. O conceito de recursos na API REST implica que o usuário pode definir qualquer informação ou qualquer módulo como recurso. Dado um sistema de gestão de funcionários, o criador pode definir os recursos de funcionários, departamentos e qualquer outro módulo utilizado na aplicação.

Apátrida

Em uma arquitetura RESTful, todas as respostas e solicitações, e toda a comunicação entre servidores, são sem estado. Isso significa que o servidor não mantém o estado atual do sistema, o cliente pode enviar uma solicitação que é concluída. E este pedido não depende de nenhum dos pedidos anteriores. Por exemplo, se você estiver comprando on-line e adicionando itens ao carrinho, o servidor não manterá o estado do seu carrinho, portanto, toda vez que um usuário enviar uma solicitação ao servidor, ela conterá o estado do carrinho no momento em que o pedido foi enviado. pedido foi feito. Quando sem estado, não há sobrecarga para o servidor armazenar ou manter a sessão, melhorando assim o desempenho do serviço web.

Capacidade de cache

No último protocolo, notamos que na arquitetura RESTful o servidor não salva o estado da sessão, todo o cache acontece no lado do cliente. Sempre que um cliente envia uma solicitação ao servidor, o servidor retorna uma resposta que contém os dados reais, bem como outros metadados que informam ao cliente se ele deve armazenar a resposta localmente ou não.

Sistema multinível

Os princípios REST afirmam que sempre que houver comunicação entre um cliente e um servidor, pode haver várias camadas entre eles, e essas camadas podem ser usadas para implementar vários propósitos, como tradução de mensagens, melhoria de desempenho, armazenamento em cache e uma variedade de outras coisas. Cada nível de comunicação tem uma tarefa específica. Com múltiplas camadas de comunicação, o sistema opera de forma eficiente, melhorando a velocidade e a durabilidade.

Código a pedido

Esta é uma limitação opcional dos serviços web RESTful que funciona quando o usuário envia uma solicitação para receber uma resposta. A resposta pode executar código do lado do cliente. Este princípio expande a funcionalidade da comunicação.

Por que as APIs REST estão sendo usadas cada vez com mais frequência?

REST é geralmente mais fácil de usar, mais flexível e tem diversas vantagens sobre SOAP. Por exemplo, você não precisa de ferramentas caras para interagir com qualquer serviço web. A arquitetura REST é mais simples, pode ser facilmente customizada e não requer habilidades especiais na criação de um modelo de comunicação. É eficiente de usar porque pode usar o lado cliente do servidor para armazenar informações relacionadas ao cliente. REST usa formatos de mensagens menores e fornece interações mais rápidas porque não requer processamento demorado. REST também está mais próximo de outras tecnologias web quando se trata de filosofia de design.

SOAP ou REST?

Para os requisitos de uma aplicação web típica, o SOAP costuma ser um exagero. REST é uma solução mais simples que tem tudo que você precisa quando um aplicativo web precisa de uma API. Porém, há momentos em que a API precisa ser um pouco mais complexa para realizar tarefas. Por exemplo, se uma API for necessária para solicitações automatizadas, uma API SOAP seria uma escolha melhor para esse cenário. Simplificando, escolha SOAP se o problema for grande e complexo e escolha REST se precisar de uma solução simples.