{"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\/sl\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","title":{"rendered":"Najino izku\u0161nje pri ustvarjanju API Gateway","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Nekatere podjetja, vklju\u010dno z na\u0161im naro\u010dnikom, razvijajo izdelek prek partnerske mre\u017ee. Na primer, veliki spletni trgovci so integrirani s storitvijo dostave \u2014 naro\u010dite izdelek in kmalu prejmete \u0161tevilko za sledenje paketu. Drug primer \u2014 skupaj z letalsko vozovnico kupite zavarovanje ali vozovnico za letali\u0161ki ekspres.<\/p>\n<p>Za to se uporablja en API, ki ga je treba izdati partnerjem prek API Gateway. To nalogo smo re\u0161ili. V tem \u010dlanku bomo podali podrobnosti.<\/p>\n<p>Dano: ekosistem in API portal z vmesnikom, kjer so uporabniki registrirani, prejemajo informacije itd. Moramo ustvariti udoben in zanesljiv API Gateway. Med postopkom smo morali zagotoviti <\/p>\n<ul>\n<li>registracijo, <\/li>\n<li>nadzor nad povezavo z API, <\/li>\n<li>monitoring, kako uporabniki uporabljajo kon\u010dni sistem, <\/li>\n<li>ra\u010dunanje poslovnih kazalnikov.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Najino izku\u0161nje pri ustvarjanju API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/4fa66fd4573af16b0bc78aa61173f907.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nV \u010dlanku bomo govorili o na\u0161em na\u010dinu ustvarjanja API Gateway, pri \u010demer smo re\u0161evali naslednje naloge:<\/p>\n<ul>\n<li>avtentifikacija uporabnika,<\/li>\n<li>avtorizacija uporabnika,<\/li>\n<li>modifikacija izvirnega zahtevka,<\/li>\n<li>posredovanje zahtevka,<\/li>\n<li>obdelava odgovora.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nObstajata dve vrsti upravljanja API:<\/p>\n<p>1. Standardno, ki deluje takole. Pred povezovanjem uporabnik testira zmo\u017enosti, nato pla\u010da in integrira na svojo spletno stran. Najpogosteje ga uporabljajo v malem in srednjem podjetni\u0161tvu.<\/p>\n<p>2. Veliko B2B API Management, kjer podjetje najprej sprejme poslovno odlo\u010ditev o povezavi, postane partner podjetja s pogodbenimi obveznostmi, nato se pove\u017ee z API. In \u0161ele po urednih formalnostih podjetje pridobi testni dostop, opravi testiranje in preide v produkcijo. Vendar to ni mogo\u010de brez upravljalske odlo\u010ditve o povezavi. <\/p>\n<p><img decoding=\"async\" alt=\"Najino izku\u0161nje pri ustvarjanju API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b9ab53d6c64d5a971c4950cd340ad42e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3> Na\u0161a re\u0161itev<\/h3>\n<p>\nV tem delu bomo govorili o ustvarjanju API Gateway.<\/p>\n<p>Kon\u010dni uporabniki ustvarjenega API Gateway-a so partnerji na\u0161ega naro\u010dnika. Za vsakega od njih \u017ee hranimo potrebne pogodbe. Potrebno bo le raz\u0161iriti funkcionalnosti, ob tem pa ozna\u010diti dodeljen dostop do gateway-a. Zato je potreben kontroliran proces povezovanja in upravljanja.<\/p>\n<p>Seveda bi bilo mogo\u010de uporabiti kak\u0161no pripravljeno re\u0161itev za nalogo upravljanja API in ustvarjanje API Gateway. Na primer, tak\u0161na bi lahko bila<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/api-management\/\"> Azure API Management<\/a><\/noindex>. Ni nam ni odgovaralo, jer smo ve\u0107 imali API portal i ogromni ekosistem izgra\u0111en oko njega. Svi korisnici su ve\u0107 bili registrovani, znali su gde i kako mogu da dobiju potrebne informacije. U API portalu su ve\u0107 postojali potrebni interfejsi, samo nam je bio potreban API Gateway. Sotv, njime smo se i bavili. <\/p>\n<p>Ono \u0161to nazivamo API Gateway \u2014 svojevrsni je proxy. Ponovo smo imali izbor \u2014 mo\u017eemo napisati svoj proxy ili odabrati ne\u0161to ve\u0107 postoje\u0107e. U ovom slu\u010daju, oti\u0161li smo drugim putem i izabrali kombinaciju nginx+Lua. Za\u0161to? Bio nam je potreban pouzdan, testiran softver koji podr\u017eava skalabilnost. Nismo \u017eeleli nakon implementacije da proveravamo i ta\u010dnost poslovne logike i funkcionalnost proxy-a. <\/p>\n<p>Svaki veb server ima proces obrade zahteva. U slu\u010daju nginx-a, izgleda ovako:<\/p>\n<p><img decoding=\"async\" alt=\"Najino izku\u0161nje pri ustvarjanju API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b4cba1d37cc769202f92df052b45c77e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n(shema iz <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">GitHub Lua Nginx<\/a><\/noindex>)<\/p>\n<p>Na\u0161 cilj je bio da se uklopimo u ovaj proces u onom trenutku kada mo\u017eemo da modifikujemo izvorni zahtev. <\/p>\n<p>\u017delimo da stvorimo transparentni proxy, tako da funkcionalno zahtev ostane onakav kakav je i do\u0161ao. Mi samo kontroli\u0161emo pristup krajnjem API-ju, poma\u017eemo zahtevu da do njega stigne. U slu\u010daju da je zahtev bio neispravan, gre\u0161ku bi trebao prikazati krajnji API, a ne mi. Jedini razlog za\u0161to mo\u017eemo odbiti zahtev \u2014 zbog nedostatka pristupa klijenta. <\/p>\n<p>Za nginx ve\u0107 postoji <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">raz\u0161iritev<\/a><\/noindex> na <noindex><a rel=\"nofollow\" href=\"http:\/\/www.lua.ru\/\">Lua<\/a><\/noindex>. Lua \u2014 je skriptni jezik, veoma je lagan i lako se u\u010di. Tako smo potrebnu logiku realizovali pomo\u0107u Lua. <\/p>\n<p>Konfiguracija nginx-a (analogija rute aplikacije), gde se obavlja sav posao, prili\u010dno je jasna. Posebna je poslednja direktiva \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>\nPogledajmo \u0161ta se de\u0161ava u ovoj konfiguraciji: <br \/>\n<b>more_clear_input_headers<\/b> \u2014 \u010disti vrednost navedenih nakon direktive headera. <br \/>\n<b>lua_need_request_body <\/b>\u2014 reguli\u0161e da li treba da pro\u010dita izvorno telo zahteva pre nego \u0161to izvr\u0161i rewrite\/access\/access_by_lua direktive ili ne. Podrazumevano nginx ne \u010dita telo zahteva klijenta, i ako vam je potrebno da mu pristupite, ova direktiva treba da ima vrednost on.<br \/>\n<b>rewrite_by_lua_file<\/b> \u2014 pot do skripte, v katerem je opisana logika za modifikacijo poizvedbe<br \/>\n<b>access_by_lua_file <\/b>\u2014 pot do skripte, v katerem je opisana logika, ki preverja dostop do vira. <br \/>\n<b>proxy_pass <\/b>\u2014 url, na katerega bo posredovana poizvedba.<br \/>\n<b>body_filter_by_lua_file <\/b>\u2014 pot do skripte, v katerem je opisana logika za filtriranje poizvedbe pred vra\u010danjem stranki.<br \/>\nIn, kon\u010dno, <b>post_action<\/b> \u2014 uradno nedokumentirana direktiva, s pomo\u010djo katere lahko izvedemo \u0161e nekatere druge akcije po tem, ko je odgovor dan stranki. <\/p>\n<p>Nato bomo po vrsti opisali, kako smo re\u0161evali svoje naloge.<\/p>\n<h3>Avtorizacija\/audit in modifikacija poizvedbe<\/h3>\n<p>\n<b>Avtorizacija<\/b><\/p>\n<p>Avtorizacijo in avtentifikacijo smo zgradili s pomo\u010djo dostopov na podlagi certifikata. Obstaja korenski certifikat. Vsakemu novemu naro\u010dniku naro\u010dnika se ustvari njegov osebni certifikat, s katerim lahko dostopa do API. Ta certifikat se nastavi v razdelku server nastavitev 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>Modifikacija<\/b><\/p>\n<p>Lahko se postavi upravi\u010deno vpra\u0161anje: kaj storiti s certificiranim strankam, \u010de nenadoma \u017eelimo onemogo\u010diti dostop do sistema? Ne moremo ponovno izdajati certifikatov za vse ostale stranke. <\/p>\n<p>Tako smo gladko pre\u0161li na naslednjo nalogo \u2014 modifikacijo izvorne poizvedbe. Izvorna poizvedba stranke ni veljavna za kon\u010dni sistem. Ena od nalog je dodati manjkajo\u010de dele v poizvedbo, da postane veljavna. \u010car je v tem, da so manjkajo\u010di podatki razli\u010dni za vsako stranko. Vemo, da k nam pride stranka s certifikatom, iz katerega lahko vzamemo odtis in potegnemo potrebne podatke o stranki iz baze. <\/p>\n<p>\u010ce bomo v nekem trenutku potrebovali onemogo\u010diti stranko iz na\u0161e storitve, bodo njeni podatki izginili iz baze in ne bo mogla ni\u010desar storiti. <\/p>\n<h3>Delo s podatki stranke<\/h3>\n<p>\nMorali smo zagotoviti visoko razpolo\u017eljivost re\u0161itve, zlasti glede na\u010dina pridobivanja podatkov strank. Te\u017eava je v tem, da je izvor teh podatkov zunanja storitev, ki ne zagotavlja nemotenega in dovolj visoke hitrosti delovanja. <\/p>\n<p>Zato smo morali zagotoviti visoko razpolo\u017eljivost podatkov strank. Kot orodje smo izbrali <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/\">Hazelcast<\/a><\/noindex>, ki nam nudi:<\/p>\n<ul>\n<li>hitri dostop do podatkov,<\/li>\n<li>mo\u017enost organizacije gru\u010de ve\u010d vozli\u0161\u010d z replikiranimi podatki na razli\u010dnih vozli\u0161\u010dih.<\/li>\n<\/ul>\n<p>\nIzbrali smo najpreprostej\u0161o strategijo dostave podatkov v predpomnilnik:<\/p>\n<p><img decoding=\"async\" alt=\"Najino izku\u0161nje pri ustvarjanju API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/0175d6f0fda543566ab13d4cae9d8cc1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDelo z kon\u010dnim sistemom poteka v okviru sej in obstaja omejitev na najve\u010dje \u0161tevilo. \u010ce stranka ne zapre seje, moramo to narediti mi. <\/p>\n<p>Podatki o odprti seji prihajajo od kon\u010dnega sistema in se prvotno obdelujejo na strani Lua. Odlo\u010dili smo se uporabiti Hazelcast za shranjevanje teh podatkov s pomo\u010djo opravila, napisanega v .NET. Nato ob\u010dasno preverjamo pravico do \u017eivljenja odprtih sej in zapiramo potekle. <\/p>\n<h3>Dostop do Hazelcasta tako iz Lua kot iz .NET<\/h3>\n<p>\nStrank za Lua za delo z Hazelcastom ni, vendar Hazelcast ponuja REST API, ki ga nameravamo uporabiti. Za .NET pa imamo <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/clients\/net\/\">stranko<\/a><\/noindex>, prek katere smo na\u010drtovali dostop do podatkov Hazelcast na strani .NET. Ampak ni \u0161lo po na\u010drtih.<\/p>\n<p><img decoding=\"async\" alt=\"Najino izku\u0161nje pri ustvarjanju API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/52c9437e5cd16073b56afc55a4f415da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPri shranjevanju podatkov prek REST in pridobivanju prek .NET stranke se uporabljajo razli\u010dni serializerji in deserializerji. Zato ni mogo\u010de shraniti podatkov prek REST, jih pa pridobiti prek .NET stranke in obratno. <\/p>\n<p>\u010ce bodo zainteresirani, bomo podrobneje predstavili to te\u017eavo v lo\u010denem \u010dlanku. Spoiler \u2014 na shemi. <\/p>\n<p><img decoding=\"async\" alt=\"Najino izku\u0161nje pri ustvarjanju API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/73bb11214fdaeca86ef10cdbd788e288.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Dnevnik in ogledovanje<\/h3>\n<p>\nNa\u0161 korporativni standard za dnevnikovaje prek .NET \u2014 Serilog, vsi dnevniki na koncu pridejo v Elasticsearch, njihovo analizo pa izvajamo prek Kiban\u0435. Nekaj podobnega smo \u017eeleli dose\u010di tudi v tem primeru. Edina <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DhavalKapil\/elasticsearch-lua\">stranko<\/a><\/noindex> stranka za delo z Elasticom na Lua, ki je bila najdena, se je poru\u0161ila takoj pri prvem require. In uporabili smo Fluentd. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.fluentd.org\/\">Fluentd<\/a><\/noindex> \u2014 je odprtokodna re\u0161itev za zagotavljanje enotnega sloja dnevnikov aplikacije. Omogo\u010da zbiranje dnevnikov z razli\u010dnih slojev aplikacije in njihovo prenos v enoten vir. <\/p>\n<p>API Gateway deluje v K8S, zato smo se odlo\u010dili dodati kontejner s fluentd v isto pod, da bi pisali dnevnike na obstoje\u010dem odprtem tcp portu fluentd. <\/p>\n<p>Raziskali smo tudi, kako se bo fluentd obna\u0161al, \u010de ne bo imel povezave z Elasticsearchom. \u010cez dva dni so v vrata neprekinjeno prihajali zahtevki, v fluentd so se po\u0161iljali dnevniki, vendar je imel fluentd IP Elastica blokiran. Po obnovitvi povezave je fluentd brez te\u017eav prenesel vse dnevnike v Elastic.<\/p>\n<h3>Zaklju\u010dek<\/h3>\n<p>\nIzbrani pristop k implementaciji nam je omogo\u010dil, da smo dostavili dejansko delujo\u010d izdelek v produkcijsko okolje v samo 2.5 mesecih.<\/p>\n<p>\u010ce se kdaj ukvarjate s podobnimi stvarmi, priporo\u010damo, da najprej jasno razumete, katero nalogo \u017eelite re\u0161iti in katere vire \u017ee imate na voljo. Bodite pozorni na zapletenost integracije z obstoje\u010dimi sistemi za upravljanje API. <\/p>\n<p>Razumite, kaj to\u010dno nameravate razviti \u2014 samo poslovno logiko obdelave zahtevkov ali, kot je bilo v na\u0161em primeru, celoten proxy. Ne pozabite, da mora biti vse, kar sami razvijete, pozneje temeljito testirano.<br \/>\n<br \/>Izvor: <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.4 - 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\/sl\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sl_SI\" \/>\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\/sl\/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\udd47Na\u0161a izku\u0161nja pri ustvarjanju API Gateway | ProHoster","description":"Nekatera podjetja, vklju\u010dno z na\u0161im naro\u010dnikom, razvijajo izdelek preko partnerske mre\u017ee.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/30792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=30792"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/30792\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/22777"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=30792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=30792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=30792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}