3. Java 8 - Interface
● Adicionados métodos default e static nas interfaces, até então, interfaces
não podiam ter métodos com ação (código) no seu corpo.
● Static não podem ser sobrescritos e são acessados pelo nome da interface.
● Default podem ser acessados por instâncias de classes que implementam a
interface e podem ser sobrescritos.
● Default foram adicionados para incluir métodos em interfaces sem quebrar
suas implementações
● Optional
5. Java 8 - Expressões lambda
● Expressões lambda são expressões que lembram o paradigma funcional,
onde temos funções que fazem o nosso processamento, facilitam a
legibilidade do código
● Podem ser aplicadas em tudo que for uma interface funcional, ou seja,
aquelas que possuem apenas um método, assim como a Runnable, que tem
apenas o método run
● Ao fazer um foreach do Java8, também podemos fazer uso de lambdas
para alguma ação relacionada ao objeto
● Method reference
7. Java 8 - Stream API
● Interface criada para suportar novas operações em Listas usando técnicas
de programação funcional
● Coleta todos os dados da lista para trabalhar de forma mais dinâmica e
fluída
● É recheada de métodos como filter, map, collect, count, ifpresent
● É possível fazer fazer várias operações como cálculos, coletar dados, filtrar
os dados que tu precisa, fazer sort. Tudo de maneira mais fluída
● Alguns métodos retornam Optional para evitar null pointer
10. Java 9 - Private interface methods
● Métodos de interfaces que tem corpo (comportamento) e que são privados
a interface
● Muito usados quando a interface tem métodos que precisam compartilhar
algum recurso ou fazem coisas iguais
● É criado então um método privado e todos os outros chamam esse método
quando necessário
12. Java 9 - Immutable set
● Java 9 nos trás também a possibilidade de criar um Set imutável com o uso
de set.of()
● Ao tentar remover ou adicionar valores após a criação, é lançada uma
UnsupportedOperationException
● É permitido alterar os valores dentro de um objeto já guardado no set
● Valores nulos não podem ser adicionados
15. Java 10 - inferência de tipos
● Foi adicionada a inferência de tipos, assim com é utilizado no JavaScript
● Para tal, devemos usar a palavra var. Exemplo, var test = List.of("one test", "two tests", "three
tests");
● Podemos receber um objeto ou métodos nessa variável
● Só pode ser usada para variáveis locais com inicializadores
● Devemos usar com cautela pois pode ficar difícil de ler ao termos muitas
variáveis assim
● Podemos usar para receber retorno de métodos mas não como tipo de
método e nem como parâmetros
17. Java 10 - orElseThrow() method
● Adicionado o método orElsethrow() à classe Optional
● Permite lançar exception direto na utilização do método
● Mais um método para puxar um pouco de programação funcional
20. Java 11 - padronização http
● Novo pacote java.net lançado
● Padroniza o cliente http para fazer requests que suporta requisições
síncronas e assíncronas
● Temos request, bodyPublisher para requisições que tem um corpo,
response para gerenciar respostas, interface funcional bodyhandler
● Utiliza o pattern builder na criação de clientes e requests
● Permite realizar as operações com suporte a novas features como http 2
sem precisar de dependências
23. Java 11 - var como parâmetros em lambda
● Agora é possível usar variáveis var como parâmetros em expressões
lambda, mas com algumas proibições
● Não podemos usar um var para vários parâmetros na mesma expressão
● Não podemos misturar var com tipos explícitos
26. Http - conceito
● HyperText transfer protocol
● Responsável pelo transporte dos dados, sejam eles frutos de requisições ou
respostas
● Desenvolvido para comunicação entre servidores web e navegadores web
● É stateless, não mantém dados
● Normalmente é usado com tcp/ip mas pode ser usado com qualquer
camada de transporte, como udp
27. Http - funcionamento
● É baseado em requisição e resposta
● Alguém faz uma requisição de alguma informação e outro alguém responde
com outra informação
● A isso damos o nome de request e response, respectivamente
● Como atores dessa comunicação temos o cliente, o servidor e o proxy
● Cliente (user-agent)
○ É quem faz solicitação, pode ser um navegador, uma máquina conectada a internet, o
software de atualização de um celular e por aí vai
28. Http - funcionamento
● Servidor
○ É quem responde a essas solicitações quando necessário
● Proxy
○ É o representante da conexão quando necessário e configurado
○ Ele é quem recebe e requisição e acaba transmitindo a quem realmente precisa receber
aquele requisição
○ Esse roteamento acontece muito quando trabalhamos com balanceamento de carga
utilizando proxy
● Toda essa troca é feita por uma “conversa” entre as parte, essa conversa é
dividida em duas partes básicas, cabeçalho e corpo
29. Http - Cabeçalho (header)
● O cabeçalho é um conjunto de informações adicionais à requisição
● Podem especificar que tipo de dado é aceito ou que é enviado, especificar o
tipo de caracteres e muito mais
● É composto por nome e valor (parecido com o map que é chave e valor)
○ O nome é case-insensitive seguido de : (dois pontos) e seu valor, sem quebra de linhas
○ Podemos usar nomes personalizados e outros padronizados
○ Personalizados são usados com um X- antes do nome, mas isso está depreciado por
causar alguns problemas
● Aqui podemos encontrar a maioria dos message headers que existem, fora
os personalizados
30. Http - Cabeçalho (header)
● Os message Headers mais comumente vistos são
○ Accept que dizem qual é o tipo de documento que aceitamos, em qual idioma, qual a
codificação de caracteres
○ Authentication para informar login e senha, quando necessários
○ Content-type para informar que tipo de conteúdo estamos enviando e que tipo estamos
recebendo e ainda outros tipos de content que indicam várias coisas referentes ao
conteúdo
○ User-agent
○ Date
○ Keep-alive que indica a quantidade mínima e máxima de tempo que uma conexão deve ficar
aberta
31. Http - Cabeçalho (header)
● Quando se trata de documentos, normalmente transmitimos json, xml ou
html
● Junto a esses cabeçalhos, temos alguns itens que já vem com o protocolo,
que são o status code que serve para nos dizer o que acontece
● Dentro desse header podemos fazer operações, por exemplo, um if para
aceitar um conteúdo apenas se preencher um requisito, redirecionar para
outro endpoint e outras mais
32. Http - Status code
● Uma das informações mais importantes da requisição e resposta é status
code, ele nos dá um norte do que está acontecendo
● São armazenados em cinco famílias
○ Respostas de informação - 1xx
○ Respostas de sucesso - 2xx
○ Redirecionamentos - 3xx
○ Erros do cliente - 4xx
○ Erros do servidor - 5xx
33. Http - Status code - 1xx
● 100 - Continue
○ Mostra que “até agora” está tudo certo e o usuário pode continuar ou encerrar a operação,
caso já tenha o que precisa
■ Perguntar se o srv está disponível, por exemplo
● 101 - Switching protocol
○ Indica a qual protocolo o srv está alternando
● 102 - Processing
○ Indica que srv recebeu a solicitação mas não tem nenhuma resposta no momento
34. Http - Status code - 2xx
● 200 - OK
○ indica que deu tudo certo, “tudo certo” varia de método para método
● 201 - Created
○ indica que o recurso foi criado, normalmente usado em POST
● 202 - Accepted
○ Indica que a solicitação foi aceita, mas nada foi feito com ela. Pode ser que outro srv vá
tomar alguma ação ou algo assim
● 204 - No Content
○ Não há conteúdo para essa solicitação, muito utilizada para atualizar os cabeçalhos
35. Http - Status code - 3xx
● 300 - Multiple Choices
○ Há mais de uma resposta para a requisição, o user deve escolher qual, mas não há uma
maneira padrão.
■ Solicitar em formato específico, por exemplo
● 301 - Moved Permanently
○ A URI responsável foi movida, provavelmente será enviada a nova URI no cabeçalho
● 304 - Not Modified
○ Diz que o recurso não foi modificado, então pode ser usado o que está no cache
36. Http - Status code - 4xx
● 400 - Bad Request
○ Diz que o srv não entendeu a requisição devido a uma sintaxe inválida
● 401 - Unauthorized
○ Significa que o usuário precisa se autenticar para acessar o recurso
● 402 - Payment Required
○ Não é usado atualmente, o intuito era usar em sistemas de pagamento
● 403 - Forbidden
○ Usuário não tem permissão para acessar, mas aqui ele já é conhecido
● 404 - Not Found
○ Muito comum, o recurso solicitado não foi encontrado
37. Http - Status code - 4xx
● 405 - Method Not Allowed
○ O método da nossa requisição não é permitido para aquele recurso
■ Enviar um POST para um endpoint que só atende GET, por exemplo
● 415 - Unsupported Media Type
○ O tipo de mídia não é suportado pelo servidor
● 451 - Unavailable For Legal Reasons
○ Informado quando um recurso ilegal tem tentativa de acesso
■ Acessar uma página censurada, por exemplo
38. Http - Status code - 5xx
● 500 - Internal Server Error
○ Ocorreu uma situação com a qual o srv não sabe lidar
● 502 - Bad Gateway
○ Diz que o srv está atuando como uma ponte e que o srv que realmente atendeu a demanda
enviou uma resposta que a “ponte” não entende
● 503 - Service Unavailable
○ O srv não está pronto para atender
■ Pode ser que está em manutenção, por exemplo
● 504 - Gateway Timeout
○ Diz que o srv “ponte” não obteve resposta a tempo
39. Http - Todos os status
● Clique aqui para acessar a lista com todos os Status Code
40. Http - Methods
● O protocolo especifica alguns métodos para realizar as requisições
● São eles
○ GET
■ Solicita a representação do recurso solicitado passando parâmetros na URL
○ HEAD
■ Idêntico ao GET, porém a resposta não contém corpo, muito usado para atualizar
headers
○ POST
■ É utilizado para criar, enviar, submeter algum dado ao srv ou recurso, pode ou não
receber corpo na resposta
41. Http - Methods
● PUT
○ É usado para fazer um update de algo com o corpo da requisição, editar um usuário, por
exemplo
● DELETE
○ Como o nome diz, é usado para deletar, apagar, arquivos, dados ou qualquer coisa que
possa ser apagada, pode ter corpo ou não na resposta
● CONNECT
○ É usado para conectar o srv, não tem corpo na resposta e nem na requisição
● OPTIONS
○ É usado para saber o que o srv suporta, quais métodos e outras opções, podemos
especificar a url ou colocar um * para fazer referência ao srv todo
42. Http - Methods
● TRACE
○ Realiza um loop-back no caminho para saber se está tudo correto, muito utilizado para
debug, não tem corpo
● PATCH
○ Usado para fazer modificações parciais para um recurso, tem corpo na requisição e
resposta, alterar apenas o nome de um usuário
44. Http2
● Surgido em 2015, apareceu para melhorar a performance e segurança dos
dados
● Não muda a semântica nem os métodos da versão 1
● É obrigatório o uso de certificados SSL, não por imposição da versão 2 ,
mas sim pelos browser que relataram suportar apenas o uso de TLS
● Habilita também, de forma automática a compressão dos dados com gzip e
dos metadados com hpack, diminuindo tamanho da transferência e
proporcionando mais velocidade
45. Http2
● Também faz uso de paralelismo nas requisições e respostas
● É possível priorizar recursos na ordem de solicitação
47. SOA
● Soa trata de quebrar “negócio” inteiro de acordo com suas áreas
● Ter um serviço responsável pelo financeiro, outro pelo administrativo, outro
pelo comercial e por aí vai
● Fazer com que esses serviços possam se comunicar e comunicar-se
também com um repositório central de serviços
● Esse repositório será responsável por listar quais serviços estão disponíveis
para uso e quais não
● Proporciona uma integração muito grande de sistemas a medida que todos
eles podem se conversar agora
48. SOA
● Essa integração beneficia muito as áreas, devido a comunicação direta,
eliminando intermediários e fazendo com que os custos sejam reduzidos e
que as informações sejam mais transparentes
● Normalmente é feito em serviços que são compartilhados por toda a
organização ou por grande parte dela, como emissão de NFs, por exemplo
● Em SOA temos um registro, cliente e um provedor de serviços
● Registro é onde vão estar listados todos os serviços disponíveis, onde os
clientes vão buscar o serviço desejado
49. SOA
● Cliente é quem consome o serviço
● Provedor é onde vai estar disponível aquele serviço, o registro informa onde
o serviço está, que é no provedor
● Diminui o acoplamento de aplicação, fazendo a comunicação baseada em
solicitação e resposta
● Possibilita o reuso de código, uma vez que uma lógica de negócio pode ser
alterada para utilizar um ou mais serviços
● Temos em soa também um barramento de serviços, onde novas
ferramentas possam fazer uso desse barramento
50. SOA
● Esse barramento representa é interface de comunicação entre provedores e
consumidores
● Podemos ter aplicações desenvolvidas em qualquer linguagem, uma vez
que as aplicações irão adotar um padrão de comunicação que pode ser
Soap, ActiveMQ ou Apache Thrift
● O barramento principal de serviços é guardado em um srv, se ele falhar,
todos os serviços que fazem parte desse barramento ficam fora
51. SOA
● A performance é um ponto delicado, em empresas muito grandes pode não
ser viável, pois apesar da divisão em serviços, o barramento pode ficar
muito complexo
● Porém, é meio que sair de uma estrutura monolítica para usar outra, quando
criado o ESB
● O banco de dados pode ser compartilhado por vários serviços da aplicação
53. Microsserviços
● De certa forma, são parecidos com SOA, uma vez que buscam dividir uma
aplicação em várias aplicações
● Mas diferente de SOA, não há um barramento, ou, pelo menos, não tão
grande, a ponto de se tornar o “monolitão”
● Cada função de uma aplicação se torna um serviço, exemplo do youtube
○ A caixa de pesquisa é um serviço, o botão de curtir é outro serviço e assim vai por cada
função da aplicação
● Cada serviço pode usar uma linguagem diferente, desde que usem um
protocolo padrão para se comunicar
54. Microsserviços
● Assim como na linguagem, cada aplicação pode usar um banco de dados
diferente
● Podemos ter várias instâncias do mesmo serviço para balancear a carga
● Podemos atualizar um serviço sem que isso atrapalhe o funcionamento da
aplicação “maior”
● E no caso da queda de um serviço, o resto da aplicação funciona
● O banco de dados é único para cada microsserviço
56. O que é o “contrato”?
● É a API em si
● Nela é que estão as “regras” do contrato, quais os pontos que podemos
acessar, o que podemos fazer nessa API
● E as vezes precisamos fazer alterações neste contrato, aí é necessário
lançar uma nova versão deste contrato
57. Versionar
● As vezes, precisamos fazer alterações na nossa API, seja para implementar
um novo recurso, excluir, adicionar novas informações em um recurso já
existente
● Então é preciso lançar uma nova versão para esses novos conteúdos, mas,
se simplesmente modificarmos tudo, quem já consome o serviço vai ter sua
aplicação quebrada
● Então lançamos uma nova versão e damos total suporte as versões antigas,
até que o serviço antigo não seja mais utilizado
58. Como versionar?
● Podemos versionar de dois modos básicos, existem mais maneiras.
● Adicionar um v1, ou v(e o número da tua versão) após raiz do teu endereço,
por exemplo, www.minhaapi.com/v1, assim como o Github faz
● Quem consumia apenas www.minhaapi.com vai continuar consumindo da
mesma maneira, quem quiser consumir a nova, tem que adaptar seus
sistemas para as novas respostas e requests
● Essa é a maneira mais fácil, precisamos “apenas” adicionar uma “pasta”
nova com o conteúdo a ser adicionado
59. Como versionar?
● É necessário informar também aos consumidores como a nova versão vai
funcionar
● Podemos também usar o versionamento por Domínio, que ao invés de usar
um v(qualquer versão) após a raiz da API, vai usar o v logo no início
● Isso fará com que o site mude tbm, por exemplo, v1.minhaapi.com
● Esse modo já envolve outros times, como o de infra para ajustar o domínio,
aplicar algumas regras que sejam necessárias
● E funciona da mesma maneira, incluímos os serviços novos e
disponibilizamos, sempre dando suporte aos serviços antigos
