Já deve ter ouvido palavras como REST quando se trata de desenvolvimento de software. REST é uma arquitectura API muito comummente utilizada, e os programadores utilizam-na amplamente para conceber APIs de software. As interfaces de programação de aplicações são vitais para qualquer aplicação de software, e REST é uma das muitas arquitecturas que são utilizadas para APIs.
Hoje em dia, gRPC A arquitectura está a ganhar popularidade, e afirma também resolver alguns problemas tradicionalmente associados a REST APIs. Mas onde é que elas diferem? E qual delas deve ser utilizada na sua aplicação? Para conhecer a resposta a estas perguntas, precisamos de compreender mais sobre gRPC vs REST e em que cenários têm melhor desempenho. Mas antes de entrarmos em tudo isso, vejamos o que são APIs e o que trazem à mesa para microserviços.
O que é API?
As aplicações de software podem interagir e comunicar entre si através da utilização de interfaces de programação de aplicações - APIs, que funcionam como mediadores técnicos. Uma API está encarregada de enviar um pedido do utilizador ao sistema, que recebe então uma resposta do sistema.
Imagine que está a encomendar um telefone online. Vai a um site que está ligado à web, e envia informações sobre a sua consulta a um servidor. O servidor recebe então a informação, analisa-a e, depois de tomar as medidas necessárias, responde-nos com os detalhes exibidos no nosso ecrã. Isto torna-se possível com as APIs.
O API descreve como executar tais pedidos de clientes, quais as estruturas de dados a utilizar, e as normas que os clientes devem aderir. Também descreve os tipos de consultas que um programa pode enviar a outro. Ambos gRPC vs REST os estilos de arquitectura são amplamente utilizados para a concepção de APIs.
APIs e micro-serviços
As aplicações podem ter uma arquitectura monolítica ou uma arquitectura de microserviço. Todas as funções e módulos do software estão contidos numa única unidade ou base de código numa aplicação monolítica. Uma aplicação de microserviço, em contraste, consiste em numerosas unidades menores que interagem umas com as outras através de interfaces como o protocolo HTTP.
O principal problema com o estilo monolítico é que se torna mais difícil mudar, actualizar e expandir o sistema à medida que os engenheiros anexam novas funções e serviços acima da base pré-existente. Uma alteração a um aspecto da aplicação pode ter um efeito prejudicial sobre outras secções. O código de um monólito torna-se gradualmente tão entrelaçado e desafiante de compreender depois de ter sido escalado, actualizado e alterado inúmeras vezes, que é necessário um redesenho completo do sistema.
Esta questão é resolvida com microserviços. Este desenho arquitectónico divide um monólito nos seus componentes constituintes, cada um dos quais é depois executado como uma aplicação separada. Cada uma destas aplicações é chamada um micro-serviço. Em seguida, estes microserviços distintos ligam-se utilizando APIs. Esta colecção de microserviços ligados por APIs junta-se para construir um desenho arquitectónico maior. Os APIs permitem a ligação e comunicação entre cada componente incorporado numa arquitectura de microserviços. Algumas abordagens populares à criação de APIs são GraphQL, RPC, e REST.
O que é RPC?
Um RPC - Remote Procedure Call - é uma arquitectura web que lhe permite executar um serviço num servidor remoto usando um formulário predefinido e obter uma resposta com o mesmo formato. O estilo do servidor que executa a consulta, quer seja um servidor local ou remoto, não é considerado por RPC desenho.
Image Source itrelease.com/Author Junaid Rehman
A função básica de um RPC O pedido API é o mesmo que o de um REST API. O é o mesmo. RPC Os pedidos API especificam as directrizes interactivas e as técnicas que tornam a interacção possível. Mais tarde, o utilizador chama estas funções utilizando parâmetros. A cadeia de pedidos de URLs contém os parâmetros utilizados para chamar operações.
Para criar pedidos de API, a RPC utiliza uma estrutura cliente-servidor. RPC interpreta a informação que o utilizador solicita e transmite-a ao servidor. Enquanto as comunicações internas dentro dos servidores são ocultadas, o servidor responde ao utilizador. O RPC modelo também permite a um utilizador solicitar um serviço de uma determinada forma. RPC tem a vantagem de suportar chamadas de procedimento remoto tanto em cenários descentralizados como em locais.
O que é REST?
REST - Representational State Transfer - refere-se a uma arquitectura cliente-servidor na qual os utilizadores têm acesso a informação backend via JSON ou comunicação XML. Uma API é considerada RESTful se:
- Tem uma interface consistente e fornece recursos de aplicação particulares aos clientes API.
- O servidor e o cliente trabalham separada e independentemente. Apenas os URIs que apontam para os componentes da aplicação serão conhecidos pelo cliente.
- É apátrida. Isto significa que apenas o cliente guarda qualquer informação de estado. O servidor não guarda quaisquer dados de estado sobre a consulta do cliente.
- Os activos da aplicação que são fornecidos pela API devem ser armazenáveis.
- Tem uma arquitectura estratificada.
É uma aplicação de desenhos arquitectónicos contemporâneos que dependem de várias restrições para permitir a transmissão de dados em redes hipermedia. Uma API RESTful web precisa de argumentos codificados por URL para se ligar a serviços que utilizam protocolos HTTP. REST As APIs têm sido extensivamente abraçadas no design da web contemporânea para criar APIs sem estado, extensíveis, e fiáveis.
Cada componente que combina o sistema de microserviço pode ser apresentado ao utilizador ou cliente como um activo quando a API REST é tornada publicamente acessível. Este recurso pode ser consultado utilizando os comandos HTTP GET, POST, PUT e DELETE .
Como funciona o REST?
REST utiliza o protocolo HTTP como protocolo de comunicação padrão ao trabalhar com serviços que são especificados nos pedidos de API. Um recurso é uma coisa que é comparável a um objecto em design orientado para objectos. O recurso RESTful tem acções e atributos, muito semelhantes aos de um objecto. Em geral, as implementações REST normalmente dão menos atenção às acções RESTful e, em vez disso, concentram-se mais nos atributos de um recurso. As soluções RESTful são aquelas que apenas utilizam atributos para representar um recurso RESTful.
Numa API RESTful, o utilizador submete uma consulta a um URL - Uniform Resource Locator, o que provoca uma resposta com uma carga útil em JSON, XML, ou qualquer formato de dados suportado. Esta carga útil representa o recurso que o utilizador deseja. Os pedidos comuns de clientes incluem
- Um método HTTP que especifica o que deve ser processado no recurso
- O caminho do recurso
- O cabeçalho que tem dados sobre a consulta
- Uma carga útil de mensagem específica do cliente
No campo Aceitar do cabeçalho, o utilizador especifica os tipos de dados que é capaz de receber. Um cabeçalho do tipo conteúdo que identifica o formato de entrega da mensagem empregado no corpo de resposta é enviado pelo servidor API juntamente com a carga útil de dados que este entrega ao utilizador que faz a consulta. Um código de resposta que informa o utilizador do estado do resultado da chamada API é também incluído no corpo de resposta.
O que é gRPC?
gRPC - Google Remote Procedure Call - é um subtipo do desenho RPC. gRPC é uma arquitectura global de alto desempenho, de código aberto RPC que garante flexibilidade e rapidez para a arquitectura de micro-serviços. As chamadas de funções são utilizadas por gRPC para assegurar a interacção do cliente em microserviços criados utilizando várias linguagens de codificação.
Esta técnica implementa RPC pedidos de API utilizando a norma HTTP 2.0, mas nem o servidor nem o programador da API são informados do HTTP. Como resultado, a complicação é diminuída porque não há razão para se preocupar com a forma como os princípios RPC são traduzidos para HTTP.
O Google Remote Procedure Call procura acelerar a transferência de dados através de microserviços. Para permitir a devolução e chamada remota, baseia-se numa estratégia que identifica um serviço, estabelece as metodologias, e especifica as variáveis pertinentes.
Além disso, utiliza uma IDL - linguagem de descrição de interface - para especificar o paradigma RPC API, tornando mais simples a identificação de funções remotas. O IDL emprega Protocol Buffers por defeito para definir a interface do serviço e o formato das mensagens de carga útil.
Como é que a gRPC trabalho?
O protocolo HTTP/2, streaming, e buffers de protocolo ou protobufs são utilizados por gRPC APIs para transmitir mensagens. Uma norma de serialização chamada protobuf permite a criação automática de bibliotecas de utilizadores e a construção simples de microserviços. Em ficheiros protótipo, os desenhadores de API descrevem as operações e mensagens que são enviadas através de servidores e clientes.
O compilador protoc carrega os ficheiros e cria software de utilizador e servidor para a comunicação com serviços remotos. Em comparação com os formatos XML ou JSON, as mensagens encriptadas com buffers de protocolo são consideravelmente mais pequenas, tornando o processamento menos intensivo em CPU.
Além disso, utilizando HTTP/2, gRPC As APIs trazem várias melhorias ao design RPC. O protocolo acrescenta uma camada de formato binário que divide os pacotes em mensagens menores, em formato binário, tornando-os transportáveis e pequenos. A execução de muitas chamadas dentro de um único canal é possível graças ao suporte do HTTP/2 para múltiplas consultas simultâneas com a arquitectura de comunicação bidireccional.
O protocolo de transporte do HTTP/2 suporta múltiplos fluxos simultâneos, mas gRPC As APIs expandem esta funcionalidade através de canais. Cada canal pode acomodar vários canais que funcionam simultaneamente através de muitas ligações simultâneas. Os canais oferecem um método simples de ligação ao servidor API num determinado endereço e porta. Um stub de cliente também pode ser feito através de canais.
gRPC vs REST: comparação
Google criou gRPC como uma variante RPC para lidar com algumas das limitações dos estilos de arquitectura API existentes. Resolve alguns problemas associados a REST APIs, mas gRPC Os APIs enfrentam certos problemas devido ao facto de ser uma tecnologia mais recente. Há muitos casos de utilização em que REST APIs podem ser mais adequados à sua aplicação. Pode decidir qual destas APIs poderá funcionar melhor com o seu software, uma vez conhecidas as diferenças entre as duas.
HTTP 1.1 vs HTTP 2
A abordagem de resposta de pedidos utilizada por REST APIs é baseada principalmente em HTTP 1.1. Isto significa que o modelo deve processar cada consulta individualmente se um microserviço receber muitas consultas de múltiplos clientes, o que arrasta todo o sistema para baixo. REST As APIs podem ser desenvolvidas no HTTP 2, mas como a arquitectura de comunicação continua a responder a pedidos, não conseguem utilizar plenamente os benefícios do HTTP 2, incluindo a compatibilidade bidireccional e a interacção de streaming.
gRPC Os APIs não se deparam com este desafio. Aderem a um modelo de ligação de resposta ao cliente e baseiam-se no HTTP 2. gRPC pode aceitar muitas consultas de vários clientes e processar esses pedidos ao mesmo tempo através de informação em streaming. Estas circunstâncias permitem uma comunicação bidireccional com interacção em streaming. Além disso, gRPC suporta interacções unárias como as criadas por HTTP 1.1.
gRPC As APIs podem ser geridas:
- Interacções unárias
Se um cliente faz um único pedido, mas apenas uma resposta é dada em troca. - Servidor streaming
É conhecido como server streaming sempre que um servidor responde a uma consulta do cliente com um fluxo de mensagens. O servidor também envia uma mensagem de estado para encerrar o procedimento depois de fornecer todos os dados. - Client-streaming
Isto ocorre quando o cliente entrega uma sequência de mensagens, e o servidor responde com uma única mensagem. - Transmissão bidireccional
Isto permite a transmissão de dados de ambas as maneiras, porque os canais servidor e cliente são independentes um do outro.
Suporte de browsers
Uma vez que a maioria das interacções web API acontecem online, o suporte de browser é uma consideração chave no gRPC vs. REST debate. O apoio ao navegador é provavelmente um dos principais benefícios de REST APIs sobre gRPC. Todos os browsers oferecem REST completa capacidade de API e suporte de browser. A funcionalidade para gRPC em navegadores, no entanto, ainda é relativamente restrito. Infelizmente, as transições através de HTTP 1.1 e HTTP 2 necessitam da gRPC-web, bem como de uma camada de proxy. Como resultado, gRPC Os APIs tendem a acabar por ser utilizados principalmente para sistemas internos ou privados, por exemplo, em aplicações API utilizadas para a informação e funcionalidade de backend de organizações específicas.
Os fluxos multiplexados são utilizados com o protocolo HTTP/2. Como resultado, numerosos clientes podem enviar consultas em paralelo sem necessidade de abrir uma nova sessão TCP para cada um deles. Além disso, o servidor pode utilizar a ligação existente para entregar mensagens aos clientes.
O modelo de transferência do estado representativo tem um amplo suporte de browser porque integra o HTTP 1.1. O HTTP 1.1, que permite REST, utiliza um método de aperto de mão TCP para cada consulta. REST Os APIs têm frequentemente problemas de latência como resultado, uma vez que o aperto de mão leva tempo.
Estrutura de dados de carga útil
Se olharmos para a estrutura de dados da carga útil ao mesmo tempo que olhamos para gRPC vs REST, gRPC As APIs efectuam a carga de dados em série utilizando Protocol Buffers por desenho. Este método é mais leve, pois torna as mensagens mais pequenas e permite uma estrutura altamente comprimida. Os Protocol Buffers estão em formato binário; portanto, para a troca de dados, ele serializa e desserializa a informação. O Protobuf pode traduzir automaticamente mensagens fortemente escritas para as linguagens de programação do cliente e do servidor.
RESTNo entanto, utiliza principalmente JSON ou formulários XML para entregar e receber informação. JSON é o formato mais utilizado devido à sua adaptabilidade e capacidade de comunicar dados dinâmicos sem aderir a uma estrutura precisa, embora não exija nenhuma. A qualidade de leitura humana do JSON, que o Protobuf ainda não consegue igualar, é outra vantagem importante.
JSON não é, contudo, tão rápida ou leve uma vez que envolve a transferência de dados. Isto deve-se ao requisito de que JSON deve ser serializado e traduzido para as linguagens de programação utilizadas tanto no servidor como no cliente quando se utiliza REST. Esta é uma etapa adicional no processo de transmissão de dados, que poderia prejudicar a eficiência e aumentar a probabilidade de erros.
Geração de código
Os engenheiros devem empregar ferramentas de terceiros como o carteiro para a geração de código para consultas API, uma vez que, e ao contrário de gRPC, a API REST carece de instalações de geração de código incorporadas. Em oposição a isto, gRPC oferece características de geração de código nativo devido ao seu compilador protoc, que suporta muitas linguagens de programação. A geração de código é especialmente vantajosa para microserviços que combinam numerosos serviços criados em múltiplas plataformas e linguagens. Em geral, a sua geração de código incorporado torna a construção do kit de desenvolvimento de software - SDK - mais fácil.
REST A API, por outro lado, não fornece características de geração de código nativo. É necessário utilizar um programa de terceiros para produzir a geração de código para chamadas API em várias línguas. Embora não seja um incómodo, é importante notar que gRPC não depende de quaisquer outros serviços para a geração de códigos.
Quando utilizar REST APIs
Ao comparar gRPC vs REST, as APIs mais amplamente utilizadas e mais apreciadas para integrar infra-estruturas construídas sobre microserviços são REST APIs. REST É provável que as APIs continuem a ser a opção padrão para ligação de aplicações durante muito tempo, independentemente de estar a criar uma rede interna ou uma plataforma aberta que abra os seus activos para o resto do mundo. REST As APIs são também perfeitas para sistemas que requerem iteração rápida e normas de protocolo HTTP.
REST As APIs podem ser a sua primeira escolha para o desenvolvimento de serviços web, microserviços e interfaces de aplicação porque as tecnologias de terceiros as suportam universalmente. Ao contrário de gRPCtem um amplo suporte de navegação e não se limita aos sistemas privados. Isto pode tornar REST APIs muito úteis em muitos contextos.
É também mais fácil de aprender REST, pois tem uma vasta gama de documentação API disponível na Internet. Esta curva de aprendizagem mais simples é muito importante se se estiver numa crise de tempo. Pode poupar muito tempo a pesquisar e aprender e começar a implementar imediatamente. As APIs RESTful são também mais fáceis de integrar em aplicações. Oferecem também uma melhor escalabilidade. Se quiser expandir a sua aplicação em breve, talvez seja melhor utilizar REST APIs. A falta de estado e confidencialidade pode causar problemas com a transferência do estado representativo em certas aplicações. Se a sua aplicação tem uma opção de pagamento, gRPC pode ser uma opção melhor.
Quando utilizar gRPC APIs
Em ambos gRPC vs REST, a maioria das ferramentas de terceiros ainda não fornecem funcionalidade integrada para gRPC conformidade. Como resultado, gRPC Os APIs são principalmente utilizados para criar sistemas ou estruturas internas inacessíveis a utilizadores externos. Com essa qualificação em mente, as seguintes situações poderiam fazer uso de gRPC APIs:
- Ligações Microservices
gRPC Os APIs são especialmente úteis para ligar arquitecturas constituídas por microserviços ligeiros onde a eficácia da entrega de mensagens é crucial devido à sua baixa latência e comunicação rápida de largura de banda.
- Sistemas multi-linguísticos
gRPC distingue-se no tratamento de comunicações num contexto poliglota, graças à sua capacidade de geração de código nativo para uma vasta gama de linguagens de programação.
- Transmissão em tempo real
Se a comunicação em tempo real for necessária, o seu sistema pode transmitir e receber dados em tempo real sem ter de esperar pela interacção Unary Client-response, graças à capacidade do gRPC para lidar com o fluxo bidireccional.
- Redes de baixa potência e baixa largura de banda
Tais redes podem beneficiar da utilização do gRPC de sessões de Protobuf seriadas, uma vez que proporcionam comunicação leve, maior eficiência, e rapidez. Por exemplo, uma rede que lucraria com o gRPC API é a Internet das Coisas.
Como é que AppMaster ajuda?
A programação mudou muito nas últimas décadas, com novas tecnologias e estruturas que facilitam as tarefas dos programadores. A geração No-code leva isto para o nível seguinte. As pessoas não têm de passar por curvas de aprendizagem íngremes e podem desenvolver aplicações mais rapidamente com no-code plataformas como AppMaster.
AppMaster ajuda-o a criar código fonte a partir do zero, de acordo com as necessidades específicas da sua aplicação. O código gerado pertencerá a si, e poderá modificá-lo de acordo com as suas necessidades. Pode criar os vários módulos que a sua aplicação necessita com AppMaster. Isto é muito menos dispendioso e demorado do que conseguir que toda uma equipa de desenvolvimento faça o mesmo.
Os programadores podem enviar consultas entre a arquitectura backend dos microserviços utilizando a gRPC protocolo utilizando a plataforma geradora do AppMaster no-code. Acrescentaremos API a ambos gRPC desenvolvimento de serviços web, bem como gRPC aplicações móveis no ano seguinte para aumentar gRPC apoio.
Conclusão
A transferência representativa do estado foi a abordagem a seguir quando se tratou do desenvolvimento de API no passado. Mas entre gRPC vs REST, gRPC Os APIs estão lentamente a tornar-se mais populares. Apesar das várias características que o fazem sobressair, alguns problemas, como a falta de suporte de browser e documentação API, tornam difícil a sua utilização em todo o lado. No entanto, com os avanços tecnológicos e o crescimento da comunidade, podemos esperar que gRPC vencerá os desafios actuais.
Finalmente, a escolha entre REST ou gRPCou mesmo qualquer das outras metodologias API como GraphQL ou SOAP, depende das necessidades específicas do seu projecto. Algumas aplicações podem precisar dos benefícios que gRPC oferece, enquanto outros podem exigir a funcionalidade básica que REST oferece. É necessário avaliar as funções da sua aplicação e utilizar casos para escolher entre estas duas tecnologias capazes.
