{"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\/fr\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","title":{"rendered":"Notre exp\u00e9rience dans la cr\u00e9ation d'une API Gateway","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Certain companies, including our client, develop their product through a partner network. For example, large online stores are integrated with the delivery service\u2014you order a product and soon receive a tracking number for the package. Another example is purchasing insurance or a ticket for the airport express along with your airline ticket.<\/p>\n<p>To achieve this, a single API needs to be provided to partners through the API Gateway. This is the task we solved. In this article, we will discuss the details.<\/p>\n<p>Given: an ecosystem and an API portal with an interface where users are registered, receive information, etc. We need to create a user-friendly and reliable API Gateway. In the process, we needed to ensure <\/p>\n<ul>\n<li>registration, <\/li>\n<li>API connection monitoring, <\/li>\n<li>monitoring how users use the end system, <\/li>\n<li>tracking business metrics.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Notre exp\u00e9rience dans la cr\u00e9ation d&#039;une API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/4fa66fd4573af16b0bc78aa61173f907.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn this article, we will share our experience in creating an API Gateway, during which we addressed the following tasks:<\/p>\n<ul>\n<li>user authentication,<\/li>\n<li>user authorization,<\/li>\n<li>modification of the original request,<\/li>\n<li>request proxying,<\/li>\n<li>response post-processing.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nThere are two types of API management:<\/p>\n<p>1. Standard, which works as follows. Before connecting, the user tests the capabilities, then pays and integrates it into their website. It is most often used in small and medium-sized businesses.<\/p>\n<p>2. Large B2B API Management, where the company first makes a business decision to connect, becomes a partner with contractual obligations, and only then connects to the API. After settling all formalities, the company receives test access, undergoes testing, and goes live. But this is not possible without a management decision to connect. <\/p>\n<p><img decoding=\"async\" alt=\"Notre exp\u00e9rience dans la cr\u00e9ation d&#039;une API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b9ab53d6c64d5a971c4950cd340ad42e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3> Our solution<\/h3>\n<p>\nIn this part, we will discuss the creation of the API Gateway.<\/p>\n<p>The end users of the created API gateway are our client's partners. We already have the necessary contracts stored for each of them. We will only need to expand the functionality, noting the provided access to the gateway. Accordingly, a controlled process for connection and management is required.<\/p>\n<p>Certainly, it would have been possible to take some ready-made solution for API Management and creating an API Gateway in particular. For example, this could be<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/api-management\/\"> Azure API Management<\/a><\/noindex>. Cela ne nous convenait pas, car dans notre cas, nous avions d\u00e9j\u00e0 un portail API et un \u00e9cosyst\u00e8me \u00e9norme construit autour. Tous les utilisateurs \u00e9taient d\u00e9j\u00e0 enregistr\u00e9s et savaient o\u00f9 et comment obtenir les informations n\u00e9cessaires. Les interfaces n\u00e9cessaires existaient d\u00e9j\u00e0 dans le portail API, nous avions seulement besoin d'une API Gateway. C'est pr\u00e9cis\u00e9ment son d\u00e9veloppement qui nous a occup\u00e9s. <\/p>\n<p>Ce que nous appelons API Gateway est une sorte de proxy. Ici, nous avions \u00e0 nouveau le choix - soit \u00e9crire notre propre proxy, soit choisir quelque chose de d\u00e9j\u00e0 pr\u00eat. Dans ce cas, nous avons opt\u00e9 pour la seconde option et choisi la combinaison nginx+Lua. Pourquoi ? Nous avions besoin d'un logiciel fiable et \u00e9prouv\u00e9, soutenant l'\u00e9volutivit\u00e9. Nous ne voulions pas avoir \u00e0 v\u00e9rifier \u00e0 la fois la logique m\u00e9tier et le bon fonctionnement du proxy apr\u00e8s la mise en \u0153uvre. <\/p>\n<p>Tout serveur web a une cha\u00eene de traitement des requ\u00eates. Dans le cas de nginx, cela se pr\u00e9sente comme suit :<\/p>\n<p><img decoding=\"async\" alt=\"Notre exp\u00e9rience dans la cr\u00e9ation d&#039;une API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b4cba1d37cc769202f92df052b45c77e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n(sch\u00e9ma de <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">GitHub Lua Nginx<\/a><\/noindex>)<\/p>\n<p>Notre objectif \u00e9tait de s'int\u00e9grer dans cette cha\u00eene au moment o\u00f9 nous pouvons modifier la requ\u00eate initiale. <\/p>\n<p>Nous souhaitons cr\u00e9er un proxy transparent, afin que la requ\u00eate reste fonctionnellement telle qu'elle est arriv\u00e9e. Nous contr\u00f4lons simplement l'acc\u00e8s \u00e0 l'API finale, aidant la requ\u00eate \u00e0 y parvenir. Dans le cas o\u00f9 la requ\u00eate \u00e9tait incorrecte, c'est l'API finale qui doit afficher l'erreur, et non nous. La seule raison pour laquelle nous pouvons rejeter une requ\u00eate est l'absence d'acc\u00e8s pour le client. <\/p>\n<p>Il existe d\u00e9j\u00e0 pour nginx <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">extension<\/a><\/noindex> sur <noindex><a rel=\"nofollow\" href=\"http:\/\/www.lua.ru\/\">Lua<\/a><\/noindex>. Lua est un langage de script, tr\u00e8s l\u00e9ger et facile \u00e0 apprendre. Nous avons donc r\u00e9alis\u00e9 la logique n\u00e9cessaire \u00e0 l'aide de Lua. <\/p>\n<p>La configuration de nginx (analogie de l'application route), o\u00f9 tout le travail s'effectue, est assez compr\u00e9hensible. La derni\u00e8re directive est particuli\u00e8rement remarquable - 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>\nVoyons ce qui se passe dans cette configuration : <br \/>\n<b>more_clear_input_headers<\/b> \u2014 nettoie la valeur des en-t\u00eates sp\u00e9cifi\u00e9s apr\u00e8s la directive. <br \/>\n<b>lua_need_request_body <\/b>\u2014 d\u00e9termine si le corps de la requ\u00eate initiale doit \u00eatre lu avant d'ex\u00e9cuter les directives rewrite\/access\/access_by_lua ou non. Par d\u00e9faut, nginx ne lit pas le corps de la requ\u00eate du client, et si vous devez y acc\u00e9der, cette directive doit \u00eatre d\u00e9finie sur on.<br \/>\n<b>rewrite_by_lua_file<\/b> \u2014 chemin vers le script o\u00f9 la logique pour modifier la requ\u00eate est d\u00e9crite<br \/>\n<b>access_by_lua_file <\/b>\u2014 chemin vers le script o\u00f9 la logique v\u00e9rifiant l'acc\u00e8s \u00e0 la ressource est d\u00e9crite. <br \/>\n<b>proxy_pass <\/b>\u2014 url \u00e0 laquelle la requ\u00eate sera proxyfi\u00e9e.<br \/>\n<b>body_filter_by_lua_file <\/b>\u2014 chemin vers le script o\u00f9 la logique pour filtrer la requ\u00eate avant le retour au client est d\u00e9crite.<br \/>\nEt enfin, <b>post_action<\/b> \u2014 directive non document\u00e9e qui permet d'effectuer d'autres actions apr\u00e8s que la r\u00e9ponse ait \u00e9t\u00e9 envoy\u00e9e au client. <\/p>\n<p>Nous allons maintenant expliquer dans l'ordre comment nous avons r\u00e9solu nos probl\u00e8mes.<\/p>\n<h3>Autorisation\/authentification et modification de la requ\u00eate<\/h3>\n<p>\n<b>Autorisation<\/b><\/p>\n<p>Nous avons construit l'autorisation et l'authentification en utilisant l'acc\u00e8s par certificat. Il y a un certificat racine. Un certificat personnel est g\u00e9n\u00e9r\u00e9 pour chaque nouveau client du client, avec lequel il peut acc\u00e9der \u00e0 l'API. Ce certificat est configur\u00e9 dans la section server des param\u00e8tres 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>Modification<\/b><\/p>\n<p>Il peut \u00eatre l\u00e9gitime de se demander que faire avec un client certifi\u00e9 si soudainement nous voulons le d\u00e9connecter du syst\u00e8me ? Ne faut-il pas r\u00e9\u00e9mettre des certificats pour tous les autres clients ? <\/p>\n<p>Ainsi, nous avons progressivement abord\u00e9 la prochaine t\u00e2che \u2014 la modification de la requ\u00eate d'origine. La requ\u00eate d'origine du client n'est pas valable pour le syst\u00e8me final. L'une des t\u00e2ches consiste \u00e0 ajouter les parties manquantes \u00e0 la requ\u00eate pour la rendre valide. Le hic, c'est que les donn\u00e9es manquantes varient pour chaque client. Nous savons que le client vient \u00e0 nous avec un certificat dont nous pouvons prendre l'empreinte et extraire les donn\u00e9es n\u00e9cessaires du client \u00e0 partir de la base. <\/p>\n<p>Si \u00e0 un moment donn\u00e9 il devient n\u00e9cessaire de d\u00e9connecter un client de notre service, ses donn\u00e9es dispara\u00eetront de la base et il ne pourra rien faire. <\/p>\n<h3>Gestion des donn\u00e9es du client<\/h3>\n<p>\nNous devions assurer une haute disponibilit\u00e9 de la solution, en particulier pour la mani\u00e8re dont nous obtenons les donn\u00e9es du client. La difficult\u00e9 r\u00e9side dans le fait que la source primaire de ces donn\u00e9es est un service tiers qui ne garantit pas un fonctionnement ininterrompu et une vitesse de fonctionnement suffisamment \u00e9lev\u00e9e. <\/p>\n<p>C'est pourquoi nous devions assurer une haute disponibilit\u00e9 des donn\u00e9es clients. Comme outil, nous avons choisi <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/\">Hazelcast<\/a><\/noindex>, qui nous fournit :<\/p>\n<ul>\n<li>un acc\u00e8s rapide aux donn\u00e9es,<\/li>\n<li>la possibilit\u00e9 d'organiser un cluster de plusieurs n\u0153uds avec des donn\u00e9es r\u00e9pliqu\u00e9es sur diff\u00e9rents n\u0153uds.<\/li>\n<\/ul>\n<p>\nNous avons suivi la strat\u00e9gie la plus simple pour livrer les donn\u00e9es en cache :<\/p>\n<p><img decoding=\"async\" alt=\"Notre exp\u00e9rience dans la cr\u00e9ation d&#039;une API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/0175d6f0fda543566ab13d4cae9d8cc1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe travail avec le syst\u00e8me final se fait dans le cadre de sessions et il y a une limite sur le nombre maximal. Si le client n'a pas ferm\u00e9 la session, c'est \u00e0 nous de le faire. <\/p>\n<p>Les donn\u00e9es sur la session ouverte proviennent du syst\u00e8me final et sont initialement trait\u00e9es du c\u00f4t\u00e9 de Lua. Nous avons d\u00e9cid\u00e9 d'utiliser Hazelcast pour sauvegarder ces donn\u00e9es \u00e0 l'aide d'un job \u00e9crit en .NET. Ensuite, \u00e0 intervalles r\u00e9guliers, nous v\u00e9rifions la validit\u00e9 des sessions ouvertes et fermons celles qui ont expir\u00e9. <\/p>\n<h3>Acc\u00e8s \u00e0 Hazelcast \u00e0 la fois depuis Lua et depuis .NET<\/h3>\n<p>\nIl n'y a pas de clients Lua pour travailler avec Hazelcast, mais Hazelcast propose une API REST que nous avons d\u00e9cid\u00e9 d'utiliser. Pour .NET, il existe <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/clients\/net\/\">client<\/a><\/noindex>, par lequel nous avions pr\u00e9vu d'acc\u00e9der aux donn\u00e9es Hazelcast c\u00f4t\u00e9 .NET. Mais ce ne fut pas si simple.<\/p>\n<p><img decoding=\"async\" alt=\"Notre exp\u00e9rience dans la cr\u00e9ation d&#039;une API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/52c9437e5cd16073b56afc55a4f415da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLors de la sauvegarde des donn\u00e9es via REST et de l'extraction \u00e0 l'aide du client .NET, diff\u00e9rents s\u00e9rialiseurs\/d\u00e9s\u00e9rialiseurs sont utilis\u00e9s. Il est donc impossible de mettre des donn\u00e9es via REST et de les extraire avec le client .NET, et vice versa. <\/p>\n<p>S'il y a des int\u00e9ress\u00e9s, nous en parlerons plus en d\u00e9tail dans un article s\u00e9par\u00e9. Spoiler - sur le sch\u00e9ma. <\/p>\n<p><img decoding=\"async\" alt=\"Notre exp\u00e9rience dans la cr\u00e9ation d&#039;une API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/73bb11214fdaeca86ef10cdbd788e288.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Journalisation et surveillance<\/h3>\n<p>\nNotre standard d'entreprise pour la journalisation via .NET est Serilog, tous les journaux finissent par \u00eatre envoy\u00e9s dans Elasticsearch, et nous analysons les donn\u00e9es via Kibana. Nous voulions faire \u00e0 peu pr\u00e8s la m\u00eame chose dans ce cas. Cependant, le seul <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DhavalKapil\/elasticsearch-lua\">client<\/a><\/noindex> pour travailler avec Elastic en Lua que nous avons trouv\u00e9 a \u00e9chou\u00e9 lors du premier require. Nous avons donc utilis\u00e9 Fluentd. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.fluentd.org\/\">Fluentd<\/a><\/noindex> est une solution open source pour fournir une couche unique de journalisation d'application. Elle permet de collecter des journaux provenant de diff\u00e9rents niveaux de l'application, puis de les transmettre \u00e0 une source unique. <\/p>\n<p>API Gateway fonctionne dans K8S, nous avons donc d\u00e9cid\u00e9 d'ajouter un conteneur avec Fluentd dans le m\u00eame pod pour \u00e9crire les journaux dans le port tcp ouvert d\u00e9j\u00e0 existant de Fluentd. <\/p>\n<p>Nous avons \u00e9galement \u00e9tudi\u00e9 le comportement de Fluentd en cas de perte de connexion avec Elasticsearch. Pendant deux jours, des requ\u00eates ont continu\u00e9 \u00e0 arriver dans la passerelle, des journaux \u00e9taient envoy\u00e9s \u00e0 Fluentd, mais l'IP d'Elastic avait \u00e9t\u00e9 bloqu\u00e9e. Apr\u00e8s la restauration de la connexion, Fluentd a r\u00e9ussi \u00e0 transf\u00e9rer tous les journaux vers Elastic.<\/p>\n<h3>Conclusion<\/h3>\n<p>\nL'approche choisie pour la mise en \u0153uvre nous a permis de livrer un produit fonctionnel en production en seulement 2,5 mois.<\/p>\n<p>Si jamais vous \u00eates amen\u00e9 \u00e0 travailler sur ce type de t\u00e2ches, nous vous conseillons de bien comprendre d'abord quel probl\u00e8me vous r\u00e9solvez et quelles ressources vous avez d\u00e9j\u00e0 \u00e0 disposition. Soyez attentif aux complexit\u00e9s d'int\u00e9gration avec les syst\u00e8mes de gestion API existants. <\/p>\n<p>Comprenez ce que vous allez d\u00e9velopper \u2014 uniquement la logique m\u00e9tier du traitement des requ\u00eates ou, comme cela a pu \u00eatre le cas pour nous, le proxy dans son int\u00e9gralit\u00e9. N'oubliez pas que tout ce que vous r\u00e9aliserez par vous-m\u00eame devra ensuite \u00eatre rigoureusement test\u00e9.<br \/>\n<br \/>Source : <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\/fr\/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=\"fr_FR\" \/>\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\/fr\/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\udd47Notre exp\u00e9rience dans la cr\u00e9ation de passerelles API | ProHoster","description":"Certaines entreprises, y compris notre client, d\u00e9veloppent le produit via un r\u00e9seau de partenaires.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/30792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=30792"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/30792\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/22777"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=30792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=30792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=30792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}