Quando comecei a aprender a programar, o termo API sempre me assombrava. Eu não conseguia entender o que realmente significava porque ouvia as pessoas falando sobre APIs em diferentes contextos.

O maior desafio era que eu não conseguia encontrar recursos para aprender sobre APIs em termos simples.

Agora que sei como as APIs funcionam, decidi escrever este guia para qualquer iniciante que tenha dificuldade para entender esse tópico que não é tão complicado, mas que ainda é confuso, em desenvolvimento para a web e em engenharia de software.

O que é uma API?

API significa Interface de Programação de Aplicações. A aplicação pode ser qualquer software que execute uma tarefa específica e a interface é um ponto onde duas aplicações se comunicam.

Uma aplicação atua como client e o outro atua como servidor. Um client solicita algum recurso (por exemplo, uma foto) e o servidor envia essa foto para o client.

O client, aqui, pode ser seu celular, computador desktop ou laptop ou qualquer dispositivo que você usa para navegar na internet. O servidor é um computador maior, que armazena os dados que você deseja (uma foto, no nosso caso).

Suponha que eu queira uma fotografia da natureza para enviar para meu blog de viagens. Eu posso ir ao site do Unsplash, digitar "natureza" na barra de pesquisa e ele retornará um grande número de fotografias da natureza.

Essa é uma API trabalhando nos bastidores para fazer a conversa entre o Unsplash e eu acontecer.

Como as APIs funcionam?

Os computadores seguem um protocolo para se comunicar uns com os outros. Um protocolo nada mais é do que um conjunto de regras que os computadores seguem para se comunicar. Qualquer computador que não siga o protocolo quebra o fio da comunicação.

Você pode ter usado Bluetooth para compartilhar dados no passado. Bluetooth nada mais é do que um protocolo para dispositivos móveis se comunicarem entre eles a uma distância menor.

Quando você pede ao seu amigo para enviar fotos de sua última viagem, seu dispositivo atua como client e o dispositivo do seu amigo (aquele que envia as fotos) é o servidor.

Esse é apenas um exemplo de protocolo. Temos um grande número de protocolos no mundo da ciência da computação – um para quase tudo.

Na web, usamos o protocolo HTTP (em inglês, Hyper Text Transfer Protocol). As APIs disponíveis na web usam o protocolo HTTP por vários motivos – é fácil de usar e é popular, por exemplo.

As comunicações que ocorrem pelo protocolo HTTP também são conhecidas como ciclo de solicitação-resposta porque é exatamente assim que o protocolo funciona. O client envia uma solicitação ao servidor e o servidor responde ao client em relação a essa solicitação.

Ao contrário dos humanos, os computadores precisam ser rígidos para se comunicarem uns com os outros ou eles quebram a comunicação. Por esse motivo, um client (computador/dispositivo solicitante) precisa de um conjunto de informações para enviar com a solicitação para que o servidor responda de acordo. Essas informações incluem:

1. URL – um endereço da web onde você deseja fazer uma solicitação
2. Método – se você deseja dados já armazenados em algum lugar ou deseja salvar novos dados em um banco de dados
3. Cabeçalho – todas as informações relevantes sobre sua solicitação, incluindo em qual formato o dispositivo client espera receber os dados
4. Corpo – os dados reais da solicitação

No nosso exemplo do Unsplash, o URL é https://unsplash.com/s/photos/nature. O método é GET, porque queremos que o servidor recupere imagens da natureza. O cabeçalho inclui informações como o formato que nosso computador espera obter e aceitar – como o idioma, o idioma do dispositivo, nosso sistema operacional e assim por diante. O corpo inclui os dados que precisamos enviar ao servidor (a palavra-chave natureza, por exemplo).

Existem quatro tipos de métodos para solicitações HTTP que abordaremos em breve. Por enquanto, saiba apenas que um método indica o que você deseja fazer com os dados disponíveis no servidor. Por exemplo, se você deseja esses dados como documentos ou se deseja salvar uma nova entrada em dados salvos em algum lugar.

Quando um client faz uma solicitação, o servidor responde a essa solicitação. A resposta pode ser os dados que o client solicitou ou um erro.

Assim como uma resposta, uma solicitação tem uma estrutura que inclui URL, código de status, cabeçalho e corpo. Em uma solicitação, temos um método, que possui quatro tipos. Na resposta, temos um código de status, que indica se uma solicitação foi aceita ou recusada.

Métodos HTTP

Existem quatro métodos HTTP disponíveis e cada um tem sua funcionalidade exclusiva.

1. GET: como já discutido, indica que o client está solicitando que os dados sejam enviados do servidor.
2. POST: esse método informa ao servidor que o client deseja criar uma entrada em um banco de dados. Por exemplo, salvar uma nova postagem em um blog em um banco de dados de todos os blogs anteriores.
3. DELETE: como o nome em inglês sugere, o client deseja excluir um registro de dados de um banco de dados.
4. PUT: esse método é usado quando um client deseja atualizar ou editar um registro de dados. Por exemplo, alterar sua senha do Facebook.

Códigos de status HTTP

Existe uma lista enorme de códigos de status HTTP, mas vamos dar uma olhada em alguns dos mais comuns:

1. 200 OK: indica que a solicitação foi atendida com sucesso pelo servidor
2. 201 CREATED: a entrada de dados cuja criação você solicitou foi criada
3. 404 NOT FOUND: indica que o recurso que você solicitou não foi encontrado pelo servidor
4. 500 INTERNAL SERVER ERROR: significa que ocorreu um erro no lado do servidor e que ele não pôde atender à sua solicitação

Não há necessidade de memorizar esses códigos de status, pois a lista é enorme e você os aprenderá inconscientemente à medida que os encontrar em sua jornada de desenvolvimento.

Ainda assim, existem vários códigos de status que indicam uma resposta genérica, como você pode ver aqui:

1. 100s: respostas informativas, indicando o progresso da solicitação
2. 200s: sucesso, indicando o sucesso da solicitação
3. 300s: redirecionamento, indicando que a solicitação teve que ser redirecionada para outro lugar
4. 400s: erros do client, indicando erros que ocorreram no lado do client
5. 500s: erros do servidor, quando o servidor falha ao responder a uma solicitação válida do client

Tipos de APIs

Você se lembra quando eu disse que ficava confusa quando as pessoas falavam sobre APIs em diferentes contextos? Isso ocorre porque também temos diferentes tipos de APIs disponíveis.

As que falamos neste artigo são APIs da web que usam o protocolo HTTP. Os desenvolvedores podem usá-las para criar uma melhor experiência do usuário para seus usuários.

Outros tipos incluem as APIs internas, que estão ocultas de usuários externos e que são usadas apenas dentro de uma empresa.

Existem também APIs abertas, que estão disponíveis para serem usadas por qualquer pessoa gratuitamente (como a OpenWeatherMap API, a API de mapa meteorológico aberto). Você pode ter APIs de parceiros, que são compartilhadas apenas entre parceiros de negócios para realizar suas tarefas de negócios e APIs compostas, que combinam sequencialmente várias solicitações de API em uma única chamada de API para reduzir a carga do servidor e criar uma experiência mais rápida.

Recursos para aprender mais sobre APIs:

Se você quiser aprender mais sobre a criação de APIs, aqui há um texto para começar (em inglês).

Aqui está um tutorial sobre tipos de APIs, ferramentas de testes e documentação (em inglês).

Aqui está uma ficha informativa sobre a Fetch API (em inglês), para você começar a aprender mais sobre ela.

Conclusão

Uma API é uma interface para dois computadores se comunicarem para realizar tarefas na internet.

As APIs da web seguem o protocolo HTTP para se comunicarem. Esse protocolo possui uma estrutura específica de solicitação e resposta.

Existem diferentes métodos para realizar diferentes tarefas e vários códigos de status estão disponíveis. Eles indicam se a solicitação foi bem-sucedida, recusada ou está em estado pendente.

Interessado em se conectar pelo LinkedIn? Fale com a autora por lá.

Em desenvolvimento para a web, as APIs REST têm uma função importante na garantia de uma comunicação tranquila entre o client e o servidor.

Você pode pensar no client como sendo o front-end e o servidor como o back-end.

A comunicação entre o client (front-end) e o servidor (back-end), normalmente, não é muito direta. Assim, usamos uma interface, a qual chamamos de Interface de Programação de Aplicações (ou API), que agirá como um intermediário entre o client e o servidor.

Como a API tem uma função importante nessa comunicação entre o client e o servidor, devemos sempre criar APIs considerando as melhores práticas possíveis. Isso ajuda os desenvolvedores em sua manutenção, bem como em seu consumo, evitando que encontrem problemas ao realizar suas tarefas.

Neste artigo, mostrarei 9 práticas recomendadas a serem seguidas ao criar APIs REST. Isso ajudará a criar as melhores APIs possíveis e a tornar mais fácil a vida daqueles que consumem suas API.

Primeiramente, o que é uma API REST?

REST é a abreviação de Representational State Transfer (em português, transferência de estado de representação). É um estilo de arquitetura de software criado por Roy Fielding no ano 2000 que serve para guiar a criação de uma arquitetura para a web.

Qualquer API (Interface de programação de aplicações) que siga o princípio de criação REST é considerada RESTful.

Colocado de modo simples, uma API REST é um meio para que dois computadores se comuniquem por meio do HTTP (Protocolo de transferência de hipertexto), do mesmo modo que clients e servidores se comunicam.

Melhores práticas de criação de APIs REST

1. Use JSON como o formato para o envio e o recebimento de dados

No passado, aceitar e responder a solicitações de API era feitos principalmente em XML e até em HTML. Hoje em dia, porém, JSON (JavaScript Object Notation) tornou-se, na maioria das vezes, o formato de fato para enviar e receber dados de API.

Isso ocorre porque, com o XML, por exemplo, muitas vezes é um pouco complicado decodificar e codificar dados – portanto, o XML não é mais amplamente suportado pelos frameworks.

O JavaScript, por exemplo, tem um método incorporado para analisar dados em JSON por meio da API de busca (em inglês, Fetch API) porque o JSON foi feito principalmente para ele. Se, contudo, você estiver usando qualquer outra linguagem de programação, como Python ou PHP, agora todas elas também têm métodos para analisar e manipular dados em JSON.

O Python, por exemplo, fornece os métodos json.loads() e json.dumps() para o trabalho com dados em JSON.

Para garantir que o client interprete os dados em JSON corretamente, você deve definir o tipo Content-Type no cabeçalho de resposta como application/json ao fazer a solicitação.

Para frameworks do lado do servidor, por outro lado, muitos deles definem o Content-Type automaticamente. O Express, por exemplo, agora tem o middleware express.json() para essa finalidade. O pacote do NPM chamado body-parser ainda funciona com o mesmo propósito.

2. Use substantivos ao invés de verbos nos endpoints

Ao criar uma API REST, você não deve usar verbos nos caminhos dos endpoints. Eles devem usar substantivos que representem aquilo que eles fazem.

Isso ocorre porque os métodos HTTP, como GET, POST, PUT, PATCH e DELETE, já usam a forma verbal para realizar operações básicas de CRUD (Create, Read, Update e Delete – em português, criar, ler, atualizar e excluir dados).

GET, POST, PUT, PATCH e DELETE são os verbos mais comuns do HTTP. Existem outros, como COPY, PURGE, LINK, UNLINK e assim por diante.

Dessa maneira, por exemplo, um endpoint não deve ser assim:

https://meusite.com/getPosts (para obter posts)

ou assim:

https://meusite.com/createPost (para criar posts)

Pelo contrário, ele deve ter esta aparência: https://meusite.com/posts (para as publicações em si)

Resumidamente, deixe que os verbos do HTTP lidem com o que os endpoints fazem. Deixe que GET obtenha os dados, POST os crie, PUT os atualize e DELETE os exclua.

3. Nomeie coleções com substantivos no plural

Pense nos dados da sua API como se fossem uma coleção de recursos diferentes para aqueles que a consomem.

Se você tiver um endpoint como https://meusite.com/post/123, pode não haver problema na exclusão de um post com uma solicitação de DELETE ou, ainda, atualizar um post com uma solicitação de PUT ou PATCH, mas isso não informa ao usuário que pode haver outros posts na coleção. É por isso que suas coleções devem usar substantivos no plural.

Assim, em vez de https://meusite.com/post/123, utilize https://meusite.com/posts/123.

4. Use códigos de erro no tratamento de erros

Você sempre deve usar os códigos de status regulares do HTTP nas respostas às solicitações feitas à API. Isso ajudará os usuários a saberem o que está acontecendo – se a solicitação teve sucesso, se ocorreu um erro ou qualquer outra situação.

Abaixo, temos uma tabela que mostra diferentes códigos de status do HTTP e seus significados:

5. Use aninhamento nos endpoints para mostrar as relações

Com frequência, diferentes endpoints podem estar interligados. Por isso, aninhe-os de maneira que seja mais fácil compreender as relações entre eles.

Como exemplo, no caso de uma plataforma de blog com diversos usuários, posts diferentes podem ser escritos por autores diferentes. Desse modo, um endpoint como https://meusite.com/posts/autor seria um aninhamento válido para o caso em questão.

Seguindo o mesmo raciocínio, os posts podem ter comentários individuais. Assim, para obter os comentários, um endpoint como https://meusite.com/posts/postId/comentarios faria parte de uma lógica aceitável.

Evite aninhamentos que tenham mais de três níveis de profundidade, pois isso pode fazer com que a API fique menos elegante e legível.

6. Use filtragem, ordenação e paginação para obter os dados solicitados

Por vezes, o banco de dados de uma API pode ficar incrivelmente grande. Se isso acontecer, obter dados desse banco poderia acabar sendo muito lento.

Filtragem, ordenação e paginação são ações que podem ser realizadas na coleção de uma API REST. Elas permitem obter, ordenar e organizar os dados necessários em páginas para que o servidor não fique muito ocupado com solicitações.

Um exemplo de um endpoint com filtragem é o que vemos abaixo:
https://meusite.com/posts?tags=javascript
Esse endpoint obterá todos os posts que tiverem a tag JavaScript.

7. Use SSL para ter mais segurança

SSL significa secure socket layer (em português, camada de soquete segura). Ela é fundamental para a segurança na criação de uma API REST. Ela garantirá que sua API esteja mais segura e a tornará menos vulnerável a ataques maliciosos.

Outras medidas de segurança que você deve levar em consideração incluem: tornar a comunicação entre servidor e client privada e garantir que qualquer pessoa que consuma a API não receba mais do que aquilo que solicitou.

Os certificados de SSL não são difíceis de se carregar em um servidor e estão disponíveis gratuitamente, em grande parte, durante o primeiro ano do site. Nos casos em que não estão disponíveis gratuitamente, eles também não são tão caros.

A diferença óbvia entre o URL de uma API REST que é executada com SSL daquela que não é executada com ela é a presença de um "s" no HTTP:
https://meusite.com/posts faz uso de SSL.
http://meusite.com/posts não faz uso de SSL.

8. Seja claro com o controle de versão

APIs REST devem ter versões diferentes, de maneira a não forçar os clients (usuários) a migrar para novas versões. Isso pode até quebrar a aplicação dos usuários se você não for cuidadoso.

Um dos sistemas de controle de versão mais comuns no desenvolvimento para a web é o de controle de versão semântico.

Um exemplo de controle de versão semântico é 1.0.0, 2.1.2, e 3.3.4. O primeiro número representa a versão principal (em inglês, major), o segundo representa a versão secundária (em inglês, minor) e o terceiro representa a versão de patch.

Muitas APIs RESTful dos gigantes da área de tecnologia – e mesmo de indivíduos trabalhando nela – vêm nesse formato:
https://meusite.com/v1/ para a versão 1
https://mysite.com/v2 para a versão 2

O Facebook faz o controle de versão de suas APIs assim:

O Spotify faz seu controle de versão do mesmo modo:

Não é, contudo, o caso para todas as APIs. O Mailchimp, por exemplo, controla as versões de sua API de modo diferente:

Ao deixar APIs REST disponíveis desse modo, você não forçará o client a migrar para novas versões caso o usuário decida não fazer isso.

9. Forneça uma documentação de API adequada e precisa

Ao criar uma API REST, é preciso ajudar os clients (consumidores) a aprender e descobrir como usá-la corretamente. A melhor maneira de se fazer isso é fornecendo uma boa documentação para a API.

A documentação deve conter:

• endpoints relevantes da API
• solicitações de exemplo aos endpoints
• implementação em diversas linguagens de programação
• mensagens listadas para os diferentes erros com seus respectivos códigos de status

Uma das ferramentas mais comuns que você pode usar para a documentação de uma API é o Swagger. Você também pode usar o Postman, uma das ferramentas mais comuns de teste de APIs no desenvolvimento de software, para documentar suas APIs.

Conclusão

Neste artigo, você aprendeu sobre várias práticas recomendadas que você deve ter em mente ao criar suas APIs REST.

É importante fazer uso dessas práticas recomendadas e convenções para criar aplicações altamente funcionais, que trabalhem bem, sejam seguras e, em última análise, facilitem a vida dos consumidores das APIs.

Agradeço a leitura. Agora, é a sua vez de criar APIs com essas práticas recomendadas.

Escrito por: Ramesh Lingappa

Todos sabemos o valor das APIs. Elas são a porta de entrada para a exploração de outros serviços, para a integração com eles e para a criação de soluções incríveis mais rapidamente.

Você já deve ter criado ou está pensando em criar APIs para que outros desenvolvedores as utilizem. Uma API precisa de alguma forma de autenticação para dar acesso autorizado aos dados que ela retorna.

Existem vários padrões de autenticação disponíveis hoje em dia, como chaves de API, OAuth, JWT, entre outros.

Neste artigo, veremos como gerenciar corretamente as chaves para acessar APIs.

Por que usar chaves de API?

As chaves de API são simples de usar, são breves, estáticas e não expiram até terem sido revogadas. Elas fornecem uma maneira fácil para que diversos serviços se comuniquem.

Se você fornecer uma API para que seus clientes a consumam, é essencial que você crie as chaves de API do modo certo.

Vamos começar. Quero mostrar a vocês como criar chaves de API corretamente.

Geração de chaves de API

Como a própria chave de API é uma identidade a partir da qual reconheceremos a aplicação ou o usuário, ela precisa ser exclusiva, aleatória e não ser fácil de adivinhar. Chaves de API geradas também devem usar caracteres alfanuméricos e especiais. Um exemplo de chave de API seria zaCELgL.0imfnc8mVLWwsAawjYr4Rx-Af50DDqtlx.

Armazenamento seguro de chaves de API

Como a chave da API fornece acesso direto aos dados, ela é semelhante a uma senha que o usuário da web ou da aplicação para dispositivos móveis fornece para obter acesso aos mesmos dados.

Pense nisto: o motivo pelo qual precisamos armazenar chaves de API é garantir que a chave da API que se encontra na requisição seja válida e emitida por nós mesmos (como uma senha).

Não precisamos conhecer a chave de API bruta. Precisamos apenas validar se a chave está correta. Assim, em vez de armazenar a chave em texto simples (o que é ruim) ou criptografá-la, devemos armazená-la como um valor com um hash em nosso banco de dados.

Um valor com hash significa que, mesmo que alguém obtivesse acesso não autorizado ao nosso banco de dados, as chaves de API não seriam "vazadas" e tudo continuaria seguro. O usuário final poderia enviar a chave de API bruta em toda solicitação à API e poderíamos validar a chave passando-a pelo hash na solicitação e comparando a chave com hash com a chave com hash armazenada em nosso banco de dados. O problema está no fato de que armazenar um valor com hash pode trazer problemas específicos de usabilidade. Falaremos deles agora.

Como apresentar as chaves de API aos usuários

Como não armazenamos a chave de API original, podemos mostrá-la apenas uma vez para o usuário, no momento de sua criação. Desse modo, não se esqueça de alertar os usuários de que ela não poderá ser obtida novamente, sendo preciso gerar um novo token caso eles tenham se esquecido de copiar a chave de API e de armazená-la de modo seguro. Você pode fazer algo assim:

Como os usuários podem identificar posteriormente uma chave de API gerada

Outro problema está em como os usuários identificam a chave de API certa em nosso console se precisarem editá-la ou revogá-la. Isso pode ser resolvido adicionando um prefixo à chave de API. Perceba na figura acima os primeiros 7 caracteres (nosso prefixo), separados do resto da chave de API pelo ponto.

Agora, você pode armazenar este prefixo no banco de dados e exibi-lo no console para que os usuários possam identificar rapidamente a entrada certa da chave de API, assim:

Não dê todo o poder à chave de API

Um erro comum que cometem os fornecedores de chaves de API é o de dar a uma única chave acesso a tudo, já que isso facilita o gerenciamento. Não faça isso. Leve em conta que um usuário precisa apenas ler um e-mail para gerar uma chave de API. Essa chave, porém, agora terá acesso total aos outros serviços, incluindo a permissão de exclusão de registros no banco de dados.

A abordagem correta seria a de permitir aos usuários finais terem acesso a chaves de API restritas e selecionar ações específicas que essas chaves possam realizar. Isso pode ser feito por meio do fornecimento de escopos, onde cada escopo representa uma permissão específica.

Por exemplo:

• se você precisa de uma chave de API apenas para enviar e-mails, pode gerar uma chave de API com o escopo sendo algo como "email.envios"
• se o usuário final tiver diversos servidores e cada um deles realizar uma ação específica, uma chave de API separada pode ser gerada para cada escopo específico.

Assim, ao criar uma chave de API, permita que os usuários selecionem qual o acesso à chave de API deve ter, assim como na imagem abaixo.

Desse modo, os usuários podem gerar diversas chaves de API, cada uma com regras específicas de acesso, gerando uma maior segurança. Quando uma requisição de API for recebida, será possível verificar se a chave de API tem o escopo certo para acessar aquela API. O banco de dados, agora, teria uma aparência semelhante a esta:

Chaves de API com limitação de taxa

Sim, talvez você já saiba disso, mas é importante limitar a taxa de solicitações feitas com chaves de API específicas para garantir que ninguém mal-intencionado possa derrubar seus servidores de APIs ou causar problemas de desempenho que possam afetar outros usuários. Ter uma limitação de taxa adequada e monitorar soluções mantém o serviço da API em bom estado.

Conclusão

Chaves de API, quando criadas do modo certo, seguem sendo uma grande maneira de se comunicar com outro servidor. Como revisamos neste artigo, seguir certas práticas oferece benefícios tanto aos fornecedores quanto aos consumidores das APIs. Espero que o artigo tenha ajudado você.

Divirta-se deixando suas APIs cada vez mais seguras!

Se você não está muito familiarizado com APIs, pode estar se perguntando... por que tanta conversa sobre o versionamento de API?

Se você já teve de fazer alterações na API, provavelmente é você quem está se conversando sobre o assunto. Se você mantém uma API, também pode estar tentando responder a perguntas desafiadoras como estas:

# Esta é a versão 2 apenas de 'produtos' ou da API inteira?
/v2/produtos

# O que gerou a mudança de v1 para v2? Qual é a diferença entre elas?
/v1/produtos
/v2/produtos

Essas perguntas sobre versionamento não são fáceis de responder. Nem sempre está claro a que v1 ou v2 se referem. Não devemos simplesmente fazer uma segunda versão de um endpoint quando a primeira já não parece ser suficiente.

Há razões claras pelas quais sua API precisa ter versionamento. Também existem estratégias claras sobre como navegar efetivamente pelas alterações da API.

No entanto, descobri que a maioria dos desenvolvedores – incluindo eu mesmo até ter aprendido algumas lições da maneira mais difícil – não está ciente dessas razões e estratégias.

Este artigo procura mostrar as razões para o versionamento e as estratégias para realizá-lo. Vamos assumir um contexto de API REST – pois é um padrão para muitas APIs – e nos concentrar no aspecto do versionamento.

O que é o versionamento?

Devemos começar com a definição de nível sobre o que significa o termo "versionamento de API". Aqui está a nossa definição de trabalho:

O versionamento de APIs é a prática de gerenciar de maneira transparente as alterações em sua API.

O versionamento é uma comunicação eficaz em torno de alterações em sua API, para que quem as consome saiba o que esperar dela. Você está entregando dados para o público de algum modo e precisa comunicar quando muda a maneira como os dados são entregues.

O resumo disso é que, no mínimo, é preciso gerenciar contratos de dados e quebrar mudanças. O primeiro é o bloco de construção principal da sua API e o segundo revela o motivo de o versionamento ser necessário.

Contratos de dados

Uma API é uma Interface de Programação de Aplicações. Uma interface é um limite compartilhado para a troca de informações. O contrato de dados é o coração dessa interface.

Um contrato de dados é um acordo sobre o modo e o conteúdo geral dos dados de solicitação e/ou resposta.

Para ilustrar um contrato de dados, aqui está um corpo de resposta JSON básico:

{
  "dados": [
    {
      "id": 1,
      "nome": "Produto 1"
    },
    {
      "id": 2,
      "nome": "Produto 2"
    }
  ]
}

O JSON é um objeto com uma propriedade dados, que é um array (lista) de produtos, cada um desses produtos com uma propriedade id e uma propriedade nome. A propriedade dados, porém, também poderia ter sido facilmente chamada de body. A propriedade id de cada produto, por sua vez, poderia ter sido um GUID em vez de um número inteiro. Se um único produto estivesse sendo retornado, dados poderia ser um objeto em vez de um array.

Essas mudanças aparentemente sutis teriam criado um acordo diferente, um contrato diferente, em relação ao "formato" no qual os dados são apresentados. O formato dos dados pode ser aplicado a nomes de propriedades, tipos de dados ou até mesmo ao formato esperado (JSON ou XML).

Por que o versionamento é necessário?

Com as APIs, algo tão simples como alterar o nome de uma propriedade de IdDoProduto para IDDoProduto pode causar problemas para quem consome a API. Isso foi exatamente o que aconteceu com a nossa equipe na semana passada.

Felizmente, fizemos testes para detectar alterações no contrato da API. No entanto, não deveríamos ter precisado desses testes, porque os mantenedores da API deveriam saber que essa seria uma mudança que causaria problemas.

Mudanças problemáticas

Essa foi uma mudança problemática no contrato de dados acordado, pois a mudança deles nos obrigou a também mudar nossa aplicação.

O que constitui uma "mudança problemática" em um endpoint de API?

As alterações de quebra se encaixam principalmente nas seguintes categorias:

1. Alterar o formato de solicitação/resposta (por exemplo, de XML para JSON)
2. Alterar um nome de propriedade (por exemplo, de nome para nomeDoProduto) ou tipo de dados em uma propriedade (por exemplo, de número inteiro para número de ponto flutuante)
3. Adicionar um campo obrigatório na solicitação (por exemplo, um novo cabeçalho ou propriedade obrigatório em um corpo de solicitação)
4. Remover uma propriedade na resposta (por exemplo, remover a descricao de um produto)

Gerenciamento de alterações da API

Nunca é sábio ou gentil forçar os consumidores de uma API a fazer uma mudança. Se você precisar fazer uma alteração problemática, use o versionamento para isso. Abordaremos as maneiras mais eficazes de fazer a versão da sua aplicação e dos endpoints.

Primeiramente, vamos discutir brevemente como evitar mudanças problemáticas. Poderíamos chamar isso de gerenciamento de alterações da API.

O gerenciamento eficaz de alterações no contexto de uma API é resumido pelos seguintes princípios:

• Manter o suporte a propriedades/endpoints existentes
• Adicionar novas propriedades/endpoints em vez de alterar os existentes
• Tornar obsoletos propriedades/endpoints com muito cuidado

Aqui está um exemplo que demonstra todos esses três princípios no contexto da resposta para solicitar dados do usuário:

{
  "dados": {
    "id": 1,
    "nome": "Carlos Ray Norris",       // propriedade original
    "nomeInicial": "Carlos",           // propriedade nova
    "sobreNome": "Norris",             // propriedade nova
    "apelido": "Chuck",                // propriedade obsoleta
    "apelidos": ["Chuck", "Walker"]   // propriedade nova
  },
  "meta": {
    "notasDosCampos": [
      {
        "campo": "apelido",
        "nota": "Será tornado obsoleto em [data futura]. Utilize apelidos em seu lugar."
      }
    ]
  }
}

Nesse exemplo, nome era uma propriedade original. Os campos nomeInicial e sobrenome estão sendo implementados para fornecer uma opção mais granular, caso quem consuma a API queira exibir "Sr. Norris" com alguma interpolação de strings, mas sem ter que analisar o campo nome. No entanto, a propriedade nome continuará a ser suportada.

apelido, por outro lado, será preterido em favor do array apelidos – já que Chuck tem muitos apelidos – há uma nota na resposta para indicar o tempo até que o campo se torne obsoleto.

Como fazer a versão de uma API?

Esses princípios farão uma grande diferença na navegação pelas alterações em sua API sem a necessidade de lançar uma nova versão. No entanto (e, às vezes, isso é inevitável), se você precisar de um novo contrato de dados, precisará de uma nova versão do seu endpoint. Então, você precisará comunicar isso ao público de alguma maneira.

Como um aparte, observe que não estamos falando sobre a versão da base de código subjacente. Portanto, se você estiver usando o versionamento semântico (link em inglês) para sua aplicação que também oferece suporte a uma API pública, provavelmente desejará separar esses sistemas de versionamento.

Como criar uma outra versão da sua API? Quais são os diferentes métodos para fazê-lo? Você precisará determinar que tipo de estratégia de versionamento deseja adotar em geral e, à medida que desenvolve e mantém sua API, precisará determinar o escopo de cada alteração de versão.

Escopo

Vamos abordar o escopo primeiro. Como exploramos acima, às vezes, os contratos de dados serão comprometidos por uma alteração problemática. Isso significa que precisaremos fornecer uma nova versão do contrato de dados. Isso pode representar uma nova versão de um endpoint ou uma alteração em um escopo mais global da aplicação.

Podemos pensar em níveis de mudança de escopo dentro de uma analogia de árvore:

• Folha – uma alteração em um endpoint isolado, sem relação com outros endpoints
• Galho – uma alteração em um grupo de endpoints ou em um recurso acessado por vários endpoints
• Tronco – uma alteração no nível da aplicação, causando uma alteração de versão na maioria ou em todos endpoints
• Raiz – uma alteração que afeta o acesso a todos os recursos da API de todas as versões

Como você pode ver, passando da folha até a raiz, as mudanças se tornam progressivamente mais impactantes e de alcance global.

O escopo de folha geralmente pode ser manipulado por meio do gerenciamento eficaz de alterações de API. Caso contrário, basta criar um outro endpoint com o novo contrato de dados de recursos.

Um galho é um pouco mais complicado, dependendo de quantos endpoints são afetados pela alteração do contrato de dados no recurso em questão. Se as alterações estiverem relativamente confinadas a um grupo claro de endpoints relacionados, você poderá navegar por isso introduzindo um novo nome para o recurso e atualizando seus documentos de acordo.

# variantes, que possui uma mudança problemática, é acessada por diversas rotas
/variantes
/produtos/:id/variantes

# apresentamos variantes-do-produto em seu lugar
/variantes-do-produto
/produtos/:id/variantes-do-produto

Um tronco refere-se a alterações no nível da aplicação que, geralmente, são resultado de uma alteração em uma das seguintes categorias:

• Formato (por exemplo, de XML para JSON)
• Especificação (por exemplo, de uma especificação interna para uma da JSON API ou da Open API)
• Cabeçalhos necessários (por exemplo, para autenticação/autorização)

Essas categorias exigirão uma alteração na versão geral da API. Portanto, você deve planejar cuidadosamente e executar bem a transição.

Uma alteração de raiz forçará você a dar um passo adiante para garantir que todos os consumidores de todas as versões de sua API estejam cientes da alteração.

Tipos de versionamento de API

À medida que nos voltamos para diferentes tipos de versionamento de API, desejaremos usar esses insights em escopos variados de alterações de API para avaliar os tipos. Cada abordagem tem seu próprio conjunto de pontos fortes e fracos para lidar com as mudanças com base em seu escopo.

Existem vários métodos para gerenciar a versão da API. O versionamento do caminho do URI (Uniform Resource Identifier, ou, em português, identificador uniforme de recurso) é o mais comum.

Caminho do URI

http://www.exemplo.com/api/v1/produtos
http://api.exemplo.com/v1/produtos

Essa estratégia envolve colocar o número da versão no caminho do URI e geralmente é feita com o prefixo "v". Na maioria das vezes, os criadores de APIs o usam para se referir à versão da aplicação (ou seja, o "tronco") em vez de a versão do endpoint (ou seja, da "folha" ou do "galho"), mas essa nem sempre é uma suposição segura.

O versionamento do caminho de URI implica versões orquestradas de versões de aplicação que exigirão uma de duas abordagens: manter uma versão enquanto desenvolve uma nova ou forçar os consumidores a esperar por novos recursos até que a nova versão seja lançada. Isso também significa que você precisaria transferir quaisquer endpoints não alterados de versão para versão. No entanto, para APIs com volatilidade relativamente baixa, ainda é uma opção decente.

Você, provavelmente, não gostaria de relacionar seu número de versão com o do endpoint ou recurso, pois isso resultaria facilmente em algo como uma v4 de produtos, mas uma v1 de variantes, o que seria bastante confuso.

Parâmetros de consulta

http://www.exemplo.com/api/produtos?versao=1

Esse tipo de versionamento adiciona um parâmetro de consulta (do inglês, query) à solicitação que indica a versão. Muito flexível em termos de solicitação da versão do recurso que você gostaria no nível de "folha", mas não tem noção da versão geral da API e se presta aos mesmos problemas de assincronia mencionados no comentário acima sobre o versionamento em nível de endpoint do caminho do URI.

Cabeçalho

Accept: versao=1.0

A abordagem de cabeçalho é aquela que fornece mais granularidade no fornecimento da versão solicitada de qualquer recurso específico.

No entanto, ela fica oculta dentro do objeto de solicitação e não é tão transparente quanto a opção do caminho do URI. Também é difícil dizer se 1.0 se refere à versão do endpoint ou da própria API.

Integração de tipos

Cada uma dessas abordagens parece ter a fraqueza de favorecer um escopo de "folha" ou de "tronco", mas sem dar suporte ao outro tipo.

Se você precisar manter a versão geral da API e, ao mesmo tempo, fornecer suporte para várias versões de recursos, considere uma combinação dos tipos de caminho do URI e parâmetros de consulta ou, ainda, uma abordagem de cabeçalho mais avançada.

# Combinação de caminho da URIe parâmetros de consulta
http://api.exemplo.com/v1/produtos?versao=1
http://api.exemplo.com/v1/produtos?versao=2

# Cabeçalhos estendidos, para http://api.exemplo.com/produtos
Accept: versao-da-api=1; versao-do-recurso=1
Accept: versao-da-api=1; versao-do-recurso=2

Conclusão

Tratamos de muitas coisas aqui. É hora de recapitular:

• O versionamento da API é a prática de gerenciar de modo transparente as alterações em sua API.
• O gerenciamento de uma API se resume a definir e evoluir contratos de dados e lidar com alterações problemáticas.
• A maneira mais eficaz de evoluir sua API sem interromper as alterações é seguir princípios eficazes de gerenciamento de alterações de API.
• Para a maioria das APIs, o versionamento do caminho do URI é a solução mais simples.
• Para APIs mais complexas ou voláteis, você pode gerenciar escopos variados de alterações empregando uma combinação das abordagens de caminho do URI e de parâmetros de consulta.

Embora esses princípios devam fornecer uma direção clara sobre como gerenciar efetivamente as alterações em suas APIs, evoluir uma API é, potencialmente, mais uma arte do que uma ciência. São necessárias reflexão e previsão para criar e manter uma API confiável.

Se você deseja se tornar um desenvolvedor iOS, existem algumas habilidades fundamentais que vale a pena conhecer. Em primeiro lugar, é importante estar familiarizado com a criação de visualizações de tabela. Em segundo, você deve saber como preencher essas visualizações de tabela com dados. Em terceiro, é ótimo se você puder buscar dados de uma API e usar esses dados em sua visualização de tabela.

O terceiro ponto é o que abordaremos neste artigo. Desde a introdução do Codable no Swift 4, fazer chamadas de API ficou muito mais fácil. Anteriormente, a maioria das pessoas usava pods como Alamofire e SwiftyJson (você pode ler sobre como fazer isso aqui - texto em inglês). Agora, o Swift está muito melhor desde o início. Assim, não há motivo para baixar um pod.

Vamos passar por alguns blocos de construção que são frequentemente usados para fazer uma chamada de API. Abordaremos esses conceitos primeiro, pois eles são partes importantes para entender como fazer uma chamada de API.

• Manipuladores de conclusão (em inglês, Completion handlers)
• URLSession
• DispatchQueue
• Ciclos de retenção

Por fim, vamos juntar isso tudo. Usaremos a API de Star Wars de código aberto para construir esse projeto. Você pode ver o código completo do meu projeto no GitHub.

Alerta de isenção de responsabilidade: sou nova na programação e sou autodidata. Peço desculpas se deturpei alguns conceitos.

Manipuladores de conclusão

Lembra do episódio de Friends em que a Phoebe fica grudada no telefone por dias esperando para falar com o atendimento ao cliente? Imagine se, bem no início dessa ligação, uma pessoa adorável chamada Pip dissesse: "Obrigado por ligar. Não tenho ideia de quanto tempo você precisará esperar, mas ligo de volta quando estivermos prontos para você." Não teria sido tão engraçado, mas Pip estaria se oferecendo para ser um manipulador de conclusão para Phoebe.

Você usa um manipulador de conclusão em uma função quando sabe que essa função demorará um pouco para ser concluída. Você não sabe quanto tempo e não quer pausar sua vida esperando que ela termine. Então, você pede a Pip para dar um toque a você quando ela estiver pronta para dar uma resposta. Desse modo, você pode seguir sua vida, sair para comprar coisas, ler um livro e assistir TV. Quando Pip avisar você que já tem a resposta, você pode pegá-la e usá-la.

Isso é o que acontece com as chamadas de API. Você envia uma solicitação de URL para um servidor, solicitando alguns dados. Você espera que o servidor retorne os dados rapidamente, mas não sabe quanto tempo levará. Em vez de fazer seu usuário esperar pacientemente até que o servidor forneça os dados, você usa um manipulador de conclusão. Isso significa que você pode dizer ao seu aplicativo para desligar e fazer outras coisas, como carregar o resto da página.

Você diz ao manipulador de conclusão para avisar o seu aplicativo assim que ele tiver as informações desejadas. Você pode especificar quais são essas informações. Desse modo, quando seu aplicativo é avisado, ele pode pegar as informações do manipulador de conclusão e fazer algo com elas. Normalmente, o que você fará é recarregar a visualização da tabela para que os dados apareçam para o usuário.

Aqui está um exemplo da aparência de um manipulador de conclusão. O primeiro exemplo é de quando configuramos a própria chamada da API:

func fetchFilms(completionHandler: @escaping ([Film]) -> Void) {
  // Configurar a variável lotsOfFilms
  var lotsOfFilms: [Film]
  
  // Chamar a API com algum código
  
  // Usar os dados da API, atribuir um valor a lotsOfFilms  
  
  // Dar ao manipulador de conclusão a variável lotsOfFilms
  completionHandler(lotsOfFilms)
}

Agora, podemos invocar a função fetchFilms. Algumas coisas a serem observadas:

• Você não precisa referenciar o completionHandler quando você chama a função. A única vez em que você faz referência ao completionHandler está dentro da declaração da função.
• O manipulador de conclusão nos devolverá alguns dados para usar. Com base na função que escrevemos acima, sabemos esperar dados do tipo [Film]. Precisamos nomear os dados para que possamos nos referir a eles. Abaixo, estou usando o nome films, mas poderia ser randomData, ou qualquer outro nome de variável.

O código ficará mais ou menos assim:

fetchFilms() { (films) in
  // Fazer algo com os dados retornados pelo manipulador de conclusão 
  print(films)
}

URLSession

URLSession é como o gerente de uma equipe. O gerente não faz nada sozinho. Seu trabalho é compartilhar o trabalho com as pessoas de sua equipe, e eles farão o trabalho. A equipe dela são as dataTasks. Toda vez que você precisar de alguns dados, escreva para o chefe e use URLSession.shared.dataTask.

Você pode dar ao dataTask diferentes tipos de informações para ajudá-lo a atingir seu objetivo. Dar informações ao dataTask é chamado de inicialização. Eu inicializo meu dataTasks com URLs. As dataTasks também usam manipuladores de conclusão como parte de sua inicialização. Aqui está um exemplo:

let url = URL(string: "https://www.swapi.co/api/films")

let task = URLSession.shared.dataTask(with: url, completionHandler: { (data, response, error) in 
  // Insira seu código aqui
})

task.resume()

As dataTasks usam manipuladores de conclusão e sempre retornam os mesmos tipos de informações: data, response e error. Você pode dar nomes diferentes a esses tipos de dados, como(data, res, err) ou (someData, someResponse, someError). Por uma questão de convenção, é melhor se ater a algo óbvio em vez de usar novos nomes de variáveis.

Vamos começar com error. Se dataTask retorna um error, você vai querer saber isso antecipadamente. Isso significa que você pode direcionar seu código para lidar com o erro normalmente. Isso também significa que você não se incomodará em tentar ler os dados e fazer algo com eles, pois há um erro ao retornar os dados.

Abaixo, estou lidando com o erro simplesmente imprimindo um erro no console e saindo da função. Existem muitas outras maneiras de lidar com o erro, se desejar. Pense em como esses dados são fundamentais para seu aplicativo. Por exemplo, se você tiver um aplicativo bancário e essa chamada de API mostrar o saldo dos usuários, convém lidar com o erro apresentando um modal ao usuário que diz: "Desculpe, estamos enfrentando um problema agora. Tente de novo mais tarde."

if let error = error {
  print("Error accessing swapi.co: /(error)")
  return
}

Em seguida, analisamos a resposta. Você pode converter a resposta para que seja um httpResponse. Desse modo, você pode ver os códigos de status e tomar algumas decisões com base no código. Por exemplo, se o código de status for 404, você saberá que a página não foi encontrada.

O código abaixo usa guard para verificar se existem duas coisas. Se ambos existirem, ele permitirá que o código continue para a próxima instrução após a cláusula de guard. Se qualquer uma das instruções falhar, saímos da função. Este é um caso de uso típico de uma cláusula de guard. Você espera que o código após uma cláusula de guard seja o fluxo ideal (ou seja, o fluxo fácil sem erros).

  guard let httpResponse = response as? HTTPURLResponse,
            (200...299).contains(httpResponse.statusCode) else {
    print("Erro na resposta. Código de status esperado: \(response)")
    return
  }

Finalmente, você lida com os dados em si. Observe que não usamos o manipulador de conclusão para error ou para response. Isso ocorre porque o manipulador de conclusão está aguardando dados da API. Se não chegar à parte de dados do código, não há necessidade de invocar o manipulador.

Estamos usando o JSONDecoder para analisar os dados de uma maneira agradável. Isso é muito bom, mas requer que você tenha estabelecido um modelo. Nosso modelo é chamado FilmSummary. Se o JSONDecoder for novo para você, dê uma olhada on-line para saber como usá-lo e como usar o Codable. É muito simples no Swift 4 e em versões superiores em comparação com a época do Swift 3.

No código abaixo, primeiro verificamos se os dados existem. Temos certeza de que deve existir, porque não há erros nem respostas HTTP estranhas. Em segundo lugar, verificamos se podemos analisar os dados que recebemos da maneira que esperamos. Se pudermos, devolvemos o resumo do filme ao manipulador de conclusão. Caso não haja dados para retornar da API, temos um plano de retorno (em inglês, fall back) do array vazio.

if let data = data,
        let filmSummary = try? JSONDecoder().decode(FilmSummary.self, from: data) {
        completionHandler(filmSummary.results ?? [])
      }

Portanto, o código completo para a chamada da API fica assim:

func fetchFilms(completionHandler: @escaping ([Film]) -> Void) {
    let url = URL(string: domainUrlString + "films/")!

    let task = URLSession.shared.dataTask(with: url, completionHandler: { (data, response, error) in
      if let error = error {
        print("Erro ao obter os filmes: \(error)")
        return
      }
      
      guard let httpResponse = response as? HTTPURLResponse,
            (200...299).contains(httpResponse.statusCode) else {
        print("Erro na resposta. Código de status esperado: \(response)")
        return
      }

      if let data = data,
        let filmSummary = try? JSONDecoder().decode(FilmSummary.self, from: data) {
        completionHandler(filmSummary.results ?? [])
      }
    })
    task.resume()
  }

Ciclos de retenção

Aviso: eu estou muito no início dos meus estudos nova para entender os ciclos de retenção! Aqui está a essência do que eu pesquisei on-line.

Os ciclos de retenção são importantes para o gerenciamento de memória. Basicamente, você quer que seu aplicativo limpe pedaços de memória de que não precisa mais. Suponho que isso torna o aplicativo mais eficiente.
Há muitas maneiras de o Swift ajudar você a fazer isso automaticamente.

No entanto, há muitas maneiras de codificar acidentalmente ciclos de retenção em seu aplicativo. Um ciclo de retenção significa que seu aplicativo sempre manterá a memória para um determinado trecho de código. Geralmente, isso acontece quando você tem duas coisas que têm indicadores fortes uma para a outra.

Para contornar isso, as pessoas costumam usar weak. Quando um lado do código é weak, você não tem um ciclo de retenção e seu aplicativo poderá liberar a memória.

Para nosso propósito, um padrão comum é usar [weak self] ao chamar a API. Isso garante que, assim que o manipulador de conclusão retornar algum código, o aplicativo possa liberar a memória.

fetchFilms { [weak self] (films) in
  // Seu código aqui
}

Fila de despacho (DispatchQueue, em inglês)

O Xcode usa diferentes threads para executar código em paralelo. A vantagem de vários threads está no fato de que você não fica parado esperando que uma coisa termine antes de passar para a próxima. Espero que você já esteja vendo a ligação com os manipuladores de conclusão aqui.

Esses threads também parecem ser chamados de filas de despacho. As chamadas de API são tratadas em uma fila – normalmente, uma fila em segundo plano. Depois de ter os dados de sua chamada de API, provavelmente você desejará mostrar esses dados ao usuário. Isso significa que você desejará atualizar sua visualização de tabela.

As exibições de tabela fazem parte da interface do usuário. Todas as manipulações da interface do usuário devem ser feitas na fila de despacho principal. Isso significa que, em algum lugar no seu arquivo de controlador de visualização, geralmente, como parte da função viewDidLoad, você deve ter um trecho de código que diga à sua visualização de tabela para atualizar.

Queremos que a visualização de tabela seja atualizada apenas quando tiver alguns novos dados da API. Isso significa que usaremos um manipulador de conclusão para nos avisar quando a chamada da API for concluída. Vamos esperar até esse aviso antes de atualizar a tabela.

O código será algo como:

fetchFilms { [weak self] (films) in
  self.films = films

  // Recarregar a visualização de tabela usando a fila de despacho principal
  DispatchQueue.main.async {
    tableView.reloadData()
  }
}

viewDidLoad x viewDidAppear

Finalmente, você precisa decidir onde chamar sua função fetchfilms. Ele estará dentro de um controlador (em inglês, controller) de visualização, que usará os dados da API. Existem dois lugares óbvios em que você pode fazer essa chamada de API. Um está dentro de viewDidLoad e o outro está dentro de viewDidAppear.

Esses são dois estados diferentes para seu aplicativo. Meu entendimento é o de que viewDidLoad é chamado na primeira vez em que você carrega essa visualização em primeiro plano. viewDidAppear é chamado toda vez que você volta a essa visualização, por exemplo, quando você pressiona o botão Voltar para voltar à visualização.

Se você espera que seus dados mudem entre os momentos em que o usuário navegará para e a partir dessa visualização, convém colocar sua chamada de API em viewDidAppear. No entanto, acho que para quase todos os aplicativos viewDidLoad é suficiente. A Apple recomenda viewDidAppear para todas as chamadas de API, mas isso parece um exagero. Imagino que isso tornaria seu aplicativo menos eficiente, pois está fazendo muito mais chamadas de API do que precisa.

Combinando todas as etapas

Primeiro: escreva a função que chama a API. Acima, essa função é a fetchFilms. Ela terá um manipulador de conclusão, que retornará os dados nos quais você está interessado. No meu exemplo, o manipulador de conclusão retorna um array de filmes.

Segundo: chame essa função em seu controlador de visualização. Você faz isso aqui porque deseja atualizar a visualização com base nos dados da API. No meu exemplo, estou atualizando uma visualização de tabela assim que a API retornar os dados.

Terceiro: decida onde em seu controlador de visualização você gostaria de chamar a função. No meu exemplo, eu chamo de viewDidLoad.

Quarto: decida o que fazer com os dados da API. No meu exemplo, estou atualizando uma visualização de tabela.

Dentro de NetworkManager.swift (esta função pode ser definida em seu controlador de visualização se você quiser, mas estou usando o padrão MVVM).

func fetchFilms(completionHandler: @escaping ([Film]) -> Void) {
    let url = URL(string: domainUrlString + "films/")!

    let task = URLSession.shared.dataTask(with: url, completionHandler: { (data, response, error) in
      if let error = error {
        print("Erro ao obter os filmes: \(error)")
        return
      }
      
      guard let httpResponse = response as? HTTPURLResponse,
            (200...299).contains(httpResponse.statusCode) else {
        print("Erro na responta. Código de status inesperado: \(response)")
        return
      }

      if let data = data,
        let filmSummary = try? JSONDecoder().decode(FilmSummary.self, from: data) {
        completionHandler(filmSummary.results ?? [])
      }
    })
    task.resume()
  }

Dentro de FilmsViewController.swift:

final class FilmsViewController: UIViewController {
  private var films: [Film]?

  override func viewDidLoad() {
    super.viewDidLoad()
    
    NetworkManager().fetchFilms { [weak self] (films) in
      self?.films = films
      DispatchQueue.main.async {
        self?.tableView.reloadData()
      }
    }
  }
  
  // o resto do código para o controlador de visualizações
}

Puxa, conseguimos! Obrigado por ficar comigo até o final da leitura.

Se essa publicação foi útil para você, compartilhe! Obrigada!