وقتی درباره طراحی یک سامانه دولتی صحبت میشود، معمولاً اولین چیزی که دیده میشود صفحات ورود، فرمها، داشبوردها و منوهای کاربری است. این بخشها مهماند، اما فقط یک طرف ماجرا را تشکیل میدهند. در دولت دیجیتال، سامانهها باید بتوانند همانقدر که با کاربران انسانی ارتباط برقرار میکنند، با سامانههای دیگر نیز داده و خدمت مبادله کنند.
اگر این نیاز از ابتدای طراحی در نظر گرفته نشود، سازمان بعداً با سیستمی روبرو میشود که برای انجام وظایف داخلی مناسب است، اما اتصال آن به سایر زیرساختها دشوار، پرهزینه یا حتی ناممکن خواهد بود.
اینجاست که مفهوم API-first اهمیت پیدا میکند؛ رویکردی که در آن API یک قابلیت جانبی برای آینده نیست، بلکه از ابتدا بخشی از معماری محصول محسوب میشود.
رابط کاربری برای انسان است؛ API برای سامانهها
کاربر انسانی برای کار با یک نرمافزار به صفحه، دکمه، فرم و گزارش نیاز دارد. اما اگر یک سامانه دیگر بخواهد اطلاعات مشخصی را دریافت یا عملیاتی را آغاز کند، رابط گرافیکی کمکی به آن نمیکند.
فرض کنیم یک سامانه منابع انسانی اطلاعات کارکنان را نگهداری میکند و سامانه مالی نیز برای محاسبه حقوق به بخشی از همین دادهها نیاز دارد. یک راه این است که کاربر اطلاعات را از سامانه اول استخراج کند و دوباره در سامانه دوم وارد کند.
راه دیگر این است که دو سامانه از طریق API با یکدیگر ارتباط داشته باشند.
در حالت دوم، سامانه مالی میتواند بر اساس مجوز و قواعد مشخص، داده مورد نیاز خود را مستقیماً از منبع اصلی دریافت کند. دخالتِ دستی کمتر میشود، احتمال مغایرت اطلاعات کاهش پیدا میکند و مشخص است هر داده از کجا آمده است.
API در واقع رابطی برای گفتگو میان نرمافزارهاست؛ همان نقشی که رابط کاربری برای ارتباط انسان با نرمافزار دارد.
در دولت دیجیتال، رابط کاربری فقط بخشی از محصول است؛ یک سامانه باید برای سامانههای دیگر نیز مسیر استاندارد، امن و مشخصی برای تبادل داده و خدمت داشته باشد.
API-first دقیقاً به چه معناست؟
API-first به این معنا نیست که تیم توسعه قبل از هر کار دیگری چند API بسازد و بعد درباره محصول تصمیم بگیرد.
مفهوم اصلی این است که از همان مرحله طراحی، تعامل سامانه با سیستمهای دیگر یکی از نیازهای پایه محصول در نظر گرفته شود.
در چنین رویکردی، پیش از آن که قابلیتها صرفاً بر اساس صفحات کاربری طراحی شوند، چند سؤال مهم مطرح میشود:
وقتی این پرسشها در ابتدای کار مطرح شوند، API بخشی از معماری سامانه میشود؛ نه راهحلی اضطراری که چند سال بعد برای اتصال دو سیستم ساخته شود.
تفاوت API-first با «بعداً یک وبسرویس اضافه میکنیم»
در بسیاری از پروژهها نیاز به اتصال در ابتدای توسعه جدی گرفته نمیشود. سامانه راهاندازی میشود، دادهها در ساختار داخلی آن شکل میگیرند و فرایندها بر اساس رابط کاربری طراحی میشوند.
چند سال بعد، دستگاه دیگری درخواست اتصال میکند.
در این مرحله تیم فنی تازه باید مشخص کند چه دادههایی را میتوان بیرون داد، شناسهها چگونه با سامانه دیگر تطبیق پیدا میکنند، سطح دسترسی چیست و از کدام قسمت معماری داخلی میتوان اطلاعات را استخراج کرد.
نتیجه گاهی یک رابط موقت و اختصاصی است که فقط برای همان اتصال ساخته شده است.
با اضافه شدن دستگاه دوم، رابط دوم ساخته میشود. دستگاه سوم نیز قالب دیگری میخواهد.
به مرور، سامانهای که در ابتدا یک محصول منظم بوده، با مجموعهای از اتصالهای اختصاصی و وابستگیهای فنی روبرو میشود که توسعه و نگهداری آنها روزبهروز دشوارتر خواهد شد.
در معماری API-first مسیر متفاوت است. ساختار داده و خدمات از ابتدا طوری طراحی میشوند که مصرفکننده آنها فقط صفحه وب خود سامانه نباشد.
API بخشی از محصول است، نه خروجی جانبی تیم فنی
یکی از تفاوتهای مهم API-first همین نگاه محصولی است.
اگر API صرفاً یک خروجی فنی تلقی شود، طراحی آن معمولاً بعد از تکمیل قابلیت اصلی انجام خواهد شد. اما وقتی API بخشی از محصول باشد، همان حساسیتی که برای رابط کاربری وجود دارد باید برای آن نیز وجود داشته باشد.
نام و ساختار دادهها باید مشخص باشد. رفتار درخواستها باید قابل پیشبینی باشد. خطاها باید کد و مفهوم روشن داشته باشند. مستندات باید نگهداری شوند و تغییر نسخه نباید بدون برنامه ارتباط سامانههای دیگر را مختل کند.
یک API خوب باید حداقل درباره این موارد تکلیف روشنی داشته باشد:
این موارد شاید در صفحهای که کاربر میبیند قابلمشاهده نباشند، اما کیفیت واقعی تعامل میان سامانهها تا حد زیادی به همین جزئیات وابسته است.
چرا این موضوع برای دولت دیجیتال مهمتر است؟
یک شرکت خصوصی میتواند بسیاری از فرایندهای خود را در یک مجموعه نرمافزاری متمرکز کند، اما ساختار دولت متفاوت است.
اطلاعات موردنیاز برای ارائه یک خدمت عمومی معمولاً در اختیار یک دستگاه واحد نیست. هویت در یک سامانه نگهداری میشود، اطلاعات مکانی در سامانه دیگر، مجوز در دستگاهی دیگر صادر میشود و اطلاعات مالی نیز منبع جداگانهای دارد.
اگر هر سازمان بخواهد نسخه مستقلی از همه این اطلاعات را ایجاد کند، دولت خیلی سریع با انبوهی از پایگاههای داده مشابه و ناسازگار روبرو خواهد شد.
راهکار پایدار این نیست که همه دادههای کشور در یک نرمافزار قرار گیرند. راهکار این است که منابع معتبر داده مشخص باشند و سامانهها بتوانند بر اساس قواعد و مجوزهای تعیینشده با یکدیگر ارتباط برقرار کنند.
در چنین مدلی، API یکی از زیرساختهای اصلی دولت دیجیتال است.
یک API خوب هر دادهای را در اختیار همه نمیگذارد
اتصالپذیری نباید با دسترسی آزاد اشتباه گرفته شود. یکی از مهمترین بخشهای طراحی API در سامانههای دولتی، مشخص کردن مرز دسترسی است.
فرض کنیم سامانهای اطلاعات یک پرونده را نگهداری میکند. یک دستگاه دیگر شاید فقط به وضعیت پرونده نیاز داشته باشد، نه تمام اسناد و مشخصات موجود در آن.
در یک معماری درست، API باید همان مقدار دادهای را ارائه کند که برای انجام مأموریت مشخص لازم است.
برای هر ارتباط باید مشخص باشد:
به همین دلیل API-first در سامانه دولتی فقط یک تصمیم نرمافزاری نیست؛ بخشی از طراحی امنیت، مالکیت داده و حاکمیت اطلاعات نیز محسوب میشود.
API و اصل «منبع مرجع داده»
اگر چند سازمان، یک مشخصهی واحد را نگهداری کنند، احتمال اختلاف میان نسخههای مختلف اطلاعات بالاتر میرود. برای مثال، اگر مشخصات پایه یک واحد سازمانی در پنج سامانه مستقل ثبت شده باشد، تغییر یک مشخصه لزوماً در چهار سامانه دیگر منعکس نمیشود.
API میتواند این الگو را تغییر دهد.
به جای کپی دائمی اطلاعات، یک سامانه میتواند مالک و منبع مرجع داده باشد و سامانههای دیگر اطلاعات لازم را از آن دریافت کنند.
در این مدل، مسئولیت نیز روشنتر است. سامانه دریافتکننده لازم نیست مسئول صحت تمام داده منبع باشد؛ بلکه باید بداند اطلاعات را از کدام مرجع معتبر دریافت کرده است. این موضوع رابطه مستقیمی با معماری یکپارچه، اصل Once-Only و مدیریت چرخه عمر داده دارد.
API-first بهتنهایی جلوی سامانههای جزیرهای را نمیگیرد
وجود API لزوماً به معنای یکپارچگی نیست. یک سامانه میتواند دهها API داشته باشد اما همچنان از نظر داده، فرایند و معماری با سایر بخشهای سازمان هماهنگ نباشد.
API ابزار ارتباط است؛ طراحی ارتباط هنوز به تصمیمهای مدیریتی و معماری نیاز دارد.
اگر دو سامانه درباره شناسهها، مالکیت داده، قواعد فرایند و معنی اطلاعات توافق نداشته باشند، ایجاد یک کانال فنی میان آنها مسئله را حل نمیکند.
در واقع، اتصال فنی بدون توافق دادهای گاهی فقط اختلاف موجود را سریعتر منتقل میکند.
نسخهبندی؛ تغییری کوچک که میتواند چند سامانه را متوقف کند
سامانهها دائماً تغییر میکنند: فیلدی اضافه میشود، ساختار پاسخ تغییر میکند، روش احراز هویت ارتقا پیدا میکند یا یک خدمت قدیمی کنار گذاشته میشود.
در رابط کاربری، تیم توسعه کنترل زیادی روی هر دو سمت تغییر دارد. اما در API شرایط متفاوت است؛ احتمال دارد ده سامانه دیگر به همان رابط متصل باشند.
یک تغییر ناگهانی میتواند ارتباط همه آنها را مختل کند.
به همین دلیل نسخهبندی، اعلام تغییرات و حفظ سازگاری تا یک دوره مشخص از اجزای مهم مدیریت API هستند.
API-first فقط درباره «ساخت API» نیست؛ درباره مدیریت چرخه عمر آن هم هست.
API-first و معماری ماژولار
API-first فقط برای ارتباط میان دو سازمان کاربرد ندارد.
در یک سامانه بزرگ نیز بخشهای مختلف میتوانند مرزهای مشخصی داشته باشند و از طریق قراردادهای استاندارد با یکدیگر تعامل کنند.
این موضوع بهویژه زمانی اهمیت پیدا میکند که محصول طی چند سال توسعه پیدا کند، قابلیتهای تازه اضافه شوند یا بعضی بخشها به خدمات مستقل تبدیل شوند.
اگر مرز میان حوزههای مختلف از ابتدا روشن باشد، تغییر معماری در آینده آسانتر خواهد بود.
در مقابل، اگر همه بخشهای نرمافزار مستقیماً به جزئیات داخلی یکدیگر وابسته باشند، جدا کردن آنها در آینده هزینه زیادی خواهد داشت.
وقتی API وجود ندارد، بار ارتباط روی دوش انسان میافتد
نبود API به این معنا نیست که تبادل اطلاعات متوقف میشود. یک سازمان همچنان به داده نیاز دارد و راهی برای انتقال آن پیدا خواهد کرد. معمولاً یکی از این راهها شکل میگیرد:
یعنی کاری که میتوانست میان دو سامانه و با قواعد مشخص انجام شود، به فرایند انسانی تبدیل میشود. با افزایش تعداد سامانهها، این مدل بهسختی مقیاسپذیر خواهد بود.
ایران: مسئله فقط داشتن سامانه نیست، اتصالپذیری آنهاست
در ایران طی سالهای گذشته سامانههای متعددی در دستگاههای دولتی، عمومی و اجرایی ایجاد شدهاند. بسیاری از آنها مأموریت مشخصی دارند و بعضی نیز سالهاست بخش مهمی از عملیات سازمان خود را انجام میدهند.
چالش زمانی آغاز میشود که برای ارائه یک خدمت جدید، چند سامانه باید با یکدیگر تعامل کنند.
سامانهای که از ابتدا فقط برای کاربران داخلی خود طراحی شده، احتمال دارد API استاندارد نداشته باشد، ساختار داده آن برای تبادل بیرونی آماده نباشد یا شناسههایش با سایر دستگاهها هماهنگ نشده باشد.
در چنین شرایطی اتصال به آن گاهی به پروژهای مستقل تبدیل میشود: طراحی رابط واسط، تبدیل داده، ساخت سرویس اختصاصی یا حتی ادامه تبادل فایل.
اگر اتصالپذیری از مرحله طراحی وارد الزامات سامانههای دولتی شود، این چرخه در نسلهای بعدی نرمافزارها قابل کنترلتر خواهد بود.
API-first در اینجا یک موضوع فنی حاشیهای نیست؛ بخشی از آمادهسازی زیرساخت دولت برای تبادل داده میان دستگاههاست.
سامانهای که امروز بدون مسیر استاندارد تبادل داده طراحی میشود، احتمال دارد فردا برای اتصال به هر دستگاه جدید به یک پروژه جداگانه نیاز داشته باشد.
قانون مدیریت دادههاآیا همه APIها باید عمومی باشند؟
خیر. API میتواند عمومی، محدود به شرکای مشخص، درونسازمانی یا حتی فقط برای ارتباط میان اجزای یک سامانه باشد.
در سامانههای دولتی بخش بزرگی از APIها طبیعتاً عمومی نیستند. مسئله API-first «باز کردن سامانه» نیست؛ مسئله ایجاد یک مسیر کنترلشده برای ارتباط در مواردی است که چنین ارتباطی لازم میشود.
حتی API داخلی نیز باید قواعد امنیتی، احراز هویت، سطح دسترسی و ثبت سوابق خود را داشته باشد.
در نتیجه، اتصالپذیری و امنیت مقابل یکدیگر قرار نمیگیرند. معماری درست باید هر دو را همزمان در نظر بگیرد.
REST API و جایگاه آن در سماد
سامانه مدیریت امور دهیاریها «سماد» نیز به دلیل ماهیت یکپارچه خود با حوزههای مختلف داده و فرایند روبرو است. اطلاعات مالی، پرسنلی، مصوبات، مجوزها، گزارشها و سایر فرایندهای مدیریت روستایی در بسیاری از موارد به دادهها یا خدمات بیرون از یک سامانه واحد محدود نمیشوند.
در معماری فنی سماد، REST API نیز در نظر گرفته شده است تا امکان تعریف ارتباط ساختاریافته میان سماد و سامانههای دیگر وجود داشته باشد.
وجود REST API به این معنا نیست که هر سامانهای بدون ضابطه به اطلاعات سماد دسترسی دارد. هر اتصال واقعی باید بر اساس نیاز، مجوز، سطح دسترسی، ساختار داده و الزامات امنیتی همان پروژه تعریف شود.
اهمیت این ظرفیت در آن است که توسعه آینده سامانه، الزاماً به تبادل دستی اطلاعات وابسته نماند و در صورت فراهم بودن شرایط سازمانی و فنی، امکان ارتباط نرمافزاری با سرویسهای دیگر وجود داشته باشد.
سماد، تجربهای منحصر بفرد
سامانه یکپارچه و هوشمند مدیریت امور دهیاریها، برای تغییر رویکرد از مدیریت سنتی به یک سیستم شفاف و منسجم.
API-first چه چیزی را از تیم طراحی تغییر میدهد؟
وقتی یک پروژه API-first طراحی شود، پرسشهای تیم محصول نیز تغییر میکنند. دیگر فقط نمیپرسیم «کاربر این اطلاعات را در کدام صفحه وارد کند؟»
بلکه همزمان باید پرسید «اگر این اطلاعات از قبل در یک سامانه معتبر وجود دارد، آیا اصلاً باید دوباره از کاربر گرفته شود؟» یا «اگر سازمان دیگری به نتیجه این فرایند نیاز داشته باشد، چگونه آن را دریافت خواهد کرد؟»
این تغییر نگاه، API را از موضوعی صرفاً مربوط به برنامهنویسان خارج میکند و وارد طراحی محصول، فرایند و داده میکند.
از API تا اکوسیستم دیجیتال
وقتی سامانهها بتوانند بر اساس استانداردهای مشخص با یکدیگر ارتباط داشته باشند، طراحی خدمات نیز تغییر میکند.
دیگر لازم نیست هر سامانه تمام قابلیتهای مورد نیاز خود را دوباره تولید کند.
یک سیستم میتواند هویت را از مرجع مربوط دریافت کند، دیگری وضعیت مجوز را ارائه دهد، سامانه مالی نتیجه پرداخت را اعلام کند و یک داشبورد مدیریتی اطلاعات مورد نیاز خود را از چند منبع معتبر جمعآوری کند.
در چنین معماریای، هر سامانه وظیفه مشخص خود را انجام میدهد و در عین حال جزئی از یک اکوسیستم بزرگتر است.
این همان نقطهای است که دولت الکترونیک مبتنی بر «سامانههای متعدد» میتواند به دولت دیجیتال مبتنی بر «خدمات متصل» نزدیک شود.
جمعبندی
همانطور که تشریح شد، یک سامانه خوب فقط آن چیزی نیست که کاربر روی صفحه میبیند. در دولت دیجیتال، بخشی از ارزش سامانه در توانایی آن برای تعامل امن، استاندارد و کنترلشده با سایر سیستمهاست.
اگر API بعد از پایان طراحی و فقط هنگام ایجاد اولین اتصال جدی گرفته شود، احتمال دارد ساختار داخلی سامانه برای چنین ارتباطی آماده نباشد و هر اتصال جدید به توسعهای اختصاصی تبدیل شود.
رویکرد API-first این مسئله را زودتر وارد طراحی میکند. مالکیت داده، قراردادهای ارتباطی، سطح دسترسی، امنیت، نسخهبندی و چرخه عمر API از ابتدا جزئی از معماری محسوب میشوند.
هدف نهایی نیز ساخت API بیشتر نیست. هدف ساخت سامانههایی است که بتوانند بدون ایجاد دوبارهکاری، جزیرههای اطلاعاتی و اتصالهای موقت، در یک اکوسیستم دیجیتال بزرگتر نقش مشخصی داشته باشند.
شرکت دانشبنیان تدبیرنگر، توسعهدهنده راهکارهای هوشمند، سامانههای اتوماسیون و خدمات یکپارچه دیجیتال در مسیر تحول و توانمندسازی سازمانی کارآمد.
آدرس
ارومیه – خیابان برق از سمت بلوار شهید بهشتی، کوچه ۳، پلاک ۱۲
ایمیل
hello@tadbirnegar.ir
tadbirnegar.com@gmail.com
