{"id":30792,"date":"2019-10-31T21:37:27","date_gmt":"2019-10-31T18:37:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/nash-opyt-sozdaniya-api-gateway\/"},"modified":"2019-10-31T21:37:27","modified_gmt":"2019-10-31T18:37:27","slug":"nash-opyt-sozdaniya-api-gateway","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","title":{"rendered":"Nossa experi\u00eancia na cria\u00e7\u00e3o de um API Gateway","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Algumas empresas, incluindo nosso cliente, desenvolvem produtos por meio de uma rede de parceiros. Por exemplo, grandes lojas online est\u00e3o integradas com servi\u00e7os de entrega \u2014 voc\u00ea faz um pedido e logo recebe um n\u00famero de rastreamento do pacote. Outro exemplo \u00e9 que, junto com o bilhete a\u00e9reo, voc\u00ea compra um seguro ou um bilhete para o aerotrem.<\/p>\n<p>Para isso, utilizamos uma API, que deve ser disponibilizada para os parceiros atrav\u00e9s do API Gateway. Essa foi a tarefa que realizamos. Neste artigo, falaremos os detalhes.<\/p>\n<p>Dado: um ecossistema e um portal de API com uma interface onde os usu\u00e1rios est\u00e3o registrados, recebem informa\u00e7\u00f5es, etc. Precisamos criar um API Gateway conveniente e confi\u00e1vel. No processo, precis\u00e1vamos garantir <\/p>\n<ul>\n<li>o registro, <\/li>\n<li>o controle de conex\u00e3o \u00e0 API, <\/li>\n<li>o monitoramento de como os usu\u00e1rios utilizam o sistema final, <\/li>\n<li>o acompanhamento de indicadores de neg\u00f3cios.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Nossa experi\u00eancia na cria\u00e7\u00e3o de um API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/4fa66fd4573af16b0bc78aa61173f907.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNeste artigo, compartilharemos nossa experi\u00eancia na cria\u00e7\u00e3o de um API Gateway, na qual resolvemos as seguintes tarefas:<\/p>\n<ul>\n<li>a autentica\u00e7\u00e3o do usu\u00e1rio,<\/li>\n<li>a autoriza\u00e7\u00e3o do usu\u00e1rio,<\/li>\n<li>a modifica\u00e7\u00e3o da solicita\u00e7\u00e3o de entrada,<\/li>\n<li>o proxypassing da solicita\u00e7\u00e3o,<\/li>\n<li>o p\u00f3s-processamento da resposta.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nExistem dois tipos de gerenciamento de API:<\/p>\n<p>1. O padr\u00e3o, que funciona da seguinte forma. Antes de se conectar, o usu\u00e1rio testa as funcionalidades, depois paga e integra em seu site. \u00c9 mais comumente utilizado por pequenas e m\u00e9dias empresas.<\/p>\n<p>2. O gerenciamento de API B2B em grande escala, onde a empresa primeiro toma uma decis\u00e3o de neg\u00f3cios sobre a conex\u00e3o, torna-se parceira da empresa com um compromisso contratual, ap\u00f3s o que se conecta \u00e0 API. E somente depois de resolver todas as formalidades, a empresa obt\u00e9m acesso de teste, passa por testes e entra em produ\u00e7\u00e3o. Mas isso n\u00e3o \u00e9 poss\u00edvel sem a decis\u00e3o gerencial sobre a conex\u00e3o. <\/p>\n<p><img decoding=\"async\" alt=\"Nossa experi\u00eancia na cria\u00e7\u00e3o de um API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b9ab53d6c64d5a971c4950cd340ad42e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3> Nossa solu\u00e7\u00e3o<\/h3>\n<p>\nNesta parte, falaremos sobre a cria\u00e7\u00e3o do API Gateway.<\/p>\n<p>Os usu\u00e1rios finais do gateway de API criado s\u00e3o os parceiros de nosso cliente. Para cada um deles, j\u00e1 armazenamos os contratos necess\u00e1rios. Precisamos apenas expandir a funcionalidade, marcando o acesso fornecido ao gateway. Portanto, \u00e9 necess\u00e1rio um processo controlado de conex\u00e3o e gest\u00e3o.<\/p>\n<p>Sem d\u00favida, poder\u00edamos ter adotado uma solu\u00e7\u00e3o pronta para resolver a tarefa de gerenciamento de API e a cria\u00e7\u00e3o do API Gateway em particular. Por exemplo, uma dessas solu\u00e7\u00f5es poderia ser<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/api-management\/\"> Azure API Management<\/a><\/noindex>. N\u00e3o funcionou para n\u00f3s, porque j\u00e1 t\u00ednhamos um portal API e uma grande ecossistema constru\u00eddo ao redor dele. Todos os usu\u00e1rios j\u00e1 estavam registrados, eles j\u00e1 entendiam onde e como poderiam obter as informa\u00e7\u00f5es necess\u00e1rias. No portal API j\u00e1 existiam as interfaces necess\u00e1rias, s\u00f3 precis\u00e1vamos do API Gateway. Na verdade, foi isso que come\u00e7amos a desenvolver. <\/p>\n<p>O que chamamos de API Gateway \u00e9 uma esp\u00e9cie de proxy. Novamente, tivemos a escolha \u2014 pod\u00edamos escrever nosso pr\u00f3prio proxy ou optar por algo j\u00e1 pronto. Neste caso, optamos pela segunda op\u00e7\u00e3o e escolhemos a combina\u00e7\u00e3o nginx+Lua. Por qu\u00ea? Precis\u00e1vamos de um software confi\u00e1vel e testado que suportasse escalabilidade. N\u00e3o quer\u00edamos, ap\u00f3s a implementa\u00e7\u00e3o, verificar tanto a l\u00f3gica de neg\u00f3cios quanto a funcionalidade do proxy. <\/p>\n<p>Qualquer servidor web tem um pipeline de processamento de solicita\u00e7\u00f5es. No caso do nginx, ele se apresenta da seguinte forma:<\/p>\n<p><img decoding=\"async\" alt=\"Nossa experi\u00eancia na cria\u00e7\u00e3o de um API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b4cba1d37cc769202f92df052b45c77e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n(diagrama de <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">GitHub Lua Nginx<\/a><\/noindex>)<\/p>\n<p>Nosso objetivo era nos integrar a esse pipeline no momento em que pud\u00e9ssemos modificar a solicita\u00e7\u00e3o original. <\/p>\n<p>Queremos criar um proxy transparente, para que a solicita\u00e7\u00e3o funcional permane\u00e7a como chegou. Apenas controlamos o acesso \u00e0 API final, ajudando a solicita\u00e7\u00e3o a chegar at\u00e9 ela. Caso a solicita\u00e7\u00e3o seja incorreta, o erro deve ser retornado pela API final, e n\u00e3o por n\u00f3s. A \u00fanica raz\u00e3o pela qual podemos rejeitar uma solicita\u00e7\u00e3o \u00e9 devido \u00e0 falta de acesso do cliente. <\/p>\n<p>J\u00e1 existe um <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">extens\u00e3o<\/a><\/noindex> para <noindex><a rel=\"nofollow\" href=\"http:\/\/www.lua.ru\/\">Lua<\/a><\/noindex>. Lua \u00e9 uma linguagem de script, muito leve e f\u00e1cil de aprender. Assim, implementamos a l\u00f3gica necess\u00e1ria usando Lua. <\/p>\n<p>A configura\u00e7\u00e3o do nginx (uma analogia ao route de um aplicativo), onde toda a opera\u00e7\u00e3o \u00e9 realizada, \u00e9 bastante compreens\u00edvel. O destaque aqui \u00e9 a \u00faltima diretiva \u2014 post_action.<\/p>\n<pre><code class=\"nginx\">location \/middleware {\n      more_clear_input_headers Accept-Encoding;\n      lua_need_request_body on;\n      rewrite_by_lua_file 'middleware\/rewrite.lua';\n      access_by_lua_file 'middleware\/access.lua';\n      proxy_pass https:\/\/someurl.com;\n      body_filter_by_lua_file 'middleware\/body_filter.lua';\n      post_action \/process_session;\n}\n<\/code><\/pre>\n<p>\nVamos analisar o que acontece nesta configura\u00e7\u00e3o: <br \/>\n<b>more_clear_input_headers<\/b> \u2014 limpa o valor dos cabe\u00e7alhos especificados ap\u00f3s a diretiva. <br \/>\n<b>lua_need_request_body <\/b>\u2014 define se deve ler o corpo original da solicita\u00e7\u00e3o antes de executar as diretivas rewrite\/access\/access_by_lua ou n\u00e3o. Por padr\u00e3o, o nginx n\u00e3o l\u00ea o corpo da solicita\u00e7\u00e3o do cliente, e se voc\u00ea precisar acess\u00e1-lo, esta diretiva deve estar definida como on.<br \/>\n<b>rewrite_by_lua_file<\/b> \u2014 caminho at\u00e9 o script que descreve a l\u00f3gica para modificar a solicita\u00e7\u00e3o<br \/>\n<b>access_by_lua_file <\/b>\u2014 caminho at\u00e9 o script que descreve a l\u00f3gica que verifica a presen\u00e7a de acesso ao recurso. <br \/>\n<b>proxy_pass <\/b>\u2014 url para o qual a solicita\u00e7\u00e3o ser\u00e1 proxy.<br \/>\n<b>body_filter_by_lua_file <\/b>\u2014 caminho at\u00e9 o script que descreve a l\u00f3gica para filtrar a solicita\u00e7\u00e3o antes de retorn\u00e1-la ao cliente.<br \/>\nE, finalmente, <b>post_action<\/b> \u2014 uma diretiva oficialmente n\u00e3o documentada, que permite realizar outras a\u00e7\u00f5es ap\u00f3s a resposta ter sido enviada ao cliente. <\/p>\n<p>A seguir, explicaremos em ordem como resolvemos nossas tarefas.<\/p>\n<h3>Autoriza\u00e7\u00e3o\/autentica\u00e7\u00e3o e modifica\u00e7\u00e3o da solicita\u00e7\u00e3o<\/h3>\n<p>\n<b>Autoriza\u00e7\u00e3o<\/b><\/p>\n<p>Constru\u00edmos a autoriza\u00e7\u00e3o e autentica\u00e7\u00e3o por meio de acessos por certificado. Existe um certificado raiz. Para cada novo cliente do contratante, \u00e9 gerado um certificado pessoal, com o qual ele pode acessar a API. Este certificado \u00e9 configurado na se\u00e7\u00e3o server das configura\u00e7\u00f5es do nginx.<\/p>\n<pre><code class=\"nginx\">ssl on;\nssl_certificate \/usr\/local\/openresty\/nginx\/ssl\/cert.pem;\nssl_certificate_key \/usr\/local\/openresty\/nginx\/ssl\/cert.pem;\nssl_client_certificate \/usr\/local\/openresty\/nginx\/ssl\/ca.crt;\nssl_verify_client on;<\/code><\/pre>\n<p>\n<b>Modifica\u00e7\u00e3o<\/b><\/p>\n<p>Uma pergunta justa pode surgir: o que fazer com um cliente certificado, se de repente quisermos desconect\u00e1-lo do sistema? N\u00e3o vamos emitir novos certificados para todos os outros clientes. <\/p>\n<p>Assim, chegamos suavemente \u00e0 pr\u00f3xima tarefa \u2014 a modifica\u00e7\u00e3o da solicita\u00e7\u00e3o original. A solicita\u00e7\u00e3o original do cliente, em geral, n\u00e3o \u00e9 v\u00e1lida para o sistema final. Um dos objetivos \u00e9 adicionar as partes faltantes \u00e0 solicita\u00e7\u00e3o para torn\u00e1-la v\u00e1lida. A quest\u00e3o \u00e9 que os dados ausentes s\u00e3o diferentes para cada cliente. Sabemos que o cliente nos apresenta um certificado, do qual podemos extrair a impress\u00e3o digital e obter os dados necess\u00e1rios do cliente do banco de dados. <\/p>\n<p>Se em algum momento for necess\u00e1rio desconectar o cliente do nosso servi\u00e7o, seus dados desaparecer\u00e3o do banco de dados e ele n\u00e3o poder\u00e1 fazer nada. <\/p>\n<h3>Trabalhando com os dados do cliente<\/h3>\n<p>\nPrecis\u00e1vamos garantir alta disponibilidade da solu\u00e7\u00e3o, especialmente no que diz respeito \u00e0 forma como obtemos os dados do cliente. A complexidade est\u00e1 no fato de que a fonte original desses dados \u00e9 um servi\u00e7o externo, que n\u00e3o garante opera\u00e7\u00e3o ininterrupta e uma largura de banda suficientemente alta. <\/p>\n<p>Portanto, precis\u00e1vamos garantir alta disponibilidade dos dados dos clientes. Como ferramenta, escolhemos <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/\">Hazelcast<\/a><\/noindex>, que nos fornece:<\/p>\n<ul>\n<li>acesso r\u00e1pido aos dados,<\/li>\n<li>a capacidade de organizar um cluster de v\u00e1rias nodes com dados replicados em diferentes nodes.<\/li>\n<\/ul>\n<p>\nOptamos pela estrat\u00e9gia mais simples de entrega de dados em cache:<\/p>\n<p><img decoding=\"async\" alt=\"Nossa experi\u00eancia na cria\u00e7\u00e3o de um API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/0175d6f0fda543566ab13d4cae9d8cc1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO trabalho com o sistema final ocorre dentro de sess\u00f5es, e h\u00e1 um limite para o n\u00famero m\u00e1ximo. Se o cliente n\u00e3o fechar a sess\u00e3o, teremos que faz\u00ea-lo. <\/p>\n<p>Os dados sobre a sess\u00e3o aberta v\u00eam do sistema final e s\u00e3o inicialmente processados no lado do Lua. Decidimos usar o Hazelcast para armazenar esses dados com um job escrito em .NET. Em seguida, verificamos periodicamente a validade das sess\u00f5es abertas e fechamos as que est\u00e3o expiradas. <\/p>\n<h3>Acesso ao Hazelcast tanto do Lua quanto do .NET<\/h3>\n<p>\nN\u00e3o h\u00e1 clientes para Lua que trabalhem com Hazelcast, mas o Hazelcast tem uma API REST, que decidimos utilizar. Para .NET, existe <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/clients\/net\/\">leve<\/a><\/noindex>, atrav\u00e9s do qual planejamos acessar os dados do Hazelcast do lado do .NET. Mas n\u00e3o foi t\u00e3o simples.<\/p>\n<p><img decoding=\"async\" alt=\"Nossa experi\u00eancia na cria\u00e7\u00e3o de um API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/52c9437e5cd16073b56afc55a4f415da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAo salvar dados via REST e recuper\u00e1-los atrav\u00e9s do cliente .NET, diferentes serializadores\/deserializadores s\u00e3o utilizados. Portanto, n\u00e3o \u00e9 poss\u00edvel enviar dados via REST e recuper\u00e1-los atrav\u00e9s do cliente .NET e vice-versa. <\/p>\n<p>Se houver interessados, contaremos mais sobre esse problema em um artigo separado. Spoiler \u2014 na figura. <\/p>\n<p><img decoding=\"async\" alt=\"Nossa experi\u00eancia na cria\u00e7\u00e3o de um API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/73bb11214fdaeca86ef10cdbd788e288.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Registro e monitoramento<\/h3>\n<p>\nNosso padr\u00e3o corporativo para registro via .NET \u00e9 o Serilog, todos os logs acabam no Elasticsearch, e a an\u00e1lise \u00e9 feita atrav\u00e9s do Kibana. Algo semelhante quer\u00edamos fazer nesse caso. O \u00fanico <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DhavalKapil\/elasticsearch-lua\">leve<\/a><\/noindex> para trabalhar com Elastic em Lua que foi encontrado quebrou na primeira importa\u00e7\u00e3o. Ent\u00e3o usamos o Fluentd. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.fluentd.org\/\">Fluentd<\/a><\/noindex> \u00e9 uma solu\u00e7\u00e3o open source para fornecer uma camada unificada de registro de aplica\u00e7\u00f5es. Permite coletar logs de diferentes camadas da aplica\u00e7\u00e3o e depois transmiti-los para uma fonte \u00fanica. <\/p>\n<p>O API Gateway funciona no K8S, ent\u00e3o decidimos adicionar um cont\u00eainer com o fluentd no mesmo pod, para escrever logs na porta TCP aberta existente do fluentd. <\/p>\n<p>Tamb\u00e9m investigamos como o fluentd se comportaria se n\u00e3o tivesse conex\u00e3o com o Elasticsearch. Durante dois dias, o gateway recebeu solicita\u00e7\u00f5es cont\u00ednuas, os logs foram enviados para o fluentd, mas o IP do Elastic foi bloqueado para o fluentd. Ap\u00f3s a restaura\u00e7\u00e3o da conex\u00e3o, o fluentd conseguiu transferir todos os logs para o Elastic.<\/p>\n<h3>Conclus\u00e3o<\/h3>\n<p>\nA abordagem escolhida para a implementa\u00e7\u00e3o nos permitiu entregar um produto funcional ao ambiente de produ\u00e7\u00e3o em apenas 2,5 meses.<\/p>\n<p>Se voc\u00ea algum dia se deparar com tarefas semelhantes, recomendamos que, em primeiro lugar, entenda claramente qual problema voc\u00ea est\u00e1 resolvendo e quais recursos voc\u00ea j\u00e1 possui. Esteja atento \u00e0s complexidades da integra\u00e7\u00e3o com sistemas de gerenciamento de API existentes. <\/p>\n<p>Entenda para si mesmo o que exatamente voc\u00ea pretende desenvolver \u2014 apenas a l\u00f3gica de neg\u00f3cios para processar solicita\u00e7\u00f5es ou, como poderia ser em nosso caso, o proxy como um todo. N\u00e3o se esque\u00e7a de que tudo o que voc\u00ea fizer por conta pr\u00f3pria deve ser rigorosamente testado posteriormente.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/true_engineering\/blog\/446438\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043d\u0430\u0448 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a, \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0447\u0435\u0440\u0435\u0437 \u043f\u0430\u0440\u0442\u043d\u0435\u0440\u0441\u043a\u0443\u044e \u0441\u0435\u0442\u044c. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043a\u0440\u0443\u043f\u043d\u044b\u0435 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u043c\u0430\u0433\u0430\u0437\u0438\u043d\u044b \u0438\u043d\u0442\u0435\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u043d\u044b \u0441\u043e \u0441\u043b\u0443\u0436\u0431\u043e\u0439 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u2014 \u0432\u044b \u0437\u0430\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0435 \u0442\u043e\u0432\u0430\u0440 \u0438 \u0432\u0441\u043a\u043e\u0440\u0435 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442\u0435 \u0442\u0440\u0435\u043a\u0438\u043d\u0433\u043e\u0432\u044b\u0439 \u043d\u043e\u043c\u0435\u0440 \u043f\u043e\u0441\u044b\u043b\u043a\u0438. \u0414\u0440\u0443\u0433\u043e\u0439 \u043f\u0440\u0438\u043c\u0435\u0440 \u2014 \u0432\u043c\u0435\u0441\u0442\u0435 \u0441 \u0430\u0432\u0438\u0430\u0431\u0438\u043b\u0435\u0442\u043e\u043c \u0432\u044b \u043f\u043e\u043a\u0443\u043f\u0430\u0435\u0442\u0435 \u0441\u0442\u0440\u0430\u0445\u043e\u0432\u043a\u0443 \u0438\u043b\u0438 \u0431\u0438\u043b\u0435\u0442 \u043d\u0430 \u0430\u044d\u0440\u043e\u044d\u043a\u0441\u043f\u0440\u0435\u0441\u0441. \u0414\u043b\u044f \u044d\u0442\u043e\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u043e\u0434\u0438\u043d API, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043d\u0443\u0436\u043d\u043e \u0432\u044b\u0434\u0430\u0442\u044c \u043f\u0430\u0440\u0442\u043d\u0435\u0440\u0430\u043c \u0447\u0435\u0440\u0435\u0437 API Gateway. \u042d\u0442\u0443 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":22777,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30792","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043d\u0430\u0448 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a, \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0447\u0435\u0440\u0435\u0437 \u043f\u0430\u0440\u0442\u043d\u0435\u0440\u0441\u043a\u0443\u044e \u0441\u0435\u0442\u044c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041d\u0430\u0448 \u043e\u043f\u044b\u0442 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f API Gateway | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043d\u0430\u0448 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a, \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0447\u0435\u0440\u0435\u0437 \u043f\u0430\u0440\u0442\u043d\u0435\u0440\u0441\u043a\u0443\u044e \u0441\u0435\u0442\u044c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:37:27+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:37:27+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Nossa experi\u00eancia na cria\u00e7\u00e3o de API Gateway | ProHoster","description":"Algumas empresas, incluindo nosso cliente, desenvolvem produtos por meio de uma rede de parceiros.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041d\u0430\u0448 \u043e\u043f\u044b\u0442 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f API Gateway | ProHoster","og:description":"\u041d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043d\u0430\u0448 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a, \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0447\u0435\u0440\u0435\u0437 \u043f\u0430\u0440\u0442\u043d\u0435\u0440\u0441\u043a\u0443\u044e \u0441\u0435\u0442\u044c.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:37:27+00:00","article:modified_time":"2019-10-31T18:37:27+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30792","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 03:01:22","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:05:31","updated":"2026-01-21 03:01:22","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/30792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=30792"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/30792\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/22777"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=30792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=30792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=30792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}