Na indústria , as integrações desempenham um papel fundamental no design de aplicativos. Uma das principais tecnologias para isso é a . O conhecimento da API REST é uma habilidade importante para todo especialista em tecnologia. Neste artigo, apresentaremos 25 perguntas sobre API REST que ajudarão você a se preparar para uma entrevista de emprego e a aprimorar suas habilidades. Gostar de ler! de desenvolvimento de software API REST Em primeiro lugar, o entrevistador costuma dividir as questões sobre API REST em teóricas e práticas. Primeiro, eles fazem 2 a 3 perguntas teóricas sobre terminologia e métodos de solicitação HTTP e, em seguida, você recebe uma tarefa prática sobre como redigir uma solicitação. Este artigo contém perguntas teóricas frequentes e pretendo publicar exemplos de tarefas práticas relacionadas à API REST no próximo artigo. Não sabemos com antecedência quais perguntas você receberá em uma entrevista, mas tenho certeza de que, no processo de trabalhar em nossa lista de perguntas típicas, você provavelmente se aprofundará no tópico e aprimorará seu conhecimento sobre a API REST em qualquer caso. Agora, vamos do simples ao complexo, começando com a terminologia básica e continuando com uma seção com questões mais complexas. 1. O que é REST? Resposta: Existem três termos usados quando se refere a REST que muitas vezes são considerados a mesma coisa, mas isso não é inteiramente verdade. Esses termos são REST, API REST e API RESTful. Agora haverá uma resposta sobre REST, o termo significa Representational State Transfer e é um estilo de arquitetura baseado no protocolo HTTP (Hypertext Transfer Protocol) para desenvolvimento de aplicações que possuem front-end e/ou integração com sistemas externos. REST descreve diretrizes que os serviços de API projetados devem seguir. Esses princípios garantem que as solicitações sejam transmitidas entre cliente e servidor usando HTTP. 2. O que é API REST? Resposta: Uma API é uma interface de programação que permite que aplicativos individuais se comuniquem e troquem dados. Por exemplo, um aplicativo de entrega de comida pode usar a API do Google Maps para rastrear a localização do entregador e exibi-la em um mapa. Uma API REST é uma API que segue os princípios do REST, tratando todos os dados como recursos, cada um representado por um URI (Uniform Resource Identifier) exclusivo. 3. O que é uma API RESTful? Resposta: Uma API RESTful é uma API projetada de acordo com as regras (ou você também pode dizer “princípios”) do REST. Em outras palavras, a diferença entre API REST e API RESTful é terminológica. O primeiro caso refere-se a um conjunto de regras REST, e o segundo refere-se à implementação de uma API específica seguindo regras REST. O termo API RESTful é frequentemente substituído por API REST ou mesmo REST apenas por uma questão de brevidade. Quando os analistas de sistema desenham setas rotuladas como REST em um diagrama de aplicativo, eles significam uma API RESTful. 4. Quais são os dois princípios básicos do REST? Resposta: As solicitações da API REST devem seguir dois princípios básicos: Separação em cliente e servidor: A interação entre o cliente e o servidor é realizada na forma de solicitações e respostas. Somente clientes podem fazer solicitações e somente servidores podem enviar respostas para funcionarem independentemente uns dos outros. Protocolo único: A interação entre cliente e servidor deve ser realizada por meio de um único protocolo. Para REST, este protocolo é HTTP. 5. Que outros princípios de REST você conhece? Resposta: Você pode citar pelo menos mais 4 princípios. As solicitações da API REST não armazenam estado no servidor e podem passar por camadas de servidores e serem armazenadas em cache. Você também pode enviar código executável aos clientes na resposta do servidor. Servidor sem estado: O servidor não armazena nenhuma informação sobre solicitações/respostas anteriores. Cada solicitação e resposta contém todas as informações necessárias para concluir a interação. A comunicação sem estado reduz a carga do servidor, economiza memória e melhora o desempenho. Sistema em camadas: Servidores adicionais são possíveis entre o cliente e o servidor API na forma de camadas para executar diferentes funções. Em um sistema construído com base nos princípios REST, as camadas são modulares e podem ser adicionadas e removidas sem afetar as comunicações entre o cliente e o servidor. Capacidade de cache: as respostas do servidor indicam se seu recurso pode ser armazenado em cache para que os clientes possam armazenar qualquer recurso em cache para melhorar o desempenho. Código sob demanda: O servidor pode enviar código executável aos clientes em sua resposta para execução no aplicativo cliente. 6. O que é um recurso? Resposta: Em REST, todo objeto acessível no lado do servidor é designado como um recurso. Um recurso é um objeto que possui um tipo, dados associados a ele, um relacionamento com outros recursos no servidor e uma lista de métodos que podem ser usados para trabalhar com ele. Por exemplo, um recurso pode ser um arquivo HTML ou de texto, um arquivo de dados, uma imagem ou vídeo ou um arquivo de código executável. Um recurso é identificado por um Identificador Uniforme de Recursos ou URI. Os clientes acessam recursos usando seus URIs em solicitações HTTP. 7. O que é uma URL? Resposta: URI significa Identificador Uniforme de Recursos. Esta é uma string que identifica um recurso no servidor. Cada recurso possui seu próprio URI exclusivo, que, quando incluído em uma solicitação HTTP, permite que os clientes acessem e executem ações nesse recurso. O processo de referência a um recurso por seu URI é chamado de “endereçamento”. 8. O que é CRUD? Resposta: CRUD significa "Criar, Ler, Atualizar, Excluir". Estas são as quatro principais ações que podem ser executadas em bancos de dados por meio da API REST. Cada ação tem seu próprio método de solicitação HTTP: Criar = POSTAR Ler = OBTER Atualizar = COLOCAR Excluir = EXCLUIR 9. O que significa carga útil na resposta do servidor? Resposta: A carga útil da resposta HTTP refere-se aos dados do recurso que foram solicitados pelo cliente. Isso também é brevemente chamado de "carga útil de resposta HTTP". Esses dados podem estar em JSON, XML, HTML, imagens, arquivos e assim por diante, dependendo exatamente do que o servidor fornece. 10. O que são mensagens REST? Resposta: Mensagens em REST referem-se à troca de mensagens entre o cliente e o servidor. A comunicação sempre começa com o cliente fazendo uma solicitação HTTP ao servidor. O servidor processa essa solicitação e, em seguida, envia de volta uma resposta HTTP que indica o status da solicitação e quaisquer recursos solicitados pelo cliente. 11. O que é um corretor de mensagens em REST? Resposta: No contexto do REST, o termo “corretor de mensagens” é um middleware que serve para passar mensagens entre vários componentes ou sistemas em uma aplicação distribuída. O broker pode fornecer troca assíncrona de dados, enfileiramento de mensagens e processamento de mensagens entre vários módulos do sistema. Os corretores de mensagens podem ser usados para gerenciar operações assíncronas ou enviar notificações. O agente de mensagens não é um elemento REST nativo porque... REST se concentra na comunicação síncrona entre cliente e servidor usando solicitações HTTP. 12. Quais métodos de solicitação HTTP são suportados pelo REST? Resposta: O método de solicitação HTTP especifica a ação desejada que o servidor executará no recurso. Em REST, existem quatro métodos principais para fazer solicitações HTTP de um cliente para um servidor: GET: Solicita um recurso do servidor, este método é somente leitura. POST: Cria um novo recurso no servidor. PUT: Atualiza um recurso existente no servidor. DELETE: Exclui um recurso do servidor. 13. Qual é a diferença entre os métodos POST e PUT? Resposta: POST serve para criar um recurso no servidor, enquanto PUT serve para substituir um recurso em um URI específico por outro recurso. Se você usar PUT em um URI que já possui um recurso associado, PUT o substituirá. Se não houver recurso no URI especificado, PUT cria um. PUT é idempotente, o que significa que chamá-lo várias vezes resultará na criação de apenas um recurso. Isso acontece porque cada chamada substitui um recurso existente (ou cria um novo se não houver nada para substituir). POST não é idempotente. Se, por exemplo, você chamar POST 10 vezes, serão criados 10 recursos diferentes no servidor, cada um com seu próprio URI. Embora raramente usadas, as respostas POST podem ser armazenadas em cache, mas as respostas PUT não. As solicitações POST geralmente são consideradas não armazenáveis em cache, mas podem ser armazenadas em cache quando contêm informações claras sobre a “atualidade” dos dados. Uma resposta mais detalhada é que a resposta para uma solicitação POST (ou PATCH) pode ser armazenada em cache se os dados forem "frescos" e o cabeçalho Content-Location (en-US) estiver definido, mas isso raramente é implementado. Portanto, o cache POST deve ser evitado, se possível. 14. Quais são as principais partes de uma solicitação HTTP? Resposta: Em REST, existem os seguintes componentes básicos de uma solicitação HTTP: O método de solicitação que será feito ao recurso (ou seja, GET, POST, PUT, DELETE). Um URI que identifica o recurso solicitado no servidor. Versão HTTP – ou seja, qual versão deve estar na resposta do servidor. O cabeçalho da solicitação HTTP contém metadados sobre a solicitação, como agente do usuário, formatos de arquivo aceitos pelo cliente, formato do corpo da solicitação, idioma, preferências de cache, etc. O corpo de uma solicitação HTTP contém todos os dados associados à solicitação . Isso só é necessário se a solicitação for para alterar dados no servidor usando os métodos POST ou PUT. 15. Quais são as principais partes de uma resposta HTTP? Responda: As respostas HTTP são enviadas do servidor para o cliente. Informam ao cliente que a ação solicitada foi (ou não) concluída e a entrega dos recursos solicitados. Existem quatro componentes principais de uma resposta HTTP: Versão HTTP usada. Barra de status com status da solicitação e código de status da resposta HTTP. Cabeçalho de resposta HTTP com metadados sobre a resposta, incluindo hora, nome do servidor, agente do usuário, formatos de arquivo de recursos retornados e informações de cache. Corpo da resposta HTTP contendo dados sobre o recurso solicitado pelo cliente 16. Cite pelo menos 3 códigos para respostas bem-sucedidas do servidor HTTP Resposta: O servidor retorna os seguintes códigos de status de operação quando a solicitação é processada com sucesso: 200 OK: A solicitação foi concluída com sucesso. 201 Criado: a solicitação foi bem-sucedida e o recurso foi criado. 202 Aceito: Este status significa que o servidor aceitou a solicitação do cliente, mas não concluiu o processamento. O processamento pode ser assíncrono. 17. Cite pelo menos 4 códigos de resposta HTTP do servidor ao redirecionar uma solicitação Resposta: O servidor retorna os seguintes códigos de status ao redirecionar uma solicitação: 301 Movido Permanentemente: Este status informa ao cliente que o recurso solicitado foi movido permanentemente para outra URL e o cliente deve acessar a nova URL para acessar o recurso. 302 Encontrado: Este status indica que o recurso foi movido temporariamente para outra URL e o cliente deve usar temporariamente a nova URL. Redirecionamento Temporário 307: Semelhante ao 302, mas o cliente deve usar o mesmo método de solicitação ao acessar a nova URL. Redirecionamento Permanente 308: Semelhante ao 301, mas o cliente deve usar o mesmo método de solicitação ao acessar a nova URL 18. Cite pelo menos 4 códigos para respostas malsucedidas do servidor HTTP. Resposta: O servidor retorna os seguintes códigos quando a solicitação não é bem-sucedida: 400 Solicitação incorreta: a solicitação não foi concluída devido a um erro na solicitação, como erro de digitação ou falta de dados. 401 Não autorizado: A solicitação não foi concluída porque o cliente não está autenticado ou não tem permissão para acessar o recurso solicitado. 403 Proibido: A solicitação não foi concluída porque o cliente está autenticado, mas não autorizado a acessar o recurso solicitado. 404 Not Found: A solicitação não foi concluída porque o servidor não conseguiu encontrar o recurso solicitado. 19. Cite pelo menos 3 códigos de erro do servidor. Responda: O servidor retorna os seguintes códigos quando há um erro no servidor: 500 Erro interno do servidor: a solicitação não foi concluída devido a um problema inesperado com o servidor. 502 Bad Gateway: A solicitação não foi concluída devido a uma resposta incorreta do servidor upstream. 503 Serviço indisponível: O servidor não conseguiu processar a solicitação devido a manutenção, sobrecarga ou outros distúrbios temporários. Você pode encontrar uma lista dos códigos HTTP mais comuns aqui 20. Qual é a diferença entre REST e GraphQL Resposta: GraphQL é uma linguagem de consulta que permite aos clientes consultar apenas os dados de que precisam. No GraphQL, o cliente define a estrutura e o formato dos dados que deseja receber, e o servidor os retorna de acordo com essa solicitação. A principal diferença é que o REST possui um formato fixo de solicitação e resposta para cada recurso, enquanto o GraphQL permite que os clientes definam sua solicitação e obtenham apenas as informações de que precisam, tornando-o mais eficiente e flexível de usar. 21. Qual é a diferença entre REST e SOAP? Resposta: REST e SOAP (Simple Object Access Protocol) são duas abordagens para construir APIs. Existem 3 diferenças principais entre eles: SOAP é um protocolo estrito para construção de APIs seguras. REST não é um protocolo, mas um estilo arquitetônico ditado por um conjunto de diretrizes chamadas princípios REST. - As APIs REST são mais simples de construir, mais leves e geralmente mais rápidas que as APIs SOAP. As APIs SOAP são consideradas mais seguras que as APIs REST, embora as APIs REST ainda possam implementar recursos de segurança para torná-las bastante seguras. - REST permite que as respostas sejam armazenadas em cache, enquanto o SOAP não. SOAP codifica dados em formato XML. - REST permite codificar dados em qualquer formato, embora XML e JSON sejam os mais populares. 22. Qual é a diferença entre REST e AJAX? Resposta: JavaScript assíncrono ou AJAX é um conjunto de tecnologias de desenvolvimento web usadas em aplicações web. Basicamente, o AJAX permite que uma página da Web faça solicitações ao servidor e atualize a interface da página sem precisar atualizar a página inteira. Um cliente AJAX pode usar a API REST em suas solicitações, mas o AJAX não precisa funcionar apenas com a API REST. APIs REST podem se comunicar com qualquer cliente, quer ele use AJAX ou não. Ao contrário do REST, que usa solicitações e respostas HTTP para trocar mensagens, o AJAX envia suas solicitações ao servidor usando o objeto XMLHttpRequest integrado ao JavaScript. As respostas do servidor são executadas pelo código JavaScript da página para alterar seu conteúdo. 23. Qual é a abordagem “Contrato Primeiro” para o desenvolvimento da API REST? Resposta: A abordagem Contract First para o desenvolvimento da API REST é uma metodologia na qual a especificação e o contrato da API são criados e definidos antes do início do desenvolvimento real. Este contrato serve como um importante documento que define como os clientes podem interagir com a API e quais resultados esperados serão obtidos nas diversas solicitações. 24. Quais são os benefícios do Contract First? Resposta: As seguintes vantagens da abordagem Contract First podem ser mencionadas: Definição clara da API: a especificação e o contrato da API definem como a API deve interagir com os clientes. Reduza riscos: a aprovação preliminar do contrato com os clientes ajuda a reduzir o risco de mal-entendidos e falha no atendimento às expectativas de desenvolvimento de API. Documentação aprimorada: O texto do contrato geralmente serve como documentação para a API, facilitando seu uso e integração. 25. Qual é a abordagem Code First para o desenvolvimento da API REST? Resposta: A abordagem Code First para o desenvolvimento da API REST é uma metodologia na qual a funcionalidade da API é desenvolvida primeiro e, em seguida, uma especificação da API é gerada automaticamente com base nessa funcionalidade. A marca registrada da abordagem Code First é que os desenvolvedores se concentram em escrever a lógica da API e usam ferramentas que lhes permitem criar automaticamente documentação e especificações com base nessa lógica. Em geral, ambas as abordagens, Code First e Contract First, podem ser combinadas no mesmo projeto de desenvolvimento de API. Neste caso, Code First é usado para prototipagem rápida, seguido de Contract First para formalizar o contrato. Espero que este artigo seja útil para você na preparação para uma entrevista de emprego ou para atualizar seu conhecimento sobre a API REST.
