{"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\/es\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","title":{"rendered":"Nuestra experiencia en la creaci\u00f3n de API Gateway","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Algunas empresas, incluyendo a nuestro cliente, desarrollan el producto a trav\u00e9s de una red de socios. Por ejemplo, grandes tiendas en l\u00ednea est\u00e1n integradas con el servicio de entrega: usted ordena un producto y, poco despu\u00e9s, recibe un n\u00famero de seguimiento del paquete. Otro ejemplo es que junto con el boleto de avi\u00f3n, compra un seguro o un boleto para el aerotren.<\/p>\n<p>Para esto se utiliza una \u00fanica API, que debe ser proporcionada a los socios a trav\u00e9s del API Gateway. Esta fue la tarea que resolvimos. En este art\u00edculo compartiremos los detalles.<\/p>\n<p>Dado: un ecosistema y un portal API con una interfaz donde los usuarios est\u00e1n registrados, reciben informaci\u00f3n, etc. Necesitamos crear un API Gateway c\u00f3modo y fiable. En el proceso, necesit\u00e1bamos asegurarnos de <\/p>\n<ul>\n<li>registro, <\/li>\n<li>control de la conexi\u00f3n a la API, <\/li>\n<li>monitoreo de c\u00f3mo los usuarios utilizan el sistema final, <\/li>\n<li>consideraci\u00f3n de indicadores empresariales.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Nuestra experiencia en la creaci\u00f3n de API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/4fa66fd4573af16b0bc78aa61173f907.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn el art\u00edculo hablaremos sobre nuestra experiencia en la creaci\u00f3n de un API Gateway, durante la cual resolvimos las siguientes tareas:<\/p>\n<ul>\n<li>autenticaci\u00f3n del usuario,<\/li>\n<li>autorizaci\u00f3n del usuario,<\/li>\n<li>modificaci\u00f3n de la solicitud original,<\/li>\n<li>proxy de la solicitud,<\/li>\n<li>postprocesamiento de la respuesta.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nHay dos tipos de gesti\u00f3n de API:<\/p>\n<p>1. Est\u00e1ndar, que funciona de la siguiente manera. Antes de la conexi\u00f3n, el usuario prueba las capacidades, luego paga e integra en su sitio web. Es m\u00e1s com\u00fanmente utilizado en peque\u00f1as y medianas empresas.<\/p>\n<p>2. Gran B2B API Management, donde la empresa primero toma una decisi\u00f3n comercial sobre la conexi\u00f3n, se convierte en socio de la empresa con un compromiso contractual, despu\u00e9s de lo cual se conecta a la API. Y ya despu\u00e9s de resolver todas las formalidades, la empresa obtiene acceso de prueba, realiza pruebas y pasa a producci\u00f3n. Pero esto no es posible sin una decisi\u00f3n directiva sobre la conexi\u00f3n. <\/p>\n<p><img decoding=\"async\" alt=\"Nuestra experiencia en la creaci\u00f3n de API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b9ab53d6c64d5a971c4950cd340ad42e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3> Nuestra soluci\u00f3n<\/h3>\n<p>\nEn esta parte hablaremos sobre la creaci\u00f3n de API Gateway.<\/p>\n<p>Los usuarios finales del gateway API que se est\u00e1 creando son los socios de nuestro cliente. Para cada uno de ellos ya tenemos los contratos necesarios. Solo necesitamos ampliar la funcionalidad, resaltando el acceso proporcionado al gateway. Por lo tanto, se requiere un proceso controlado de conexi\u00f3n y gesti\u00f3n.<\/p>\n<p>Sin duda, podr\u00eda haberse tomado alguna soluci\u00f3n lista para resolver la tarea de gesti\u00f3n de API y la creaci\u00f3n de API Gateway en particular. Por ejemplo, podr\u00eda haber sido<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/api-management\/\"> Azure API Management<\/a><\/noindex>. No nos funcion\u00f3 porque en nuestro caso ya ten\u00edamos un portal API y un gran ecosistema construido a su alrededor. Todos los usuarios ya estaban registrados y comprend\u00edan d\u00f3nde y c\u00f3mo pod\u00edan obtener la informaci\u00f3n necesaria. Ya exist\u00edan las interfaces requeridas en el portal API, solo necesit\u00e1bamos un API Gateway. En realidad, eso fue lo que comenzamos a desarrollar. <\/p>\n<p>Lo que llamamos API Gateway es una especie de proxy. Aqu\u00ed nuevamente ten\u00edamos una elecci\u00f3n: se pod\u00eda escribir nuestro propio proxy o elegir algo ya existente. En este caso, optamos por la segunda opci\u00f3n y elegimos la combinaci\u00f3n nginx+Lua. \u00bfPor qu\u00e9? Necesit\u00e1bamos un software confiable y probado que soportara la escalabilidad. No quer\u00edamos verificar despu\u00e9s de la implementaci\u00f3n tanto la correcci\u00f3n de la l\u00f3gica de negocio como la funcionalidad del proxy. <\/p>\n<p>Cualquier servidor web tiene un canal de procesamiento de solicitudes. En el caso de nginx, se ve de la siguiente manera:<\/p>\n<p><img decoding=\"async\" alt=\"Nuestra experiencia en la creaci\u00f3n de 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>Nuestro objetivo era integrarse en este canal en el momento en que pudi\u00e9ramos modificar la solicitud original. <\/p>\n<p>Queremos crear un proxy transparente, de modo que funcionalmente la solicitud permanezca tal como lleg\u00f3. Solo controlamos el acceso a la API final, ayudamos a que la solicitud llegue a ella. En caso de que la solicitud sea incorrecta, el error debe ser mostrado por la API final, no por nosotros. La \u00fanica raz\u00f3n por la que podemos rechazar una solicitud es por falta de acceso del cliente. <\/p>\n<p>Para nginx ya existe <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">una extensi\u00f3n<\/a><\/noindex> en <noindex><a rel=\"nofollow\" href=\"http:\/\/www.lua.ru\/\">Lua<\/a><\/noindex>. Lua es un lenguaje de scripting, es muy ligero y f\u00e1cil de aprender. De esta manera, implementamos la l\u00f3gica necesaria con Lua. <\/p>\n<p>La configuraci\u00f3n de nginx (analog\u00eda de la ruta de la aplicaci\u00f3n), donde se lleva a cabo todo el trabajo, es bastante comprensible. Lo notable aqu\u00ed es la \u00faltima directiva: 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>\nVeamos qu\u00e9 sucede en esta configuraci\u00f3n: <br \/>\n<b>more_clear_input_headers<\/b> \u2014 elimina el valor de los encabezados especificados despu\u00e9s de la directiva. <br \/>\n<b>lua_need_request_body <\/b>\u2014 determina si se debe leer el cuerpo original de la solicitud antes de ejecutar las directivas rewrite\/access\/access_by_lua o no. Por defecto, nginx no lee el cuerpo de la solicitud del cliente, y si necesita acceder a \u00e9l, esta directiva debe estar configurada como on.<br \/>\n<b>rewrite_by_lua_file<\/b> \u2014 ruta al script que describe la l\u00f3gica para modificar la solicitud<br \/>\n<b>access_by_lua_file <\/b>\u2014 ruta al script que describe la l\u00f3gica que verifica el acceso al recurso. <br \/>\n<b>proxy_pass <\/b>\u2014 URL al que se redirigir\u00e1 la solicitud.<br \/>\n<b>body_filter_by_lua_file <\/b>\u2014 ruta al script que describe la l\u00f3gica para filtrar la solicitud antes de devolverla al cliente.<br \/>\nY, por \u00faltimo, <b>post_action<\/b> \u2014 directiva oficialmente no documentada que permite realizar m\u00e1s acciones despu\u00e9s de que la respuesta ha sido enviada al cliente. <\/p>\n<p>A continuaci\u00f3n, explicaremos paso a paso c\u00f3mo resolvimos nuestras tareas.<\/p>\n<h3>Autenticaci\u00f3n\/Autorizaci\u00f3n y modificaci\u00f3n de la solicitud<\/h3>\n<p>\n<b>Autorizaci\u00f3n<\/b><\/p>\n<p>Construimos la autorizaci\u00f3n y autenticaci\u00f3n a trav\u00e9s de accesos por certificado. Hay un certificado ra\u00edz. Se genera un certificado personal para cada nuevo cliente del cliente, con el que puede acceder a la API. Este certificado se configura en la secci\u00f3n de server de los ajustes de 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>Modificaci\u00f3n<\/b><\/p>\n<p>Puede surgir una pregunta justa: \u00bfqu\u00e9 hacer con un cliente certificado si de repente queremos desconectarlo del sistema? No vamos a volver a emitir certificados para todos los dem\u00e1s clientes. <\/p>\n<p>As\u00ed que llegamos suavemente a la siguiente tarea: la modificaci\u00f3n de la solicitud original. La solicitud original del cliente, en general, no es v\u00e1lida para el sistema final. Una de las tareas consiste en agregar las partes faltantes a la solicitud para hacerla v\u00e1lida. La cuesti\u00f3n es que los datos faltantes son diferentes para cada cliente. Sabemos que el cliente nos llega con un certificado, del cual podemos obtener una huella y extraer de la base de datos los datos necesarios del cliente. <\/p>\n<p>Si en alg\u00fan momento es necesario desconectar al cliente de nuestro servicio, sus datos desaparecer\u00e1n de la base y no podr\u00e1 hacer nada. <\/p>\n<h3>Trabajo con los datos del cliente<\/h3>\n<p>\nNecesit\u00e1bamos asegurar una alta disponibilidad de la soluci\u00f3n, especialmente en c\u00f3mo obtenemos los datos del cliente. La dificultad radica en que la fuente original de estos datos es un servicio externo que no garantiza un funcionamiento ininterrumpido y una velocidad de operaci\u00f3n suficientemente alta. <\/p>\n<p>Por lo tanto, deb\u00edamos asegurar alta disponibilidad de los datos de los clientes. Como herramienta elegimos <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/\">Hazelcast<\/a><\/noindex>, que nos proporciona:<\/p>\n<ul>\n<li>acceso r\u00e1pido a los datos,<\/li>\n<li>la posibilidad de organizar un cl\u00faster de m\u00faltiples nodos con datos replicados en diferentes nodos.<\/li>\n<\/ul>\n<p>\nOptamos por la estrategia m\u00e1s sencilla para la entrega de datos en la cach\u00e9:<\/p>\n<p><img decoding=\"async\" alt=\"Nuestra experiencia en la creaci\u00f3n de API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/0175d6f0fda543566ab13d4cae9d8cc1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl trabajo con el sistema final se realiza en sesiones y hay un l\u00edmite en el n\u00famero m\u00e1ximo de sesiones. Si el cliente no cierra la sesi\u00f3n, tendremos que hacerlo nosotros. <\/p>\n<p>Los datos sobre la sesi\u00f3n abierta provienen del sistema final y se procesan inicialmente en el lado de Lua. Decidimos utilizar Hazelcast para almacenar estos datos con un job escrito en .NET. Luego, de forma peri\u00f3dica, verificamos la validez de las sesiones abiertas y cerramos las caducadas. <\/p>\n<h3>Acceso a Hazelcast tanto desde Lua como desde .NET<\/h3>\n<p>\nNo hay clientes para Lua que trabajen con Hazelcast, pero Hazelcast tiene una REST API que decidimos utilizar. Para .NET hay <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/clients\/net\/\">cliente<\/a><\/noindex>, a trav\u00e9s del cual plane\u00e1bamos acceder a los datos de Hazelcast desde .NET. Pero no fue tan sencillo.<\/p>\n<p><img decoding=\"async\" alt=\"Nuestra experiencia en la creaci\u00f3n de API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/52c9437e5cd16073b56afc55a4f415da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAl guardar datos a trav\u00e9s de REST y recuperarlos a trav\u00e9s del cliente de .NET se utilizan diferentes serializadores\/deserializadores. Por lo tanto, no es posible guardar datos a trav\u00e9s de REST y recuperarlos a trav\u00e9s del cliente de .NET, y viceversa. <\/p>\n<p>Si hay interesados, contaremos m\u00e1s sobre este problema en un art\u00edculo separado. Spoiler: en el diagrama. <\/p>\n<p><img decoding=\"async\" alt=\"Nuestra experiencia en la creaci\u00f3n de API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/73bb11214fdaeca86ef10cdbd788e288.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Registro y monitoreo<\/h3>\n<p>\nNuestro est\u00e1ndar corporativo para el registro a trav\u00e9s de .NET es Serilog, todos los registros terminan en Elasticsearch, y su an\u00e1lisis lo realizamos a trav\u00e9s de Kibana. Quer\u00edamos hacer algo similar en este caso. El \u00fanico <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DhavalKapil\/elasticsearch-lua\">cliente<\/a><\/noindex> cliente para trabajar con Elastic en Lua que se encontr\u00f3, fall\u00f3 en el primer require. As\u00ed que usamos Fluentd. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.fluentd.org\/\">Fluentd<\/a><\/noindex> es una soluci\u00f3n de c\u00f3digo abierto que proporciona una capa unificada de registro de aplicaciones. Permite recopilar registros de diferentes capas de la aplicaci\u00f3n y luego transmitirlos a una fuente \u00fanica. <\/p>\n<p>API Gateway funciona en K8S, por lo que decidimos agregar un contenedor con Fluentd en el mismo pod, para escribir registros en el puerto tcp abierto existente de Fluentd. <\/p>\n<p>Tambi\u00e9n investigamos c\u00f3mo se comportar\u00eda Fluentd si no tuviera conexi\u00f3n con Elasticsearch. Durante dos d\u00edas, la puerta de enlace recibi\u00f3 solicitudes continuamente, se enviaron registros a Fluentd, pero se bloque\u00f3 la IP de Elastic en Fluentd. Despu\u00e9s de restaurar la conexi\u00f3n, Fluentd logr\u00f3 transferir todos los registros a Elastic sin problemas.<\/p>\n<h3>Conclusi\u00f3n<\/h3>\n<p>\nEl enfoque elegido para la implementaci\u00f3n nos permiti\u00f3 entregar un producto funcional en el entorno de producci\u00f3n en solo 2.5 meses.<\/p>\n<p>Si alguna vez se encuentra involucrado en cosas similares, le recomendamos que primero entienda claramente qu\u00e9 problema est\u00e1 resolviendo y qu\u00e9 recursos ya tiene. Tenga cuidado con las dificultades de integraci\u00f3n con los sistemas de gesti\u00f3n de API existentes. <\/p>\n<p>Entienda para s\u00ed mismo qu\u00e9 es lo que planea desarrollar: solo la l\u00f3gica de negocio para procesar solicitudes o, como podr\u00eda ser en nuestro caso, el proxy completo. No olvide que todo lo que haga por su cuenta debe ser cuidadosamente probado posteriormente.<br \/>\n<br \/>Fuente: <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.2 - 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\/es\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\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\/es\/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\udd47Nuestra experiencia en la creaci\u00f3n de API Gateway | ProHoster","description":"Algunas empresas, incluido nuestro cliente, desarrollan el producto a trav\u00e9s de una red de socios.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/30792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=30792"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/30792\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/22777"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=30792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=30792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=30792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}