{"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\/no\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","title":{"rendered":"V\u00e5r erfaring med \u00e5 opprette API Gateway","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Noen selskaper, inkludert v\u00e5r kunde, utvikler produkter gjennom et partnernettverk. For eksempel er store nettbutikker integrert med leveringsservice \u2013 du bestiller et produkt og f\u00e5r snart et sporingsnummer for pakken. Et annet eksempel er at du kj\u00f8per en forsikring eller billett til ekspresstoget sammen med flybilletten.<\/p>\n<p>Dette gj\u00f8res ved hjelp av et API som m\u00e5 gis til partnerne via API Gateway. Denne oppgaven har vi l\u00f8st. I denne artikkelen vil vi beskrive detaljene.<\/p>\n<p>Gitt: et \u00f8kosystem og et API-portal med et grensesnitt, hvor brukerne er registrert, f\u00e5r informasjon osv. Vi m\u00e5 lage en brukervennlig og p\u00e5litelig API Gateway. I prosessen m\u00e5tte vi sikre <\/p>\n<ul>\n<li>registrering, <\/li>\n<li>kontroll av tilkoblinger til API, <\/li>\n<li>overv\u00e5king av hvordan brukerne bruker det endelige systemet, <\/li>\n<li>behandling av forretningsindikatorer.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"V\u00e5r erfaring med \u00e5 opprette API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/4fa66fd4573af16b0bc78aa61173f907.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI artikkelen vil vi dele v\u00e5r erfaring med \u00e5 lage API Gateway, hvor vi l\u00f8ste f\u00f8lgende oppgaver:<\/p>\n<ul>\n<li>autentisering av brukeren,<\/li>\n<li>autorisering av brukeren,<\/li>\n<li>modifisering av den opprinnelige foresp\u00f8rselen,<\/li>\n<li>proxying av foresp\u00f8rselen,<\/li>\n<li>etterbehandling av svaret.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nDet finnes to typer API-h\u00e5ndtering:<\/p>\n<p>1. Standard, som fungerer p\u00e5 f\u00f8lgende m\u00e5te. F\u00f8r tilkoblingen tester brukeren mulighetene, deretter betaler han og integrerer p\u00e5 sin nettside. Dette brukes oftest av sm\u00e5 og mellomstore bedrifter.<\/p>\n<p>2. Stor B2B API Management, der selskapet f\u00f8rst tar en forretningsbeslutning om tilkobling, blir partner med selskapskontrakt, f\u00f8r de kobles til API. Etter \u00e5 ha ordnet alle formaliteter f\u00e5r selskapet testtilgang, gjennomg\u00e5r testing og g\u00e5r i produksjon. Men dette er ikke mulig uten ledelsesvedtak om tilkobling. <\/p>\n<p><img decoding=\"async\" alt=\"V\u00e5r erfaring med \u00e5 opprette API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b9ab53d6c64d5a971c4950cd340ad42e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3> V\u00e5r l\u00f8sning<\/h3>\n<p>\nI denne delen vil vi fortelle om opprettelsen av API Gateway.<\/p>\n<p>Sluttbrukerne av den opprettede API-gatewayen er partnere av v\u00e5r kunde. For hver av dem har vi allerede lagret de n\u00f8dvendige kontraktene. Vi m\u00e5 bare utvide funksjonaliteten ved \u00e5 merke den gitte tilgangen til gatewayen. Dermed trengs en kontrollert prosess for tilkobling og forvaltning.<\/p>\n<p>Selvf\u00f8lgelig kunne vi valgt en allerede eksisterende l\u00f8sning for API Management og opprettelse av API Gateway spesielt. For eksempel kunne dette v\u00e6rt<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/api-management\/\"> Azure API Management<\/a><\/noindex>. Dette passet oss ikke, fordi vi allerede hadde en API-portal og et stort \u00f8kosystem bygget rundt den. Alle brukere var allerede registrert, de forsto allerede hvor og hvordan de kunne f\u00e5 den informasjonen de trengte. API-portalen hadde allerede de n\u00f8dvendige grensesnittene, vi hadde bare behov for en API Gateway. Egentlig var det utviklingen av den vi begynte \u00e5 fokusere p\u00e5. <\/p>\n<p>Det vi kaller API Gateway er en slags proxy. Her hadde vi igjen et valg \u2013 vi kunne skrive v\u00e5r egen proxy, eller velge noe ferdig. I dette tilfellet valgte vi den andre veien og gikk for en kombinasjon av nginx+Lua. Hvorfor? Vi trengte p\u00e5litelig, testet programvare som st\u00f8tter skalering. Vi \u00f8nsket ikke \u00e5 sjekke b\u00e5de forretningslogikkens korrekthet og proxyens funksjonalitet etter implementasjonen. <\/p>\n<p>Hver webserver har en behandlingspipeline for foresp\u00f8rselen. I tilfelle av nginx ser den slik ut:<\/p>\n<p><img decoding=\"async\" alt=\"V\u00e5r erfaring med \u00e5 opprette API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b4cba1d37cc769202f92df052b45c77e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n(skjema fra <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">GitHub Lua Nginx<\/a><\/noindex>)<\/p>\n<p>M\u00e5let v\u00e5rt var \u00e5 integrere oss i denne pipelinen p\u00e5 det punktet hvor vi kan modifisere den originale foresp\u00f8rselen. <\/p>\n<p>Vi \u00f8nsker \u00e5 lage en transparent proxy, slik at foresp\u00f8rselen forblir den samme som n\u00e5r den kom inn. Vi kontrollerer bare tilgangen til den endelige API-en, og hjelper foresp\u00f8rselen med \u00e5 n\u00e5 frem til den. Hvis foresp\u00f8rselen er feil, skal den endelige API-en vise feilen, ikke vi. Den eneste grunnen til at vi kan avvise en foresp\u00f8rsel er mangel p\u00e5 tilgang for klienten. <\/p>\n<p>For nginx eksisterer det allerede <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">SPARQL og<\/a><\/noindex> En funksjon har blitt <noindex><a rel=\"nofollow\" href=\"http:\/\/www.lua.ru\/\">Lua<\/a><\/noindex>. Lua er et skriptspr\u00e5k, det er sv\u00e6rt lettvekts og enkelt \u00e5 l\u00e6re. Dermed implementerte vi den n\u00f8dvendige logikken med hjelp av Lua. <\/p>\n<p>Konfigurasjonen av nginx (analog med ruteapplikasjonen), der alt arbeidet utf\u00f8res, er ganske forst\u00e5elig. Den siste direktiven \u2013 post_action \u2013 er bemerkelsesverdig.<\/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>\nLa oss se hva som skjer i denne konfigurasjonen: <br \/>\n<b>more_clear_input_headers<\/b> \u2013 renser verdien angitt etter direktivet for overskrifter. <br \/>\n<b>lua_need_request_body <\/b>\u2013 regulerer om den originale foresp\u00f8rselens kropp skal leses f\u00f8r direktivene rewrite\/access\/access_by_lua utf\u00f8res eller ikke. Som standard leser ikke nginx foresp\u00f8rselens kropp, og hvis du trenger tilgang til den, m\u00e5 denne direktiven settes til on.<br \/>\n<b>rewrite_by_lua_file<\/b> \u2014 sti for skrift, der beskriver logikken for \u00e5 modifisere foresp\u00f8rselen<br \/>\n<b>access_by_lua_file <\/b>\u2014 sti for skriptet som inneholder logikken som sjekker om det er tilgang til ressursen. <br \/>\n<b>proxy_pass <\/b>\u2014 url-en som foresp\u00f8rselen vil bli proxyert til.<br \/>\n<b>body_filter_by_lua_file <\/b>\u2014 sti for skriptet som inneholder logikken for filtrering av foresp\u00f8rselen f\u00f8r den returneres til klienten.<br \/>\nOg til slutt, <b>post_action<\/b> \u2014 en offisielt udokumentert direktiv som kan brukes til \u00e5 utf\u00f8re flere handlinger etter at svaret er gitt til klienten. <\/p>\n<p>Deretter skal vi forklare i rekkef\u00f8lge hvordan vi l\u00f8ste v\u00e5re oppgaver.<\/p>\n<h3>Autorisasjon\/autentisering og modifisering av foresp\u00f8rselen<\/h3>\n<p>\n<b>Autorisering<\/b><\/p>\n<p>Vi bygde autorisasjonen og autentiseringen ved hjelp av tilgang basert p\u00e5 sertifikat. Det er et rotsertifikat. Hver ny kunde av kunden f\u00e5r sitt eget personlige sertifikat, som gir dem tilgang til API-en. Dette sertifikatet konfigureres i server-delen av nginx-innstillingene.<\/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>Modifisering<\/b><\/p>\n<p>Det kan stilles et rettferdig sp\u00f8rsm\u00e5l: hva skal vi gj\u00f8re med sertifiserte kunder hvis vi plutselig \u00f8nsker \u00e5 frakoble dem fra systemet? Skal vi ikke forny sertifikatene for alle de andre kundene? <\/p>\n<p>Slik har vi smidig kommet til neste oppgave \u2014 modifisering av den opprinnelige foresp\u00f8rselen. Den opprinnelige foresp\u00f8rselen fra kunden er ikke gyldig for det endelige systemet. En av oppgavene er \u00e5 legge til manglende deler i foresp\u00f8rselen for \u00e5 gj\u00f8re den gyldig. Poenget er at de manglende dataene er forskjellige for hver kunde. Vi vet at kunden kommer til oss med et sertifikat, fra hvilket vi kan ta et fingeravtrykk og hente de n\u00f8dvendige kundedataene fra databasen. <\/p>\n<p>Hvis det p\u00e5 et tidspunkt blir n\u00f8dvendig \u00e5 frakoble kunden fra v\u00e5r tjeneste, vil dataene deres forsvinne fra databasen, og de vil ikke kunne gj\u00f8re noe. <\/p>\n<h3>H\u00e5ndtering av kundedata<\/h3>\n<p>\nVi m\u00e5tte sikre h\u00f8y tilgjengelighet av l\u00f8sningen, spesielt for hvordan vi henter kundedataene. Utfordringen er at den prim\u00e6re kilden til disse dataene er en tredjepartstjeneste som ikke garanterer p\u00e5litelig og tilstrekkelig h\u00f8y hastighet. <\/p>\n<p>Derfor m\u00e5tte vi sikre h\u00f8y tilgjengelighet for kundedataene. Som verkt\u00f8y valgte vi <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/\">Hazelcast<\/a><\/noindex>, som gir oss:<\/p>\n<ul>\n<li>raskap for data,<\/li>\n<li>mulighet til \u00e5 organisere en klynge av flere noder med replikerte data p\u00e5 forskjellige noder.<\/li>\n<\/ul>\n<p>\nVi fulgte den enkleste strategien for datalevering til cache:<\/p>\n<p><img decoding=\"async\" alt=\"V\u00e5r erfaring med \u00e5 opprette API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/0175d6f0fda543566ab13d4cae9d8cc1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSamarbeid med det endelige systemet skjer innenfor sesjoner, og det er en grense for det maksimale antallet. Hvis kunden ikke har lukket sesjonen, m\u00e5 vi gj\u00f8re det. <\/p>\n<p>Data om \u00e5pne sesjoner kommer fra det endelige systemet og behandles f\u00f8rst p\u00e5 Lua-siden. Vi bestemte oss for \u00e5 bruke Hazelcast for \u00e5 lagre disse dataene med en jobb skrevet i .NET. Deretter sjekker vi regelmessig livsretten til \u00e5pne sesjoner og stenger utg\u00e5tte. <\/p>\n<h3>Tilgang til Hazelcast b\u00e5de fra Lua og .NET<\/h3>\n<p>\nDet finnes ingen Lua-klienter for \u00e5 jobbe med Hazelcast, men Hazelcast har et REST API, som vi valgte \u00e5 bruke. For .NET er det <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/clients\/net\/\">klienten<\/a><\/noindex>, som vi planla \u00e5 bruke for \u00e5 f\u00e5 tilgang til dataene fra Hazelcast p\u00e5 .NET-siden. Men slik gikk det ikke.<\/p>\n<p><img decoding=\"async\" alt=\"V\u00e5r erfaring med \u00e5 opprette API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/52c9437e5cd16073b56afc55a4f415da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVed lagring av data gjennom REST og uthenting via .NET-klienten brukes forskjellige serializator-deserializatorer. Derfor er det umulig \u00e5 legge inn data via REST og hente dem ut via .NET-klienten og omvendt. <\/p>\n<p>Hvis det er interesserte, kan vi fortelle mer om dette problemet i en egen artikkel. Spoiler \u2014 p\u00e5 diagrammet. <\/p>\n<p><img decoding=\"async\" alt=\"V\u00e5r erfaring med \u00e5 opprette API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/73bb11214fdaeca86ef10cdbd788e288.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Logging og overv\u00e5king<\/h3>\n<p>\nV\u00e5r bedriftsstandard for logging via .NET \u2014 Serilog, alle logger havner til slutt i Elasticsearch, og analysen foreg\u00e5r via Kibana. Noe lignende \u00f8nsket vi \u00e5 gj\u00f8re i dette tilfellet. Den eneste <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DhavalKapil\/elasticsearch-lua\">klienten<\/a><\/noindex> som ble funnet for \u00e5 jobbe med Elastic p\u00e5 Lua, krasjet ved f\u00f8rste require. Og vi brukte Fluentd. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.fluentd.org\/\">Fluentd<\/a><\/noindex> \u2014 en open source-l\u00f8sning for \u00e5 gi et samlet lag av applikasjonslogging. Den lar oss samle logger fra ulike niv\u00e5er av applikasjonen, og deretter videresende dem til en enhetlig kilde. <\/p>\n<p>API Gateway kj\u00f8rer i K8S, s\u00e5 vi bestemte oss for \u00e5 legge til en container med fluentd i samme pod, for \u00e5 skrive logger til den eksisterende \u00e5pne tcp-porten til fluentd. <\/p>\n<p>Vi unders\u00f8kte ogs\u00e5 hvordan fluentd ville oppf\u00f8re seg hvis den ikke hadde forbindelse med Elasticsearch. I l\u00f8pet av to dager ble det kontinuerlig sendt foresp\u00f8rsel til gatewayen, logger ble sendt til fluentd, men IP-adressen til Elastic ble blokkert. Etter at forbindelsen ble gjenopprettet, slapp fluentd ut absolutt alle logger til Elastic.<\/p>\n<h3>Konklusjon<\/h3>\n<p>\nDen valgte tiln\u00e6rmingen for implementering gjorde at vi klarte \u00e5 levere et fullt fungerende produkt i produksjonsmilj\u00f8et p\u00e5 bare 2,5 m\u00e5neder.<\/p>\n<p>Hvis du noen gang m\u00e5 h\u00e5ndtere lignende ting, anbefaler vi f\u00f8rst og fremst \u00e5 tydelig forst\u00e5 hvilken oppgave du l\u00f8ser og hvilke ressurser du allerede har. V\u00e6r oppmerksom p\u00e5 utfordringene med integrering med eksisterende API-styringssystemer. <\/p>\n<p>Skj\u00f8nn for deg selv hva n\u00f8yaktig du planlegger \u00e5 utvikle \u2014 bare forretningslogikken for \u00e5 behandle foresp\u00f8rslene eller, som det kan ha v\u00e6rt i v\u00e5rt tilfelle, hele proxyen. Ikke glem at alt du gj\u00f8r selv, m\u00e5 testes grundig etterp\u00e5.<br \/>\n<br \/>Kilde: <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.5 - 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\/no\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"nn_NO\" \/>\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\/no\/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\udd47V\u00e5r erfaring med \u00e5 lage API Gateway | ProHoster","description":"Noen selskaper, inkludert v\u00e5r kunde, utvikler produktet sitt gjennom et partnerskapsnettverk.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/30792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=30792"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/30792\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/22777"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=30792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=30792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=30792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}