{"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\/hr\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","title":{"rendered":"Na\u0161e iskustvo u stvaranju API Gatewaya","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Neke tvrtke, uklju\u010duju\u0107i na\u0161eg klijenta, razvijaju proizvod putem partnerske mre\u017ee. Na primjer, velika internetska trgovina integrirana je sa slu\u017ebom dostave \u2014 naru\u010dujete proizvod i uskoro dobivate broj za pra\u0107enje po\u0161iljke. Drugi primjer je kada uz avionsku kartu kupujete osiguranje ili kartu za aerodromsku ekspresnu uslugu.<\/p>\n<p>Za to se koristi jedan API koji treba dati partnerima putem API Gateway-a. Ovu zada\u0107u smo i rije\u0161ili. U ovom \u010dlanku \u0107emo detaljno opisati.<\/p>\n<p>Imamo: ekosustav i API portal s su\u010deljem, gdje su korisnici registrirani, dobivaju informacije itd. Trebamo stvoriti prikladan i pouzdan API Gateway. U procesu trebamo osigurati <\/p>\n<ul>\n<li>registraciju, <\/li>\n<li>kontrolu pristupa API-ju, <\/li>\n<li>monitoring kori\u0161tenja zavr\u0161nog sustava od strane korisnika, <\/li>\n<li>pra\u0107enje poslovnih pokazatelja.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Na\u0161e iskustvo u stvaranju API Gatewaya\" src=\"\/wp-content\/uploads\/2019\/04\/4fa66fd4573af16b0bc78aa61173f907.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nU \u010dlanku \u0107emo govoriti o na\u0161em iskustvu stvaranja API Gateway-a, tijekom kojeg smo se suo\u010dili s sljede\u0107im zadatcima:<\/p>\n<ul>\n<li>autentifikacija korisnika,<\/li>\n<li>autorizacija korisnika,<\/li>\n<li>modifikacija izvorne zahtjeva,<\/li>\n<li>proksiranje zahtjeva,<\/li>\n<li>postprocesiranje odgovora.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nPostoje dva tipa API upravljanja:<\/p>\n<p>1. Standardno, koje funkcionira na sljede\u0107i na\u010din. Prije povezivanja korisnik testira mogu\u0107nosti, zatim pla\u0107a i integrira se na svoju stranicu. Naj\u010de\u0161\u0107e ga koriste mala i srednja poduze\u0107a.<\/p>\n<p>2. Veliko B2B API upravljanje, kada tvrtka prvo donosi poslovnu odluku o povezivanju, postaje partner tvrtke s ugovornom obvezom, a zatim se povezuje na API. I tek nakon rje\u0161avanja svih formalnosti, kompanija dobiva probni pristup, prolazi testiranje i prelazi u proizvodnju. No, to nije mogu\u0107e bez upravlja\u010dke odluke o povezivanju. <\/p>\n<p><img decoding=\"async\" alt=\"Na\u0161e iskustvo u stvaranju API Gatewaya\" src=\"\/wp-content\/uploads\/2019\/04\/b9ab53d6c64d5a971c4950cd340ad42e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3> Na\u0161e rje\u0161enje<\/h3>\n<p>\nU ovom dijelu govorit \u0107emo o stvaranju API Gateway-a.<\/p>\n<p>Krajnji korisnici stvorenog API Gateway-a su partneri na\u0161eg klijenta. Za svakog od njih ve\u0107 imamo potrebne ugovore. Morat \u0107emo samo pro\u0161iriti funkcionalnost, ozna\u010davaju\u0107i dodijeljeni pristup gateway-u. Odsud, potreban je kontrolirani proces povezivanja i upravljanja.<\/p>\n<p>Naravno, moglo se uzeti neko rje\u0161enje koje ve\u0107 postoji za rje\u0161avanje zadatka upravljanja API-jem i stvaranja API Gateway-a posebno. Na primjer, to bi moglo biti<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/api-management\/\"> Azure API Management<\/a><\/noindex>. Nije nam odgovarao, jer smo ve\u0107 imali API portal i ogromnu ekosustav izgra\u0111enu oko njega. Svi su korisnici ve\u0107 bili registrirani, znali su gdje i kako mogu dobiti potrebne informacije. U API portalu ve\u0107 su postojala potrebna su\u010delja, samo nam je bio potreban API Gateway. Na tome smo se zapravo i fokusirali. <\/p>\n<p>Ono \u0161to nazivamo API Gateway \u2014 svojevrsni je proxy. Ponovno smo imali izbor \u2014 mogli smo napisati svoj proxy ili izabrati ne\u0161to ve\u0107 gotovog. U ovom slu\u010daju odlu\u010dili smo se za drugu opciju i izabrali kombinaciju nginx+Lua. Za\u0161to? Trebali smo pouzdan, testiran softver koji podr\u017eava skalabilnost. Nismo \u017eeljeli nakon implementacije provjeravati i ispravnost poslovne logike i ispravnost rada proxyja. <\/p>\n<p>Svaki web server ima cjelinu za obradu zahtjeva. U slu\u010daju nginx-a izgleda ovako:<\/p>\n<p><img decoding=\"async\" alt=\"Na\u0161e iskustvo u stvaranju API Gatewaya\" 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 bio je ugraditi se u ovu cjelinu u trenutku kada mo\u017eemo modificirati izvorni zahtjev. <\/p>\n<p>\u017delimo stvoriti transparentni proxy, tako da funkcionalno zahtjev ostane onakvim kakvim je i stigao. Samo kontroliramo pristup kona\u010dnom API-ju, poma\u017eemo zahtjevu da do\u0111e do njega. U slu\u010daju da je zahtjev bio neispravan, gre\u0161ka bi trebala biti prikazana od strane kona\u010dnog API-ja, a ne od nas. Jedini razlog za\u0161to mo\u017eemo odbiti zahtjev je nedostatak pristupa klijenta. <\/p>\n<p>Za nginx ve\u0107 postoji <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">pro\u0161irenje<\/a><\/noindex> na <noindex><a rel=\"nofollow\" href=\"http:\/\/www.lua.ru\/\">Lua<\/a><\/noindex>. Lua je skriptni jezik, vrlo je lagan i jednostavan za u\u010denje. Tako smo potrebnu logiku implementirali putem Lua. <\/p>\n<p>Konfiguracija nginx-a (analogija rute aplikacije), gdje se izvr\u0161ava sav posao, je prili\u010dno jasna. Ovdje je zanimljiva posljednja 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 \u0161to se doga\u0111a u ovoj konfiguraciji: <br \/>\n<b>more_clear_input_headers<\/b> \u2014 \u010disti vrijednost navedenih nakon direktive headera. <br \/>\n<b>lua_need_request_body <\/b>\u2014 regulira treba li pro\u010ditati izvorno tijelo zahtjeva prije nego \u0161to se izvr\u0161e direktive rewrite\/access\/access_by_lua ili ne. Prema zadanim postavkama nginx ne \u010dita tijelo zahtjeva klijenta, a ako trebate pristupiti istome, ova direktiva mora imati vrijednost on.<br \/>\n<b>rewrite_by_lua_file<\/b> \u2014 put do skripte gdje je opisana logika za modifikaciju zahtjeva<br \/>\n<b>access_by_lua_file <\/b>\u2014 put do skripte gdje je opisana logika koja provjerava dostupnost resursa. <br \/>\n<b>proxy_pass <\/b>\u2014 url na koji \u0107e zahtjev biti proksiran.<br \/>\n<b>body_filter_by_lua_file <\/b>\u2014 put do skripte gdje je opisana logika za filtriranje zahtjeva prije vra\u0107anja klijentu.<br \/>\nI, na kraju, <b>post_action<\/b> \u2014 slu\u017ebeno nedokumentirana direktiva pomo\u0107u koje se mogu izvoditi dodatne radnje nakon \u0161to je odgovor poslan klijentu. <\/p>\n<p>Sljede\u0107e \u0107emo opisati redoslijedom kako smo rje\u0161avali svoje zadatke.<\/p>\n<h3>Autorizacija\/ autentifikacija i modifikacija zahtjeva<\/h3>\n<p>\n<b>Autorizacija<\/b><\/p>\n<p>Autorizaciju i autentifikaciju izgradili smo pomo\u0107u pristupa putem certifikata. Imamo korijenski certifikat. Svakom novom klijentu naru\u010ditelja generira se njegov osobni certifikat, s kojim mo\u017ee pristupiti API-ju. Ovaj certifikat se konfigurira u sekciji server pode\u0161avanja nginx-a.<\/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>Mo\u017ee se postaviti po\u0161teno pitanje: \u0161to u\u010diniti s certificiranim klijentom ako iznenada po\u017eelimo isklju\u010diti ga iz sustava? Ne mo\u017eemo ponovno izdavati certifikate za sve ostale klijente. <\/p>\n<p>Tako smo polako do\u0161li do sljede\u0107e zada\u0107e \u2014 modifikacija izvornog zahtjeva. Izvorni zahtjev klijenta, u na\u010delu, nije valjan za kona\u010dni sustav. Jedan od zadataka je dodati nedostaju\u0107e dijelove u zahtjev kako bi ga u\u010dinili valjanim. Problem je u tome \u0161to nedostaju\u0107i podaci variraju za svakog klijenta. Znamo da klijent dolazi k nama s certifikatom iz kojeg mo\u017eemo uzeti otisak i izvu\u0107i potrebne podatke klijenta iz baze. <\/p>\n<p>Ako u nekom trenutku bude potrebno isklju\u010diti klijenta iz na\u0161eg servisa, njegovi podaci \u0107e nestati iz baze i ne\u0107e mo\u0107i ni\u0161ta raditi. <\/p>\n<h3>Rad s podacima klijenta<\/h3>\n<p>\nTrebalo nam je osigurati visoku dostupnost rje\u0161enja, posebno u na\u010dinu na koji dobivamo podatke klijenta. Te\u017eina le\u017ei u tome \u0161to je izvor tih podataka \u2014 vanjska usluga koja ne jam\u010di neprekidno i dovoljno visoko radno brzinu. <\/p>\n<p>Zbog toga smo trebali osigurati visoku dostupnost podataka klijenata. Kao alat odabrali smo <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/\">Hazelcast<\/a><\/noindex>, koji nam pru\u017ea:<\/p>\n<ul>\n<li>brzi pristup podacima,<\/li>\n<li>mogu\u0107nost organiziranja klastera od vi\u0161e \u010dvorova s repliciranim podacima na razli\u010ditim \u010dvorovima.<\/li>\n<\/ul>\n<p>\nOdabrali smo najjednostavniju strategiju isporuke podataka u predmemoriju:<\/p>\n<p><img decoding=\"async\" alt=\"Na\u0161e iskustvo u stvaranju API Gatewaya\" src=\"\/wp-content\/uploads\/2019\/04\/0175d6f0fda543566ab13d4cae9d8cc1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nRad s krajnjim sustavom odvija se unutar sesija i postoji ograni\u010denje na maksimalni broj. Ako klijent ne zatvori sesiju, to \u0107emo morati u\u010diniti mi. <\/p>\n<p>Podaci o otvorenoj sesiji dolaze iz krajnjeg sustava i prvotno se obra\u0111uju na strani Lua. Odlu\u010dili smo koristiti Hazelcast za pohranu ovih podataka uz pomo\u0107 posla napisanog na .NET-u. Zatim s odre\u0111enom periodi\u010dno\u0161\u0107u provjeravamo status otvorenih sesija i zatvaramo iste koje su istekle. <\/p>\n<h3>Pristup Hazelcastu i iz Lua i iz .NET<\/h3>\n<p>\nNa Lua nema klijenata za rad s Hazelcastom, ali Hazelcast ima REST API koji smo odlu\u010dili iskoristiti. Za .NET imamo <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/clients\/net\/\">klijent<\/a><\/noindex>, preko kojeg smo planirali dobiti pristup podacima Hazelcast na strani .NET-a. No, to nije bilo tako jednostavno.<\/p>\n<p><img decoding=\"async\" alt=\"Na\u0161e iskustvo u stvaranju API Gatewaya\" src=\"\/wp-content\/uploads\/2019\/04\/52c9437e5cd16073b56afc55a4f415da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPri pohrani podataka putem REST-a i njihovom dohva\u0107anju putem .NET klijenta koriste se razli\u010diti serijalizatori\/deserijalizatori. Stoga nije mogu\u0107e pohraniti podatke putem REST-a, a zatim ih dohvatiti putem .NET klijenta i obrnuto. <\/p>\n<p>Ako \u0107e biti zainteresiranih, detaljnije \u0107emo o ovom problemu pisati u posebnom \u010dlanku. Spoiler \u2014 na shemici. <\/p>\n<p><img decoding=\"async\" alt=\"Na\u0161e iskustvo u stvaranju API Gatewaya\" src=\"\/wp-content\/uploads\/2019\/04\/73bb11214fdaeca86ef10cdbd788e288.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Zapisivanje i pra\u0107enje<\/h3>\n<p>\nNa\u0161 korporativni standard za zapisivanje putem .NET-a je Serilog, svi logovi na kraju odlaze u Elasticsearch, a njihovu analizu obavljamo putem Kibane. Ne\u0161to sli\u010dno smo htjeli posti\u0107i i u ovom slu\u010daju. Jedini <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DhavalKapil\/elasticsearch-lua\">klijent<\/a><\/noindex> alat za rad s Elasticom na Lua, koji je prona\u0111en, slomio se ve\u0107 prilikom prvog require. I koristili smo Fluentd. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.fluentd.org\/\">Fluentd<\/a><\/noindex> \u2014 open source rje\u0161enje za osiguranje jedinstvenog sloja zapisivanja aplikacije. Omogu\u0107ava prikupljanje logova s razli\u010ditih slojeva aplikacije, a zatim njihovo preusmjeravanje u jedinstveni izvor. <\/p>\n<p>API Gateway radi u K8S, stoga smo odlu\u010dili dodati kontejner s fluentd-om u isti pod, kako bismo zapisivali logove u postoje\u0107i otvoreni tcp port fluentd-a. <\/p>\n<p>Tako\u0111er smo istra\u017eivali kako \u0107e se fluentd pona\u0161ati ako ne bude imao vezu s Elasticsearchom. Tijekom dva dana u gateway su neprekidno dolazili zahtjevi, a u fluentd su se slali logovi, ali je fluentd-ov IP bio blokiran od strane Elastic-a. Nakon uspostavljanja veze, fluentd je odli\u010dno prenio apsolutno sve logove u Elastic.<\/p>\n<h3>Zaklju\u010dak<\/h3>\n<p>\nOdabrani pristup implementaciji omogu\u0107io nam je da dostavimo stvarno funkcionalan proizvod u produkcijsko okru\u017eenje za samo 2.5 mjeseca.<\/p>\n<p>Ako se ikada upustite u sli\u010dne projekte, preporu\u010dujemo da prvo jasno shvatite koju svrhu \u017eelite posti\u0107i i koje resurse ve\u0107 imate na raspolaganju. Budite oprezni s pote\u0161ko\u0107ama integracije s postoje\u0107im sustavima upravljanja API-jem. <\/p>\n<p>Razumite \u0161to to\u010dno planirate razvijati \u2014 samo poslovnu logiku obrade zahtjeva ili, kao \u0161to je to bio na\u0161 slu\u010daj, cjelokupni proxy. Ne zaboravite, sve \u0161to izradite mora naknadno biti 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\/hr\/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=\"hr_HR\" \/>\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\/hr\/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\u0161e iskustvo u kreiranju API Gatewaya | ProHoster","description":"Neke tvrtke, uklju\u010duju\u0107i na\u0161eg klijenta, razvijaju proizvod putem partnerske mre\u017ee.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/30792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=30792"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/30792\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/22777"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=30792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=30792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=30792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}