37449
API, هوش مصنوعی

کاوش Overlay OpenAPI از طریق (بانکداری باز) Open Banking چگونه رقم می‌خورد؟

توسط . ارسال شده در

شما روال رو می‌دونید. یه انتشار API جدید به .جود می‌آید، و صرف‌نظر از اینکه طراحی اول یا کد اول برای APIهاتون انجام می‌دید، جایی باید به خانم کپی و آقای پیست تکیه کنید تا یه به‌روزرسانی در توصیف OpenAPI انجام بدید. در حالی که داشتن یه منبع واحد حقیقت برای توصیف OpenAPI مطلقاً چیزیه که باید به سمتش برید، همیشه یه ویرایش دیرهنگام، تنظیم برای فیلد هدر که گیت‌وی API شما نیاز داره، یا کپی توسط یه نویسنده فنی وجود داره که باید اضافه بشه. راه‌حل ایده‌آل برای ادغام اطلاعات در توصیف OpenAPI شما، پیاده‌سازی یه پایپ‌لاین مستندات با عملیات تجویزیه که به شما کمک کنه ادغام‌ها و تغییرات از منابع مختلف رو مدیریت کنید. این نقطه شیرین برای مشخصات Overlay OpenAPI می‌باشد. Overlay تسهیل پیاده‌سازی فرآیندهای خودکار برای اعمال بعضی از تغییرات توصیف‌شده بالاست. مثلاً، اضافه کردن یه فیلد هدر تجویزی توسط گیت‌وی API شما که توسط پیاده‌سازی‌تون نیاز یا تعریف نشده، یه مورد استفاده عالی برای Overlayه. کاربرد Overlay می‌تونه، با این حال، خیلی گسترده‌تر از یه سازمان واحد اعمال بشه، و یه مثال عملی در شکل استانداردهای Open Banking UK می‌آد. این استانداردها مقررات خاصی برای ویرایش توصیف‌های API دارن، که open banking رو یه کاربرد عالی برای Overlay می‌کنه.

مشخصات API در Open Banking UK

اکوسیستم open banking UK بر اساس APIهای استانداردشده تعریف‌شده، نگهداری‌شده و منتشرشده توسط یه نهاد مرکزیه. اکثریت قریب به اتفاق ارائه‌دهندگان خدمات پرداخت و حساب (ASPSPs) (راه فانتزی گفتن بانک در اصطلاحات مقررات open banking) باید به طراحی API استاندارد ارائه‌شده از طریق چندین سند توصیف OpenAPI پایبند باشن. با این حال، راهنماهای پیاده‌سازی استانداردها اجازه می‌دن یه ASPSP توصیف API رو به چندین راه تغییر بده، با محدودیت اینکه تغییرات باید در پورتال توسعه‌دهنده ASPSP منتشر بشن. تغییرات مجاز شامل موارد زیره:

۱. حذف عملیات API:

تحت دستورالعمل خدمات پرداخت تجدیدنظرشده (PSD2) (مقرراتی که بخش‌هایی از استانداردهای open banking رو دیکته می‌کنه)، ASPSPs باید همون توابع رو از طریق API در دسترس قرار بدن که برای مشتریان از طریق پورتال‌های آنلاین و موبایل بانکیشون در دسترسه. با این حال، ASPSPs مجبور نیستن عملکرد جدیدی که ارائه نمی‌دن و در استانداردها توصیف شده رو پیاده‌سازی کنن. مثلاً، اگر یه ASPSP پرداخت‌های مبتنی بر فایل رو به مشتریان ارائه نده، نیازی به ارائه اون از طریق APIهای PSD2 نداره. بنابراین، ASPSPs می‌تونن اگر انتخاب کنن، این رو از توصیف API منتشرشده‌شون حذف کنن.

۲. تعریف مقادیر پیشنهادی به عنوان شمارش‌ها:

استانداردهای Open Banking UK یه سیاست پیاده‌سازی کردن برای ارائه مقادیر شمارش استانداردشده که ASPSPs می‌تونن به طور جزئی یا کامل اتخاذ کنن و با مقادیر خودشون تکمیل کنن. این شمارش‌ها با استفاده از مشخصات به نام x-namespaced-enum ارائه می‌شوند. ASPSPs ملزم به انتشار مقادیری هستن که پشتیبانی می‌کنن، ایده‌آل به عنوان خاصیت enum یه رشته، جایی که از لیست استاندارد منحرف می‌شوند تا مصرف‌کنندگان API بدونن چی پشتیبانی می‌شه. چنین مقادیری شامل انواع حساب‌های پشتیبانی‌شده، ریل‌های پرداخت و شناسه‌های مؤسسات مالی برای مسیردهی پرداخت می‌شه.

۳. اضافه کردن داده‌های تکمیلی:

داده‌های تکمیلی اصطلاح ISO 20022ه که به خصوصیات یه پیام اشاره داره که به طور خاص توسط پیام توصیف نشدن و بنابراین به عنوان یه “blob” غیرقابل تجزیه که می‌تونه نادیده گرفته بشه، درمان می‌شوند. مفهوم داده‌های تکمیلی در استانداردهای Open Banking UK بازاستفاده شد تا خصوصیات استانداردشده‌ای ایجاد کنه که ASPSPs می‌تونن برای اضافه کردن خصوصیات اضافی استفاده کنن که منعکس‌کننده چیزیه که در کانال‌های آنلاین و موبایل بانکی در دسترسه. مثال‌های چنین خصوصیاتی ممکنه شامل ارجاع‌های پرداخت اضافی یا شناسه‌های برای یه مسیر پرداخت بین‌المللی خاص باشه. ASPSPs باید این تغییرات رو منتشر کنن تا ارائه‌دهندگان شخص ثالث (TPPs) (خدمات فین‌تک) بتونن داده‌ها رو به درستی پر کنن.

تغییرات مجاز تحت استانداردهای Open Banking UK راه عالی برای نشون دادن چگونگی کار Overlay روی استانداردهای صنعت و برداشتن بار دستی سنگین از انجام چنین تغییراتیه. بیاید یه مثال فرضی با استفاده از «بانک M&D» بگیریم، که می‌خواد استانداردها رو به مشخصات APIهای open banking خودش تطبیق بده.

حذف عملیات API

فرض کنید بانک M&D می‌خواد همه عملیات API پشتیبانی‌نشده رو حذف کنه، که منطقیه چون نمی‌خوان با برگردوندن مداوم ۴۰۴ به انبوه فراخوانی‌های API به عملیات‌هایی که پیاده‌سازی نشدن، سر و کله بزنن. (اینکه اونا پیاده‌سازی‌شون نکردن در یه سایت مرکزی Confluence توصیف شده و لزوماً ماشین‌خوان نیست). لطفاً توجه کنید که همه عبارات JSONPath در این مثال‌ها معناشناسی RFC 9535 رو اتخاذ می‌کنن مطابق با مشخصات Overlay. RFC 9535 حاوی پشتیبانی محدود برای تطبیق نام‌های خاصیت JSON با استفاده از wildcard یا عبارت منظم، پس اگر شما طرفدار پرشور مثلاً JSONPath Plus هستید، ممکنه عبارات رو بیش از حد طولانی پیدا کنید. بانک M&D پرداخت‌های فایل یا هر پرداخت بین‌المللی رو پشتیبانی نمی‌کنه، پس گام اولشون ایجاد اشیاء فعالیت که این‌ها رو حذف کنن:

yaml
- target: $.paths['/file-payments']
  remove: true
- target: $.paths['/file-payment-consents']
  remove: true
- target: $.paths['/file-payment-consents/{ConsentId}']
  remove: true
- target: $.paths['/file-payment-consents/{ConsentId}/file']
  remove: true
- target: $.paths['/file-payments']
  remove: true
- target: $.paths['/file-payments/{FilePaymentId}']
  remove: true
- target: $.paths['/file-payments/{FilePaymentId}/payment-details']
  remove: true
- target: $.paths['/file-payments/{FilePaymentId}/report-file']
  remove: true
- target: $.paths['/international-payment-consents']
  remove: true
- target: $.paths['/international-payment-consents/{ConsentId}']
  remove: true
- target: $.paths['/international-payment-consents/{ConsentId}/funds-confirmation']
  remove: true
- target: $.paths['/international-payments']
  remove: true
- target: $.paths['/international-payments/{InternationalPaymentId}']
  remove: true
- target: $.paths['/international-payments/{InternationalPaymentId}/payment-details']
  remove: true
- target: $.paths['/international-scheduled-payment-consents']
  remove: true
- target: $.paths['/international-scheduled-payment-consents/{ConsentId}']
  remove: true
- target: $.paths['/international-scheduled-payment-consents/{ConsentId}/funds-confirmation']
  remove: true
- target: $.paths['/international-scheduled-payments']
  remove: true
- target: $.paths['/international-scheduled-payments/{InternationalScheduledPaymentId}']
  remove: true
- target: $.paths['/international-scheduled-payments/{InternationalScheduledPaymentId}/payment-details']
  remove: true
- target: $.paths['/international-standing-order-consents']
  remove: true
- target: $.paths['/international-standing-order-consents/{ConsentId}']
  remove: true
- target: $.paths['/international-standing-orders']
  remove: true
- target: $.paths['/international-standing-orders/{InternationalStandingOrderPaymentId}']
  remove: true
- target: $.paths['/international-standing-orders/{InternationalStandingOrderPaymentId}/payment-details']
  remove: true

حالا همه عملیات مربوط به این انواع پرداخت حذف شدن. توصیف OpenAPI حالا حاوی بسیاری اشیاء یتیمه، البته، چون هیچ پشتیبانی در مشخصات Overlay برای حذف‌شون از طریق درون‌نگری (introspection) وجود نداره و بنابراین بعیده پشتیبانی مستقیم در ابزارهای خاص Overlay وجود داشته باشه. با این حال، بانک M&D گزینه استفاده از Spectral یا Vacuum رو داره تا اونا رو تعقیب کنه و قوانین برای حذف در آینده اضافه کنه. گذاشتن اشیاء یتیم در جای خودشون هیچ تفاوت عملکردی برای توصیف OpenAPI نداره، اما حذف‌شون حجم رو کاهش می‌ده و بار شناختی رو برای توسعه‌دهندگان که سعی می‌کنن محتوای توصیف API رو درک کنن، کم می‌کنه.

تعریف مقادیر پیشنهادی به عنوان شمارش‌ها

سیاست‌های حاکمیت API در بانک M&D یعنی اینکه عملیات‌های فضای نام باید هم با مقادیر enum جایگزین بشن که فقط مقادیری که برای یه خاصیت معین اعمال می‌شن رو لیست کنن. مثلاً، در نسخه‌های منتشرشده با استانداردها، شیء Schema OBInternalAccountIdentification4Code یه شمارش فضای نام با همه مقادیر استاندارد لیست‌شده داره:

yaml
OBInternalAccountIdentification4Code:
  description: >-
    Name of the identification scheme, in a coded form as published in an
    external list.
    For a full list of values refer to `OBInternalAccountIdentification4Code` in *OB_Internal_CodeSet* [here](https://github.com/OpenBankingUK/External_Internal_CodeSets)
  type: string
  x-namespaced-enum:
    - UK.OBIE.BBAN
    - UK.OBIE.IBAN
    - UK.OBIE.PAN
    - UK.OBIE.Paym
    - UK.OBIE.SortCodeAccountNumber
    - UK.OBIE.Wallet

سیاست بانک M&D لیست کردن دقیق مقادیر پشتیبانی‌شده‌ست، چون باور دارن این تجربه توسعه‌دهنده بهتری رو نشون می‌ده و خطاها رو به دلیل درخواست‌های شروع پرداخت برای انواع حساب پشتیبانی‌نشده کاهش می‌ده. بنابراین، بانک M&D اشیاء Action زیر رو پیاده‌سازی می‌کنه تا مقادیر شمارش فضای نام رو حذف کنه و اونا رو با مقادیری که پشتیبانی می‌کنن از طریق یه enum جایگزین کنه:

yaml
- target: $.components.schemas.OBInternalAccountIdentification4Code['x-namespaced-enum']
  remove: true
- target: $.components.schemas.OBInternalAccountIdentification4Code
  update:
    enum:
    - UK.OBIE.IBAN
    - UK.OBIE.SortCodeAccountNumber

توجه کنید به معناشناسی Overlay اینجا، یعنی اینکه به‌روزرسانی یه ادغام با شیء هدف موجوده. یه قانون هم برای حذف خاص شمارش namespaced پیاده‌سازی شده. با این حال، از دیدگاه توصیف API این می‌تونه نادیده گرفته بشه چون مشخصاته و فقط به مخاطبانی اعمال می‌شه که می‌تونن اون رو درک کنن.

اضافه کردن داده‌های تکمیلی

تغییر نهایی که بانک M&D می‌خواد انجام بده، اضافه کردن یه خاصیت که در کانال‌های آنلاین‌شون پشتیبانی می‌کنن به نام مرجع بدهکار ساختاریافته، که اجازه می‌ده یه روایت اضافی به پرداخت‌های مشتری اضافه بشه که در لیست تراکنش‌شون نمایش داده می‌شه. بانک M&D می‌خواد این رو اضافه کنه تا مطمئن بشه با درک‌شون از الزامات PSD2 در UK همخوانی داره (و وکیل‌شون بهشون گفت…). اضافه کردن خاصیت مورد نیاز یعنی اضافه کردن یه شیء فعالیت دیگه. این بار، با این حال، بانک M&D داره یه شیء رفرنس رو با یه شیء Schema inline جایگزین می‌کنه، یعنی باید اول شیء رفرنس رو حذف کنه. گذاشتن شیء رفرنس در جای خودش یعنی اشیاء جدید و ارجاع کنار هم زندگی کنن، که در OpenAPI نامعتبره. بانک M&D همچنین باید از به‌روزرسانی شیء Schema منبع OBSupplementaryData1 اجتناب کنه چون توسط بسیاری عملیات به اشتراک گذاشته شده، و مرجع بدهکار ساختاریافته فقط به پرداخت‌های داخلی فوری اعمال می‌شه. خاصیت باید هم در payload رضایت و هم در دستور پرداخت ظاهر بشه به دلیل قوانین اطراف lodging intent در استانداردها و چگونگی ظاهر جزئیات پرداخت. بنابراین، بانک M&D اشیاء Action زیر رو به Overlayشون اضافه می‌کنه:

yaml
- target: $.components.schemas.OBWriteDomesticConsent4.properties.Data.properties.Initiation.properties.SupplementaryData['$ref']
  remove: true
- target: $.components.schemas.OBWriteDomesticConsent4.properties.Data.properties.Initiation.properties.SupplementaryData
  update:
    type: object
    properties:
      StructuredDebtorReference:
        description: Proprietary property that allows a structured debtor reference to be provided
        type: string
        minLength: 1
        maxLength: 70
- target: $.components.schemas.OBWriteDomestic2.properties.Data.properties.Initiation.properties.SupplementaryData['$ref']
  remove: true
- target: $.components.schemas.OBWriteDomestic2.properties.Data.properties.Initiation.properties.SupplementaryData
  update:
    type: object
    properties:
      StructuredDebtorReference:
        description: Proprietary property that allows a structured debtor reference to be provided
        type: string
        minLength: 1
        maxLength: 70

سیاست نهایی به‌روزرسانی داده‌های تکمیلی برای شامل کردن ارجاع اضافی، Overlay بانک M&D رو کامل می‌کنه. چیز عالی اینه که این سیاست حالا کدگذاری شده تا توسط ابزارها اجرا بشه و در هر انتشار استاندارد جدید به طور مکرر و قطعی اجرا بشه. خانم کپی و آقای پیست حالا می‌تونن راحت استراحت کنن.

استفاده از Overlay با استانداردهای صنعت

کاربرد Overlay در این سناریو خیلی منطقیه، و کاربردش محدود به اکوسیستم open banking UK نیست. استانداردهای عمده دیگه، مثل گروه برلین، رویکرد چارچوبی می‌گیرند و یه سوپرست از عملیات open banking و open finance ارائه می‌دن که می‌تونه به الزامات بازار یا مؤسسه مالی کاهش یافته بشوند. استانداردهای صنعت دیگه که چارچوب توصیف‌شده با OpenAPI ارائه می‌دن — مثلاً HIPAA در مراقبت‌های بهداشتی — هم این رویکرد رو می‌گیرن، معمولاً با پیاده‌سازی افزونگی زیاد در توصیف API.

Overlay راه سیستماتیک و قطعی برای کاهش نویز هنگام پیاده‌سازی APIهای مبتنی بر استانداردها ارائه می‌ده. Overlay افزایش واقعی برای اتوماسیون ارائه می‌ده، هم با و هم بدون استانداردهای صنعت. ترسیم مسیر برای آینده Overlay هم جالبه، چون فعالیت‌هایی که می‌تونن پشتیبانی بشن می‌تونن توسط عملیات خودکار بر اساس درون‌گرائی یه توصیف OpenAPI معین تکمیل بشن. ما قبلاً به یکی از چنین ایده‌هایی در مثال حذف خودکار عملیات یتیم، ارجاع‌نشده وقتی عملیات API والد حذف می‌شه، اشاره کردیم. اگر علاقه‌مند به درگیر شدن و کمک به هدایت کشتی Overlay هستید، به مخزن مشخصات Overlay برید، مسائل موجود رو چک کنید، یا به بحث‌ها بپیوندید تا به شکل‌دهی نسخه بعدی Overlay کمک کنید.

قبلیچگونه با ابزارهای OpenAI هوش مصنوعی عاملی بسازیم؟
بعدی۵ تولیدکننده تصادفی کلید API کدامند و دلایل استفاده از آن‌ها در چیست؟

دیدگاهتان را بنویسید

سبد خرید
علاقه‌مندی‌ها
مشاهدات اخیر
دسته بندی ها