درحال مشاهده اسناد Apigee Edge هستید.
به
اسناد Apigee X بروید. اطلاعات
کارگزار API نمای مدیریتشدهای برای سرویسهای زیرینه است. پیکربندی پایه کارگزار API شامل ProxyEndpoint (تعریف نشانی وب کارگزار API) و TargetEndpoint (تعریف نشانی وب سرویس زیرینه) است.
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>
بااینحال، پراکسی نمیتواند اطلاعات تجزیهوتحلیل درباره رفتار سرویس خارجی (مثل زمان پردازش یا نرخ خطا) ارائه دهد، که ارزیابی عملکرد سرویس خارجی را دشوار میکند.
تأثیر
- اطلاعات Analytics درباره تعامل با سرویس خارجی ( کدهای خطا، زمان پاسخ، عملکرد هدف، و غیره) دردسترس نیست
- هر منطق خاصی که قبل یا بعداز فراخواندن پیامواره سرویس لازم باشد بهعنوان بخشی از منطق کلی کارگزار گنجانده میشود و درک و استفاده مجدد از آن را دشوارتر میکند.
روال مطلوب
اگر کارگزار API فقط با یک سرویس خارجی تعامل داشته باشد، کارگزار باید از الگوی طراحی پایه پیروی کند، که در آن سرویس زیرینه بهعنوان نقطه پایانی هدف کارگزار 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>
از «خدمات تماس» برای پشتیبانی از سناریوهای ترکیبی استفاده کنید، جایی که میخواهید خدمات خارجی را قبلاز یا بعداز فراخوانی نقطه پایانی هدف فراخوانی کنید. هدف از نوشتههای راهنمای خدمات جایگزینی برای فراخوانی نقطه پایانی هدف نیست.