{"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\/it\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","title":{"rendered":"La nostra esperienza nella creazione di un API Gateway","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Alcune aziende, incluso il nostro cliente, sviluppano il prodotto attraverso una rete di partner. Ad esempio, grandi negozi online sono integrati con il servizio di consegna: ordini il prodotto e presto ricevi un numero di tracciamento del pacco. Un altro esempio \u00e8 che insieme al biglietto aereo acquisti un'assicurazione o un biglietto per l'aeroexpress.<\/p>\n<p>Per questo viene utilizzata un'unica API, che deve essere fornita ai partner tramite l'API Gateway. Questo compito lo abbiamo risolto. In questo articolo condivideremo i dettagli.<\/p>\n<p>Dati: ecosistema e portale API con un'interfaccia, dove gli utenti sono registrati, ricevono informazioni e cos\u00ec via. Dobbiamo creare un API Gateway comodo e affidabile. Durante il processo dovevamo garantire <\/p>\n<ul>\n<li>la registrazione, <\/li>\n<li>il controllo della connessione all'API, <\/li>\n<li>il monitoraggio di come gli utenti utilizzano il sistema finale, <\/li>\n<li>il monitoraggio delle metriche di business.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"La nostra esperienza nella creazione di un API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/4fa66fd4573af16b0bc78aa61173f907.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn questo articolo parleremo della nostra esperienza nella creazione di un API Gateway, durante la quale abbiamo affrontato i seguenti compiti:<\/p>\n<ul>\n<li>autenticazione dell'utente,<\/li>\n<li>autorizzazione dell'utente,<\/li>\n<li>modifica della richiesta originale,<\/li>\n<li>proxy della richiesta,<\/li>\n<li>post-elaborazione della risposta.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nCi sono due tipi di gestione delle API:<\/p>\n<p>1. Standard, che funziona nel seguente modo. Prima della connessione, l'utente testa le funzionalit\u00e0, poi paga e integra sul proprio sito. \u00c8 pi\u00f9 usato nelle piccole e medie imprese.<\/p>\n<p>2. Grande gestione delle API B2B, quando un'azienda prima prende una decisione commerciale sulla connessione, diventa partner dell'azienda con un obbligo contrattuale, dopodich\u00e9 si connette all'API. E solo dopo aver sistemato tutte le formalit\u00e0, l'azienda ottiene l'accesso di prova, supera i test e passa alla produzione. Ma ci\u00f2 non \u00e8 possibile senza una decisione di gestione sulla connessione. <\/p>\n<p><img decoding=\"async\" alt=\"La nostra esperienza nella creazione di un API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b9ab53d6c64d5a971c4950cd340ad42e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3> La nostra soluzione<\/h3>\n<p>\nIn questa parte parleremo della creazione di un API Gateway.<\/p>\n<p>Gli utenti finali del gateway API creato sono i partner del nostro cliente. Per ognuno di loro abbiamo gi\u00e0 i contratti necessari. Dobbiamo solo ampliare la funzionalit\u00e0, segnando l'accesso fornito al gateway. Di conseguenza, \u00e8 necessario un processo controllato di connessione e gestione.<\/p>\n<p>Certamente, si sarebbe potuto adottare una qualche soluzione gi\u00e0 pronta per affrontare il problema della gestione delle API e della creazione di un API Gateway in particolare. Ad esempio, una soluzione potrebbe essere<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/api-management\/\"> Azure API Management<\/a><\/noindex>. Non ci \u00e8 andato bene, perch\u00e9 nel nostro caso avevamo gi\u00e0 un portale API e un'enorme ecosistema costruita attorno ad esso. Tutti gli utenti erano gi\u00e0 registrati, capivano gi\u00e0 dove e come potevano ottenere le informazioni necessarie. Nel portale API esistevano gi\u00e0 le interfacce necessarie, ci serviva solo un API Gateway. In realt\u00e0, \u00e8 a questo sviluppo che ci siamo dedicati. <\/p>\n<p>Quello che chiamiamo API Gateway \u00e8 una sorta di proxy. Qui avevamo di nuovo una scelta: possiamo scrivere il nostro proxy, oppure scegliere qualcosa di gi\u00e0 pronto. In questo caso, abbiamo optato per la seconda strada e scelto la combinazione nginx+Lua. Perch\u00e9? Avevamo bisogno di un software affidabile e collaudato, che supportasse la scalabilit\u00e0. Non volevamo controllare, dopo l'implementazione, n\u00e9 la correttezza della logica aziendale n\u00e9 la correttezza del funzionamento del proxy. <\/p>\n<p>Qualsiasi server web ha una pipeline di elaborazione delle richieste. Nel caso di nginx, si presenta come segue:<\/p>\n<p><img decoding=\"async\" alt=\"La nostra esperienza nella creazione di un API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b4cba1d37cc769202f92df052b45c77e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n(schema da <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">GitHub Lua Nginx<\/a><\/noindex>)<\/p>\n<p>Il nostro obiettivo era di integrarci in questa pipeline nel momento in cui possiamo modificare la richiesta originale. <\/p>\n<p>Vogliamo creare un proxy trasparente, affinch\u00e9 la richiesta rimanga funzionalmente tale quale \u00e8 arrivata. Controlliamo solo l'accesso all'API finale, aiutiamo la richiesta a raggiungerla. Nel caso in cui la richiesta fosse errata, l'errore deve essere segnalato dall'API finale, non da noi. L'unico motivo per cui possiamo rifiutare una richiesta \u00e8 la mancanza di accesso da parte del cliente. <\/p>\n<p>Per nginx esiste gi\u00e0 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">un'estensione<\/a><\/noindex> in <noindex><a rel=\"nofollow\" href=\"http:\/\/www.lua.ru\/\">Lua<\/a><\/noindex>. Lua \u00e8 un linguaggio di scripting, molto leggero e facile da imparare. Cos\u00ec, abbiamo implementato la logica necessaria utilizzando Lua. <\/p>\n<p>La configurazione di nginx (analogia route dell'applicazione), dove viene eseguito tutto il lavoro, \u00e8 abbastanza comprensibile. Da notare l'ultima direttiva: 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>\nConsideriamo cosa succede in questa configurazione: <br \/>\n<b>more_clear_input_headers<\/b> \u2014 cancella il valore degli header indicati dopo la direttiva. <br \/>\n<b>lua_need_request_body <\/b>\u2014 controlla se \u00e8 necessario leggere il corpo della richiesta originale prima di eseguire le direttive rewrite\/access\/access_by_lua o meno. Per impostazione predefinita, nginx non legge il corpo della richiesta del cliente e, se \u00e8 necessario accedervi, questa direttiva deve avere valore on.<br \/>\n<b>rewrite_by_lua_file<\/b> \u2014 percorso verso gli script, in cui \u00e8 descritta la logica per modificare la richiesta<br \/>\n<b>access_by_lua_file <\/b>\u2014 percorso verso lo script, in cui \u00e8 descritta la logica che verifica la presenza di accesso alle risorse. <br \/>\n<b>proxy_pass <\/b>\u2014 url a cui verr\u00e0 inoltrata la richiesta.<br \/>\n<b>body_filter_by_lua_file <\/b>\u2014 percorso verso lo script, in cui \u00e8 descritta la logica per filtrare la richiesta prima di restituirla al cliente.<br \/>\nE, infine, <b>post_action<\/b> \u2014 direttiva ufficialmente non documentata, tramite la quale \u00e8 possibile eseguire ulteriori azioni dopo che la risposta \u00e8 stata data al cliente. <\/p>\n<p>Dopo parleremo in ordine di come abbiamo risolto le nostre problematiche.<\/p>\n<h3>Autenticazione e modifica della richiesta<\/h3>\n<p>\n<b>Autenticazione<\/b><\/p>\n<p>Abbiamo costruito l'autenticazione e l'autenticazione utilizzando accessi basati su certificato. C'\u00e8 un certificato radice. A ogni nuovo cliente del committente viene generato un certificato personale, con cui pu\u00f2 accedere all'API. Questo certificato \u00e8 configurato nella sezione server delle impostazioni 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<\/b><\/p>\n<p>Pu\u00f2 sorgere una domanda legittima: cosa fare con un cliente certificato, se all'improvviso volessimo disconnetterlo dal sistema? Non si possono riemissionare i certificati per tutti gli altri clienti. <\/p>\n<p>Cos\u00ec siamo passati naturalmente al compito successivo: la modifica della richiesta originale. La richiesta originale del cliente, a dire il vero, non \u00e8 valida per il sistema finale. Uno degli obiettivi \u00e8 completare la richiesta con le parti mancanti per renderla valida. Il punto \u00e8 che i dati mancanti sono diversi per ogni cliente. Sappiamo che il cliente si presenta con un certificato, da cui possiamo prendere l'impronta e estrarre i dati necessari dal database. <\/p>\n<p>Se a un certo punto sar\u00e0 necessario disconnettere un cliente dal nostro servizio, i suoi dati scompariranno dal database e lui non potr\u00e0 pi\u00f9 fare nulla. <\/p>\n<h3>Gestione dei dati del cliente<\/h3>\n<p>\nDovevamo garantire un'elevata disponibilit\u00e0 della soluzione, soprattutto per come otteniamo i dati del cliente. La difficolt\u00e0 sta nel fatto che la fonte originale di questi dati \u00e8 un servizio di terze parti, che non garantisce un funzionamento senza interruzioni e una velocit\u00e0 di lavoro sufficientemente alta. <\/p>\n<p>Perci\u00f2 dovevamo garantire un'elevata disponibilit\u00e0 dei dati dei clienti. Come strumento abbiamo scelto <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/\">Hazelcast<\/a><\/noindex>, che ci fornisce:<\/p>\n<ul>\n<li>accesso rapido ai dati,<\/li>\n<li>possibilit\u00e0 di organizzare un cluster di pi\u00f9 nodi con dati replicati su nodi diversi.<\/li>\n<\/ul>\n<p>\nAbbiamo adottato la strategia pi\u00f9 semplice per la consegna dei dati nella cache:<\/p>\n<p><img decoding=\"async\" alt=\"La nostra esperienza nella creazione di un API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/0175d6f0fda543566ab13d4cae9d8cc1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl lavoro con il sistema finale avviene nell'ambito delle sessioni e c'\u00e8 un limite sul numero massimo di esse. Se il cliente non chiude la sessione, dovremo farlo noi. <\/p>\n<p>I dati sulla sessione aperta provengono dal sistema finale e vengono inizialmente elaborati sul lato Lua. Abbiamo deciso di utilizzare Hazelcast per memorizzare questi dati tramite un job scritto in .NET. Poi, con una certa periodicit\u00e0, controlliamo il diritto alla vita delle sessioni aperte e chiudiamo quelle scadute. <\/p>\n<h3>Accesso a Hazelcast sia da Lua che da .NET<\/h3>\n<p>\nNon ci sono clienti su Lua per lavorare con Hazelcast, ma Hazelcast ha un'API REST che abbiamo deciso di utilizzare. Per .NET invece c'\u00e8 <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/clients\/net\/\">un client<\/a><\/noindex>, attraverso il quale avevamo pianificato di accedere ai dati di Hazelcast sul lato .NET. Ma non \u00e8 andata cos\u00ec.<\/p>\n<p><img decoding=\"async\" alt=\"La nostra esperienza nella creazione di un API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/52c9437e5cd16073b56afc55a4f415da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuando si salvano i dati tramite REST e si estraggono tramite il client .NET, vengono utilizzati diversi serializzatori e deserializzatori. Pertanto non \u00e8 possibile inserire dati tramite REST e recuperarli tramite il client .NET, e viceversa. <\/p>\n<p>Se ci saranno interessati, racconteremo pi\u00f9 in dettaglio di questo problema in un articolo separato. Spoiler: nel diagramma. <\/p>\n<p><img decoding=\"async\" alt=\"La nostra esperienza nella creazione di un API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/73bb11214fdaeca86ef10cdbd788e288.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Log e monitoraggio<\/h3>\n<p>\nIl nostro standard aziendale per la registrazione tramite .NET \u00e8 Serilog, e tutti i log alla fine vengono inviate a Elasticsearch, la cui analisi viene effettuata tramite Kibana. Volevamo fare qualcosa di simile anche in questo caso. L'unico <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DhavalKapil\/elasticsearch-lua\">un client<\/a><\/noindex> client trovato per lavorare con Elastic su Lua ha smesso di funzionare al primo require. E abbiamo usato Fluentd. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.fluentd.org\/\">Fluentd<\/a><\/noindex> \u00e8 una soluzione open source per fornire uno strato di registrazione centralizzato dell'applicazione. Permette di raccogliere log da diversi livelli dell'applicazione e poi di trasmetterli a una fonte unica. <\/p>\n<p>Il gateway API funziona in K8S, quindi abbiamo deciso di aggiungere un contenitore con fluentd nella stessa pod, per scrivere i log nella porta tcp aperta di fluentd gi\u00e0 esistente. <\/p>\n<p>Abbiamo anche indagato su come si comporter\u00e0 fluentd se non avr\u00e0 connessione con Elasticsearch. Per due giorni, continue richieste sono arrivate al gateway, i log venivano inviati a fluentd, ma l'IP di Elastic era stato bloccato per fluentd. Dopo il ripristino della connessione, fluentd ha esaminato tutti i log in Elastic.<\/p>\n<h3>Conclusione<\/h3>\n<p>\nL'approccio scelto per l'implementazione ci ha permesso di consegnare un prodotto realmente funzionante in ambiente di produzione in soli 2,5 mesi.<\/p>\n<p>Se un giorno vi capita di occuparvi di cose simili, vi consigliamo di capire chiaramente qual \u00e8 il problema che state risolvendo e quali risorse avete gi\u00e0 a disposizione. Fate attenzione alle complessit\u00e0 dell'integrazione con i sistemi di gestione API esistenti. <\/p>\n<p>Capite cosa intendete sviluppare: solo la logica aziendale per la gestione delle richieste o, come nel nostro caso, un proxy completo. Non dimenticate che tutto ci\u00f2 che farete da soli dovr\u00e0 essere successivamente testato con attenzione.<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.1.1 - 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\/it\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\/it\/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\udd47La nostra esperienza nella creazione di API Gateway | ProHoster","description":"Alcune aziende, compreso il nostro cliente, sviluppano il prodotto attraverso una rete di partner.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/30792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=30792"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/30792\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/22777"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=30792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=30792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=30792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}