Antipola: Menentukan beberapa ProxyEndpoints di 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.
Konfigurasi ProxyEndpoint menentukan cara aplikasi klien menggunakan API melalui Apigee.
ProxyEndpoint menentukan URL proxy API dan perilaku proxy: kebijakan mana yang akan diterapkan dan endpoint target mana yang akan dirutekan, serta kondisi yang perlu dipenuhi agar kebijakan atau aturan rute ini dapat dijalankan.
Singkatnya, konfigurasi ProxyEndpoint menentukan semua yang perlu dilakukan untuk menerapkan
API.
Antipola
Proxy API dapat memiliki satu atau beberapa endpoint proxy. Menentukan beberapa ProxyEndpoints adalah mekanisme yang mudah
dan sederhana untuk menerapkan beberapa API dalam satu proxy. Hal ini memungkinkan Anda menggunakan kembali kebijakan
dan/atau logika bisnis sebelum dan sesudah pemanggilan TargetEndpoint.
Di sisi lain, saat menentukan beberapa ProxyEndpoints dalam satu proxy API, Anda akan
menggabungkan banyak API yang tidak terkait secara konseptual menjadi satu artefak. Hal ini membuat proxy API lebih sulit
dibaca, dipahami, di-debug, dan dikelola. Hal ini bertentangan dengan filosofi utama proxy API: memudahkan
developer membuat dan mengelola API.
Dampak
Beberapa ProxyEndpoints di proxy API dapat:
Sulitkan developer untuk memahami dan mengelola proxy API.
Menyamarkan analisis. Secara default, data analisis digabungkan di tingkat proxy. Tidak ada
pengelompokan metrik menurut endpoint proxy kecuali jika Anda membuat laporan kustom.
Sulit memecahkan masalah terkait proxy API.
Praktik terbaik
Saat Anda menerapkan proxy API baru atau mendesain ulang proxy API yang ada, gunakan
praktik terbaik berikut:
Terapkan satu proxy API dengan satu ProxyEndpoint.
Jika ada beberapa API yang memiliki server target yang sama dan/atau memerlukan logika yang sama sebelum
atau setelah pemanggilan server target, pertimbangkan untuk menggunakan alur bersama guna menerapkan logika tersebut di
proxy API yang berbeda.
Jika ada beberapa API yang memiliki jalur dasar awal yang sama, tetapi berbeda dalam akhiran,
gunakan alur kondisional dalam satu ProxyEndpoint.
Jika ada proxy API dengan beberapa ProxyEndpoints dan jika tidak ada masalah dengan proxy tersebut,
Anda tidak perlu melakukan tindakan apa pun.
Menggunakan satu ProxyEndpoint per proxy API akan menyebabkan:
Proksi yang lebih sederhana dan mudah dikelola
Informasi yang lebih baik di Analytics, seperti performa proxy dan waktu respons target, akan dilaporkan secara terpisah, bukan digabungkan untuk semua ProxyEndpoints
Pemecahan masalah dan penyelesaian masalah yang lebih cepat
[[["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-08-21 UTC."],[[["\u003cp\u003eApigee ProxyEndpoints define how client apps interact with APIs, including URL, behavior, policies, target routing, and execution conditions.\u003c/p\u003e\n"],["\u003cp\u003eWhile defining multiple ProxyEndpoints in a single API proxy can implement multiple APIs, it can also lead to complexity, making the API proxy harder to understand, debug, and maintain.\u003c/p\u003e\n"],["\u003cp\u003eMultiple ProxyEndpoints obfuscate analytics data, making it harder to break down metrics by proxy endpoint without custom reports and making troubleshooting more difficult.\u003c/p\u003e\n"],["\u003cp\u003eThe best practice is to use one API proxy with a single ProxyEndpoint to promote easier maintenance, clearer analytics, and faster troubleshooting.\u003c/p\u003e\n"],["\u003cp\u003eShared flows can implement common logic across multiple APIs, while conditional flows can handle multiple APIs sharing a base path within a single ProxyEndpoint.\u003c/p\u003e\n"]]],[],null,["*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/multiple-proxyendpoints) documentation.*\n\nThe ProxyEndpoint configuration defines the way client apps consume the APIs through Apigee.\nThe ProxyEndpoint defines the URL of the API proxy and how a proxy behaves: which policies to apply\nand which target endpoints to route to, and the conditions that need to be met for these policies or\nroute rules to be executed.\n\nIn short, the ProxyEndpoint configuration defines all that needs to be done to implement an\nAPI.\n\nAntipattern\n\nAn API proxy can have one or more proxy endpoints. Defining multiple ProxyEndpoints is an easy\nand simple mechanism to implement multiple APIs in a single proxy. This lets you reuse policies\nand/or business logic before and after the invocation of a TargetEndpoint.\n\nOn the other hand, when defining multiple ProxyEndpoints in a single API proxy, you end up\nconceptually combining many unrelated APIs into a single artifact. It makes the API proxies harder\nto read, understand, debug, and maintain. This defeats the main philosophy of API proxies: making\nit easy for developers to create and maintain APIs.\n\nImpact\n\nMultiple ProxyEndpoints in an API proxy can:\n\n- Make it hard for developers to understand and maintain the API proxy.\n- Obfuscate analytics. By default, analytics data is aggregated at the proxy level. There is no breakdown of metrics by proxy endpoint unless you create custom reports.\n- Make it difficult to troubleshoot problems with API proxies.\n\nBest practice\n\nWhen you are implementing a new API proxy or redesigning an existing API proxy, use the\nfollowing best practices:\n\n1. Implement one API proxy with a single ProxyEndpoint.\n2. If there are multiple APIs that share common target server and/or require the same logic pre- or post-invocation of the target server, consider using shared flows to implement such logic in different API proxies.\n3. If there are multiple APIs that share a common starting base path, but differ in the suffix, use conditional flows in a single ProxyEndpoint.\n4. If there exists an API proxy with multiple ProxyEndpoints and if there are no issues with it, then there is no need to take any action.\n\nUsing one ProxyEndpoint per API proxy leads to:\n\n1. Simpler, easier to maintain proxies\n2. Better information in Analytics, such as proxy performance and target response time, will be reported separately instead of rolled up for all ProxyEndpoints\n3. Faster troubleshooting and issue resolution\n\nFurther reading\n\n- [API Proxy Configuration Reference](/apigee/docs/api-platform/reference/api-proxy-configuration-reference)\n- [Reusable shared flows](/apigee/docs/api-platform/fundamentals/shared-flows)"]]
