Antipola: Memanggil panggilan API Apigee dari proxy API
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Anda sedang melihat dokumentasi Apigee dan Apigee hybrid.
Lihat dokumentasi
Apigee Edge.
Apigee memiliki utilitas canggih yang disebut Apigee API yang menawarkan layanan seperti:
Men-deploy atau membatalkan deployment proxy API
Mengonfigurasi host virtual, keystore, dan truststore, dan sebagainya
Membuat, menghapus, dan memperbarui entity seperti peta nilai kunci (KVM), produk API, aplikasi developer, developer, kunci konsumen, dan sebagainya
Mengambil informasi tentang entity ini
Layanan ini dapat diakses melalui komponen yang disebut Server Pengelolaan di
platform Apigee. Layanan ini dapat dipanggil dengan mudah dengan bantuan panggilan API
sederhana.
Terkadang kita mungkin perlu menggunakan satu atau beberapa layanan ini dari proxy API saat runtime. Hal ini
karena entitas seperti KVM, token akses OAuth, produk API, aplikasi developer,
developer, kunci konsumen, dan sebagainya berisi informasi yang berguna dalam bentuk pasangan nilai kunci, atribut
kustom, atau sebagai bagian dari profilnya.
Misalnya, Anda dapat menyimpan informasi berikut di KVM agar lebih aman dan
dapat diakses saat runtime:
URL target backend
Properti lingkungan
Kredensial keamanan sistem backend atau pihak ketiga
Demikian pula, Anda mungkin ingin mendapatkan daftar produk API atau alamat email developer saat runtime.
Informasi ini akan tersedia sebagai bagian dari profil aplikasi developer.
Semua informasi ini dapat digunakan secara efektif saat runtime untuk mengaktifkan perilaku dinamis dalam kebijakan
atau kode kustom dalam Apigee.
Antipola
Api Apigee lebih disukai dan berguna untuk tugas administratif dan tidak boleh digunakan untuk
melakukan logika runtime apa pun dalam alur proxy API. Hal ini dikarenakan:
Menggunakan Apigee API untuk mengakses informasi tentang entitas seperti KVM, token akses OAuth, atau untuk tujuan lain dari proxy API akan menyebabkan dependensi pada Server Pengelolaan.
Server Pengelolaan bukan bagian dari komponen runtime Apigee sehingga mungkin tidak
sangat tersedia.
Server Pengelolaan juga mungkin tidak disediakan dalam jaringan atau pusat data yang sama sehingga dapat
menyebabkan latensi jaringan saat runtime.
Entri di Server Pengelolaan di-cache selama jangka waktu yang lebih lama, sehingga Anda mungkin tidak dapat langsung melihat data terbaru di proxy API jika Anda melakukan operasi tulis dan baca dalam waktu singkat.
Meningkatkan hop jaringan saat runtime.
Pada contoh kode di bawah, panggilan Apigee API dilakukan melalui kode JavaScript kustom untuk
mengambil informasi dari KVM:
Jika Server Pengelolaan tidak tersedia, kode JavaScript yang memanggil panggilan API Apigee akan gagal. Hal ini kemudian menyebabkan permintaan API gagal.
Dampak
Memperkenalkan dependensi tambahan pada Server Pengelolaan selama runtime. Setiap kegagalan di
Server Pengelolaan akan memengaruhi panggilan API.
Kredensial pengguna untuk Apigee API harus disimpan secara lokal atau di beberapa penyimpanan aman
seperti KVM terenkripsi.
Implikasi performa karena memanggil layanan pengelolaan melalui jaringan.
Mungkin tidak langsung melihat nilai yang diperbarui karena masa berlaku cache yang lebih lama di Server
Pengelolaan.
Praktik terbaik
Ada cara yang lebih efektif untuk mengambil informasi dari entitas seperti KVM, produk
API, aplikasi developer, developer, kunci konsumen, dan sebagainya saat runtime. Berikut adalah beberapa contohnya:
Gunakan kebijakan KeyValueMapOperations untuk mengakses informasi dari KVM. Berikut adalah contoh kode
yang menunjukkan cara mengambil informasi dari KVM:
Untuk mengakses informasi tentang produk API, aplikasi developer, developer, kunci konsumen, dan sebagainya
di proxy API, Anda dapat melakukan salah satu hal berikut:
Jika alur API Proxy Anda memiliki kebijakan VerifyAPIKey, Anda dapat mengakses informasi menggunakan variabel alur yang diisi sebagai bagian dari kebijakan ini. Berikut adalah contoh kode yang menunjukkan cara mengambil nama dan informasi created_by Aplikasi Developer menggunakan JavaScript:
<!--/antipatterns/examples/2-7.xml-->
print("Application Name ",context.getVariable(""verifyapikey.VerifyAPIKey.app.name"));print("Createdby:", context.getVariable("verifyapikey.VerifyAPIKey.app.created_by"));
Jika alur API Proxy Anda tidak memiliki kebijakan VerifyAPIKey, Anda dapat mengakses
profil produk API, aplikasi developer, dan sebagainya menggunakan kebijakan AccessEntity dan ExtractVariables:
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-05 UTC."],[[["\u003cp\u003eThe Apigee API is designed for administrative tasks and should not be used for runtime logic within API proxies, as it creates dependency on the Management Servers.\u003c/p\u003e\n"],["\u003cp\u003eRelying on Apigee APIs at runtime can cause performance issues and introduce network latencies because Management Servers are not part of the runtime components and may not be in the same network or data center.\u003c/p\u003e\n"],["\u003cp\u003eDirect calls to Management Servers can lead to outdated data being retrieved by API proxies due to longer caching periods, affecting data accuracy.\u003c/p\u003e\n"],["\u003cp\u003eFor accessing information at runtime, it is more effective to use policies like \u003ccode\u003eKeyValueMapOperations\u003c/code\u003e for KVM data or flow variables from the \u003ccode\u003eVerifyAPIKey\u003c/code\u003e policy for API products and developer app information, instead of calling the Apigee API.\u003c/p\u003e\n"],["\u003cp\u003eIf \u003ccode\u003eVerifyAPIKey\u003c/code\u003e policy is not in use, \u003ccode\u003eAccessEntity\u003c/code\u003e and \u003ccode\u003eExtractVariables\u003c/code\u003e policies are preferred for retrieving profiles of entities like developer apps during runtime, ensuring efficient access to needed information.\u003c/p\u003e\n"]]],[],null,["# Antipattern: Invoke Apigee API calls from an API proxy\n\n*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/invoking-management) documentation.*\n\nApigee has a powerful utility called the [Apigee API](/apigee/docs/reference/apis/apigee/rest) which offers services such as:\n\n- Deploying or undeploying API proxies\n- Configuring virtual hosts, keystores and truststores, and so on\n- Creating, deleting and updating entities such as key value maps (KVMs), API products, developer apps, developers, consumer keys, and so on\n- Retrieving information about these entities\n\nThese services are made accessible through a component called *Management Server* in the\nApigee platform. These services can be invoked easily with the help of simple API\ncalls.\n\nSometimes we may need to use one or more of these services from API proxies at runtime. This is\nbecause the entities such as KVMs, OAuth access tokens, API products, developer apps,\ndevelopers, consumer keys, and so on contain useful information in the form of key-value pairs, custom\nattributes or as part of its profile.\n\nFor instance, you can store the following information in a KVM to make it more secure and\naccessible at runtime:\n\n- Back-end target URLs\n- Environment properties\n- Security credentials of backend or third party systems\n\nSimilarly, you may want to get the list of API products or the developer's email address at runtime.\nThis information will be available as part of the developer apps profile.\n\nAll this information can be effectively used at runtime to enable dynamic behaviour in policies\nor custom code within Apigee.\n\nAntipattern\n-----------\n\nThe Apigee APIs are preferred and useful for administrative tasks and should not be used for\nperforming any runtime logic in API proxies flow. This is because:\n\n- Using Apigee APIs to access information about the entities such as KVMs, OAuth access tokens or for any other purpose from API proxies leads to dependency on Management Servers.\n- Management Servers are not a part of Apigee runtime components and therefore, they may not be highly available.\n- Management Servers also may not be provisioned within the same network or data center and may therefore introduce network latencies at runtime.\n- The entries in the Management Servers are cached for a longer period of time, so you may not be able to see the latest data immediately in the API proxies if you perform writes and reads in a short period of time.\n- Increases network hops at runtime.\n\nIn the code sample below, the Apigee API call is made via the custom JavaScript code to\nretrieve the information from the KVM: \n\n```gdscript\nvar response = httpClient.send('https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/keyvaluemaps')\n```\n\nIf the Management Server is unavailable, then the JavaScript code invoking the Apigee API\ncall fails. This subsequently causes the API request to fail.\n\nImpact\n------\n\n- Introduces additional dependency on Management Servers during runtime. Any failure in Management Servers will affect the API calls.\n- User credentials for Apigee APIs need to be stored either locally or in some secure store such as an encrypted KVM.\n- Performance implications owing to invoking the management service over the network.\n- May not see the updated values immediately due to longer cache expiration in Management Servers.\n\nBest practice\n-------------\n\nThere are more effective ways of retrieving information from entities such as KVMs, API\nproducts, developer apps, developers, consumer keys, and so on at runtime. Here are a few examples:\n\n- Use a [KeyValueMapOperations policy](/apigee/docs/api-platform/reference/policies/key-value-map-operations-policy) to access information from KVMs. Here's sample code that shows how to retrieve information from the KVM: \n\n ```verilog\n \u003c!-- /antipatterns/examples/2-6.xml --\u003e\n \u003cKeyValueMapOperations mapIdentifier=\"urlMap\" async=\"false\"\n continueOnError=\"false\" enabled=\"true\" name=\"GetURLKVM\"\u003e\n \u003cDisplayName\u003eGetURLKVM\u003c/DisplayName\u003e\n \u003cExpiryTimeInSecs\u003e86400\u003c/ExpiryTimeInSecs\u003e\n \u003cScope\u003eenvironment\u003c/Scope\u003e\n \u003cGet assignTo=\"urlHosti\" index=\"2\"\u003e\n \u003cKey\u003e\n \u003cParameter\u003eurlHost_1\u003c/Parameter\u003e\n \u003c/Key\u003e\n \u003c/Get\u003e\n \u003c/KeyValueMapOperations\u003e\n ```\n- To access information about API products, developer apps, developers, consumer keys, and so on in the API proxy, you can do either of the following:\n - If your API Proxy flow has a [VerifyAPIKey policy](/apigee/docs/api-platform/reference/policies/verify-api-key-policy), then you can access the information using the flow variables populated as part of this policy. Here is sample code that shows how to retrieve the name and created_by information of a Developer App using JavaScript: \n\n ```css+lasso\n \u003c!-- /antipatterns/examples/2-7.xml --\u003e\n print(\"Application Name \", context.getVariable(\"\"verifyapikey. VerifyAPIKey.app.name\"));\n print(\"Created by:\", context.getVariable(\"verifyapikey. VerifyAPIKey.app.created_by\"));\n ```\n - If your API Proxy flow doesn't have a [VerifyAPIKey policy](/apigee/docs/api-platform/reference/policies/verify-api-key-policy), then you can access the profiles of API products, developer apps, and so on using the `AccessEntity` and `ExtractVariables` policies:\n 1. Retrieve the profile of developer app with the [AccessEntity policy](/apigee/docs/api-platform/reference/policies/access-entity-policy): \n\n ```carbon\n \u003c!-- /antipatterns/examples/2-8.xml --\u003e\n \u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u003e\n \u003cAccessEntity async=\"false\" continueOnError=\"false\" enabled=\"true\" name=\"GetDeveloperApp\"\u003e\n \u003cDisplayName\u003eGetDeveloperApp\u003c/DisplayName\u003e\n \u003cEntityType value=\"app\"\u003e\u003c/EntityType\u003e\n \u003cEntityIdentifier ref=\"developer.app.name\" type=\"appname\"/\u003e\n \u003cSecondaryIdentifier ref=\"developer.id\" type=\"developerid\"/\u003e\n \u003c/AccessEntity\u003e\n ```\n 2. Extract the `appId` from developer app with the [ExtractVariables policy](/apigee/docs/api-platform/reference/policies/extract-variables-policy): \n\n ```gdscript\n \u003c!-- /antipatterns/examples/2-9.xml --\u003e\n \u003cExtractVariables name=\"Extract-Developer App-Info\"\u003e\n \u003c!--\n The source element points to the variable populated by AccessEntity policy.\n The format is \u003cpolicy-type\u003e.\u003cpolicy-name\u003e\n In this case, the variable contains the whole developer profile.\n --\u003e\n \u003cSource\u003eAccessEntity.GetDeveloperApp\"\u003c/Source\u003e\n \u003cVariablePrefix\u003edeveloperapp\u003c/VariablePrefix\u003e\n \u003cXMLPayload\u003e\n \u003cVariable name=\"appld\" type=\"string\"\u003e\n \u003c!-- You parse elements from the developer profile using XPath. --\u003e\n \u003cXPath\u003e/App/AppId\u003c/XPath\u003e\n \u003c/Variable\u003e\n \u003c/XMLPayload\u003e\n \u003c/ExtractVariables\u003e\n ```\n\nFurther reading\n---------------\n\n- [KeyValueMapOperations policy](/apigee/docs/api-platform/reference/policies/key-value-map-operations-policy)\n- [VerifyAPIKey policy](/apigee/docs/api-platform/reference/policies/verify-api-key-policy)\n- [AccessEntity policy](/apigee/docs/api-platform/reference/policies/access-entity-policy)"]]
