محدودیت‌های دنیای واقعی اغلب بر نحوه ساخت خدمات دیجیتال تأثیر می‌گذارند. این موضوع به ویژه در مورد APIهای سازمانی در صنایع تحت نظارت که داده‌های حساس را در حوزه‌های قضایی مختلف منتقل می‌کنند، صادق است. محدودیت‌های مربوط به مدیریت داده می‌تواند به راحتی پیشرفت را کند. اما لزوماً نباید این‌طور باشد. در اجلاس پلتفرم ۲۰۲۵، یینکا اوموله، مهندس ارشد نرم‌افزار در شرکت پرسانیو، درباره بهره‌برداری از این نوع محدودیت‌های شرکتی و نظارتی به عنوان یک مزیت معماری سخنرانی خواهد کرد. برای او، این کار نیازمند پیش‌اندیشی بیشتر در مراحل اولیه فرآیند طراحی API نسبت به حالت معمول، اجتناب از سیاست‌های جهانی برای همه انواع داده، و ذخیره قوانین به صورت پیکربندی است.
مصاحبه با یینکا اوموله
آیا می‌توانید کمی درباره پیشینه خود و کارتان با APIها بگویید؟
من مهندس ارشد در پرسانیو هستم، جایی که روی سیستم‌های حقوق و دستمزد کار می‌کنم که بیش از ۱۵ هزار شرکت در سراسر جهان را خدمت‌رسانی می‌کند. پیش از این، معاون در گلدمن ساکس بودم و پلتفرم‌های ورود دیجیتال و APIهای بانکداری تراکنشی می‌ساختم.
نکته جالب در کارم با APIها، دیدگاه بین‌حوزه‌ای است که دارم. دیده‌ام چگونه خدمات مالی و فناوری منابع انسانی مشکلات مشابه محدودیت (رعایت مقررات، خدمت‌رسانی به مشتریان سازمانی، الزامات ممیزی) را با رویکردهای متفاوت حل می‌کنند. این دیدگاه متنوع در صنایع بسیار تحت نظارت، نحوه تفکر من درباره طراحی API را شکل داده است.
چالش‌های اصلی سازمان‌های بزرگ وابسته به API در زمینه رعایت مقررات امروز چیست؟
بزرگ‌ترین چالش، نه یک مقررات واحد، بلکه ترکیب الزامات مختلف و گاهی متعارض است. برای مثال، الزامات حریم خصوصی ممکن است حداقل‌سازی و حذف داده را طلب کند، اما مقررات مالی در حوزه‌های قضایی دیگر، نگهداری ممیزی چندساله را برای همان سرویس و همان محصول الزامی می‌کند.
بسیاری از سازمان‌ها این محدودیت‌ها و تعارض‌ها را به صورت واکنشی مدیریت می‌کنند. ابتدا API را می‌سازند، سپس سعی می‌کنند رعایت مقررات را به عنوان پس‌فکری اضافه کنند. این کار پرهزینه است و اغلب به معنای بازسازی معماری اصلی است. سازمان‌هایی که خوب عمل می‌کنند، محدودیت‌ها را از روز اول به عنوان ورودی‌های طراحی درجه یک در نظر می‌گیرند.
چگونه APIهایی طراحی می‌کنید که در برابر این محدودیت‌ها انعطاف‌پذیر بمانند در حالی که همچنان عملکرد بالا و مقیاس‌پذیری داشته باشند؟
ابتدا محدودیت‌ها و الزامات را شناسایی می‌کنم، سپس نقشه می‌کشم کدام‌یک واقعاً با یکدیگر تعارض دارند. نه فقط فهرست کردن همه الزامات، بلکه نقشه‌برداری جایی که در جهت مخالف می‌کشند.
سپس به دنبال تصمیمات معماری می‌گردم که اجازه دهد هر دو را برآورده کنم. گاهی این جداسازی زمانی است (مانند انجام بررسی‌های رعایت به صورت ناهمزمان، و تطبیق بعدی برای اطمینان از پوشش ۱۰۰٪). گاهی جداسازی منطقی، و گاهی انتقال محدودیت به لایه‌ای کاملاً متفاوت.
کلید این است که سعی نکنید همه چیز را به طور برابر برآورده کنید. آنچه غیرقابل مذاکره است را انتخاب کنید، سپس ابتدا اطراف آن محدودیت‌های سخت طراحی کنید. عملکرد و انعطاف‌پذیری از شفاف بودن درباره آنچه سازش نمی‌کنید و معیارهای اصلی که باید به آنها توجه کنید، ناشی می‌شود.
در تجربه شما، عوامل کلیدی موفقیت برای APIهایی که پذیرش و استفاده گسترده‌ای کسب می‌کنند چیست؟
آسان کردن شروع کار بدون نیاز به درک تمام پیچیدگی‌ها. توسعه‌دهندگان باید بلافاصله مشغول به کار بشوند، نه پس از ساعت‌ها مطالعه مستندات.
مستندات خوب که «چرا» پشت تصمیمات طراحی را توضیح می‌دهد نیز کمک می‌کند. وقتی توسعه‌دهندگان محدودیت‌هایی که هدایت می‌کنید را درک کنند، انتخاب‌های ادغام بهتر و انتظارات واقع‌بینانه‌تری دارند.
در نهایت، پایداری. APIها در محیط‌های تحت نظارت نمی‌توانند مکرراً خراب شوند. هنگامی که افراد با سیستم‌های پرداخت یا حقوق و دستمزد ادغام می‌کنند، تمایلی به تغییر ندارند. بنابراین نیاز به استراتژی‌های سازگاری دارید که سال‌ها دوام بیاورند، نه ماه‌ها.
تکنیک‌های زمان طراحی برای مدیریت سردردهای خدمت‌رسانی داده در چندین محدودیت چیست؟ چگونه معماری هوشمند API به حل این چالش‌ها کمک می‌کند؟
یکی از تکنیک‌های مفید، جداسازی داده بر اساس حساسیت در مراحل اولیه است. همه داده‌ها نیاز به حفاظت یکسان ندارند. نام کارکنان نیاز به رمزنگاری و مدیریت دقیق دارد. نام دپارتمان‌ها می‌تواند به شدت کش شود. وقتی با همه چیز بطور یکسان برخورد می‌کنید، یا بیش از حد حفاظت می‌کنید و عملکرد را نابود می‌کنید، یا کمتر حفاظت می‌کنید و ریسک به وجود می‌آید.
تکنیک واقعاً مفید دیگر، ذخیره قوانین به عنوان پیکربندی/داده است، نه کد. وقتی منطق کسب‌وکار بر اساس حوزه قضایی متفاوت است، داده‌محور کردن آن به معنای اضافه کردن کشور جدید به عنوان تمرین پیکربندی به جای تغییرات پرریسک کد در چندین سرویس است.
آیا توصیه‌ای برای انتخاب سبک یا فرمت طراحی API مناسب برای کار — چه REST، GraphQL، معماری رویدادمحور، gRPC یا دیگران — دارید؟
واقعاً به سخت‌ترین محدودیت و آنچه نمی‌توانید با آن سازش کنید بستگی دارد.
برای مثال، اگر نیاز به کش HTTP قوی دارید و داده‌هایتان به خوبی به منابع نگاشت می‌شود، REST منطقی است. بسیاری از شرکت‌ها از این استفاده می‌کنند زیرا اکوسیستم ابزارها بالغ و شناخته‌شده است.
اگر نیاز به مسیرهای ممیزی دارید و می‌توانید تداوم را بپذیرید، رویدادمحور خوب کار می‌کند. بسیاری از عملیات سنگین رعایت واقعاً نیاز به پاسخ‌های همگام ندارند، و رویدادها مسیر ممیزی مورد نیاز را رایگان ارائه می‌دهند.
برای سرویس‌های داخلی که هر دو انتها را کنترل می‌کنید و تایپینگ قوی می‌خواهید، gRPC می‌تواند عالی کار کند. گفتگو متفاوت خواهد بود، و gRPC ممکن است برای APIهای خارجی که کلاینت را کنترل نمی‌کنید، خوب کار نکند.
فناوری را انتخاب کنید که سخت‌ترین محدودیت شما را آسان کند!
آیا تاکنون به استکهلم رفته‌اید؟ اگر بله، چه چیزی را بیشتر دوست دارید؟ اگر نه، به چه چیزی بیشتر مشتاق هستید؟
هنوز نرفته‌ام، اما واقعاً مشتاقم! شنیده‌ام شهر قدیمی، موسیقی، غذا، و رویکرد شهر به طراحی شهری عالی است. همچنین کنجکاو صحنه فناوری آنجا هستم!
در اجلاس پلتفرم امسال به چه چیزی بیشتر هیجان‌زده هستید؟ فراتر از ارائه خودتان، آیا تم‌ها، موضوعات یا سخنرانان خاصی هستند که مشتاق یادگیری از آنها هستید؟
کنجکاو هستم که چگونه متخصصان عامل‌های هوش مصنوعی را در APIهای تولیدی مدیریت می‌کنند. هیجان زیادی اطراف ابزارهای هوش مصنوعی وجود دارد، و کنجکاو هستم ببینم مردم چگونه واقعاً آن را در اپلیکیشن‌ها و APIهای سازمانی پیاده‌سازی می‌کنند.
همچنین مشتاق یادگیری از جامعه و ملاقات با افراد دیگر هستم. دریافته‌ام که معمولاً چالش‌های فنی که با آن روبرو هستیم به اندازه‌ای که فکر می‌کنیم منحصربه‌فرد نیستند، و همیشه مفید است ببینیم دیگران چگونه مشکلات مشابه را حل می‌کنند.
