شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات
یک پروکسی API یک نمای مدیریت شده برای خدمات باطن است. یک پیکربندی پایه پروکسی API از یک ProxyEndpoint (تعریف URL پروکسی API) و یک TargetEndpoint (تعریف URL سرویس باطن) تشکیل شده است.
Apigee Edge انعطاف پذیری زیادی را برای ایجاد رفتارهای پیچیده در بالای این الگو ارائه می دهد. به عنوان مثال، می‌توانید خط‌مشی‌هایی را برای کنترل نحوه پردازش API درخواست مشتری قبل از ارسال آن به سرویس پشتیبان اضافه کنید، یا پاسخ دریافتی از سرویس پشتیبان را قبل از ارسال آن به مشتری دستکاری کنید. می‌توانید با استفاده از خط‌مشی‌های فراخوانی سرویس ، سرویس‌های دیگر را فراخوانی کنید، رفتار سفارشی را با افزودن کد جاوا اسکریپت اضافه کنید، و حتی یک پراکسی API ایجاد کنید که سرویس پشتیبان را فراخوانی نکند.
ضد الگو
استفاده از فراخوان‌های سرویس برای فراخوانی یک سرویس پشتیبان در یک پراکسی API بدون مسیری به نقطه پایانی هدف، از نظر فنی امکان‌پذیر است، اما منجر به از دست رفتن داده‌های تحلیلی در مورد عملکرد سرویس خارجی می‌شود.
یک پروکسی API که حاوی مسیرهای هدف نیست می تواند در مواردی مفید باشد که نیازی به ارسال پیام درخواست به TargetEndpoint ندارید. در عوض، ProxyEndpoint تمام پردازش های لازم را انجام می دهد. به عنوان مثال، ProxyEndpoint می‌تواند داده‌ها را از جستجو در ذخیره‌سازی کلید/مقدار سرویس API بازیابی کند و پاسخ را بدون فراخوانی یک سرویس پشتیبان بازگرداند.
همانطور که در اینجا نشان داده شده است، می توانید یک مسیر پوچ در یک پراکسی API تعریف کنید:
<RouteRule name="noroute"/>
پروکسی که از مسیر تهی استفاده می کند، یک پروکسی "بدون هدف" است، زیرا یک سرویس باطن هدف را فراخوانی نمی کند.
همانطور که در مثال زیر نشان داده شده است، از نظر فنی می‌توان برای فراخوانی یک سرویس خارجی یک فراخوان سرویس به یک پراکسی بدون هدف اضافه کرد:
<!-- /antipatterns/examples/service-callout-no-target-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
<Description/>
<FaultRules/>
<PreFlow name="PreFlow">
<Request>
<Step>
<Name>ServiceCallout-InvokeBackend</Name>
</Step>
</Request>
<Response/>
</PreFlow>
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<Flows/>
<HTTPProxyConnection>
<BasePath>/no-target-proxy</BasePath>
<Properties/>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="noroute"/>
</ProxyEndpoint>
با این حال، پروکسی نمی تواند اطلاعات تحلیلی در مورد رفتار سرویس خارجی (مانند زمان پردازش یا نرخ خطا) ارائه دهد، که ارزیابی عملکرد سرویس خارجی را دشوار می کند.
تاثیر
- اطلاعات تجزیه و تحلیل در مورد تعامل با سرویس خارجی (کدهای خطا، زمان پاسخ، عملکرد هدف و غیره) در دسترس نیست.
- هر منطق خاصی که قبل یا بعد از فراخوانی فراخوانی سرویس مورد نیاز باشد به عنوان بخشی از منطق کلی پروکسی گنجانده شده است و درک و استفاده مجدد از آن را دشوارتر می کند.
بهترین تمرین
اگر یک پراکسی API تنها با یک سرویس خارجی منفرد تعامل داشته باشد، پروکسی باید از الگوی طراحی اولیه پیروی کند، جایی که سرویس backend به عنوان نقطه پایانی هدف پروکسی API تعریف می‌شود. یک پروکسی بدون قوانین مسیریابی به نقطه پایانی هدف، نباید با استفاده از خط مشی ServiceCallout، یک سرویس پشتیبان را فراخوانی کند.
پیکربندی پروکسی زیر همان رفتار مثال بالا را اجرا می کند، اما از بهترین شیوه ها پیروی می کند:
<!-- /antipatterns/examples/service-callout-no-target-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
<Description/>
<FaultRules/>
<PreFlow name="PreFlow">
<Request/>
<Response/>
</PreFlow>
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<Flows/>
<HTTPProxyConnection>
<BasePath>/simple-proxy-with-route-to-backend</BasePath>
<Properties/>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="default">
<TargetEndpoint>default</TargetEndpoint>
</RouteRule>
</ProxyEndpoint>
از فراخوان های سرویس برای پشتیبانی از سناریوهای mashup استفاده کنید، جایی که می خواهید خدمات خارجی را قبل یا بعد از فراخوانی نقطه پایانی هدف فراخوانی کنید. فراخوان‌های سرویس جایگزین فراخوانی نقطه پایانی هدف نیستند.