‫طراحی APIهای کارآمد: رویکردی فراتر از عملیات CRUD

طراحی رابط‌های برنامه‌نویسی کاربردی (API) نقش حیاتی در ایجاد سیستم‌های پایدار، مقیاس‌پذیر و قابل تغییر دارد. بسیاری از توسعه‌دهندگان، به‌ویژه در مراحل اولیه یادگیری و توسعه، به رویکردی به نام عملیات ایجاد، خواندن، به‌روزرسانی و حذف (CRUD) برای طراحی API‌های خود تکیه می‌کنند. اگرچه این رویکرد در بسیاری از موارد ساده و قابل فهم به نظر می‌رسد، اما در سیستم‌های پیچیده‌تر و با طول عمر بالا، می‌تواند منجر به مشکلاتی در زمینه تغییر، توسعه و یکپارچگی شود. این مقاله به بررسی محدودیت‌های رویکرد CRUD محور و ارائه یک دیدگاه جایگزین مبتنی بر قابلیت‌های تجاری (Business Capabilities) می‌پردازد.

تمرکز صرف بر عملیات CRUD اغلب منجر به طراحی APIهایی می‌شود که مستقیماً ساختار داده‌های زیربنایی را منعکس می‌کنند. در این حالت، درخواست‌های HTTP مانند GET، POST، PUT یا PATCH و DELETE به ترتیب با عملیات SELECT، INSERT، UPDATE و DELETE در پایگاه داده مرتبط می‌شوند. این نوع طراحی، که اغلب به اشتباه RESTful تلقی می‌شود، در واقع صرفاً انجام عملیات CRUD بر روی داده‌ها از طریق پروتکل HTTP و قالب JSON است.

یکی از مهم‌ترین مشکلات این رویکرد، تمرکز بر داده‌ها و ساختارهای داده‌ای است، نه فرآیندهای تجاری. سیستم‌هایی که بر اساس CRUD ساخته می‌شوند، اغلب منطق و گردش کار (Workflow) کسب‌وکار را به طور صریح در خود جای نمی‌دهند و این منطق عمدتاً در ذهن کاربران نهایی باقی می‌ماند. در نتیجه، APIها ساختار داده‌ای را در معرض دید قرار می‌دهند که ممکن است با نحوه واقعی انجام کارها در کسب‌وکار همخوانی نداشته باشد.

با گذشت زمان، فرآیندهای تجاری تغییر می‌کنند و نحوه تعامل کاربران با سیستم تکامل می‌یابد. ساختار داده‌ای که در ابتدا طراحی شده است، ممکن است دیگر پاسخگوی نیازهای جدید نباشد. در چنین شرایطی، توسعه‌دهندگان اغلب مجبور می‌شوند تا قابلیت‌های جدید را به زور در ساختار موجود جای دهند، که این امر منجر به پیچیدگی، شکنندگی و دشواری در تغییر سیستم می‌شود. به عبارت دیگر، با این کار، دو فرآیند تجاری مجزا به یک ساختار داده‌ای واحد گره می‌خورند و هرگونه تغییر در ساختار داده، هر دو فرآیند را تحت تأثیر قرار می‌دهد.

علاوه بر این، رویکرد CRUD محور اغلب منجر به افشای ساختار داده‌های داخلی به عنوان API می‌شود. این امر اتصال تنگاتنگی (Tight Coupling) بین مصرف‌کنندگان API و پیاده‌سازی داخلی سیستم ایجاد می‌کند. برای مثال، اگر سیستم‌های صورتحساب و حمل‌ونقل هر دو مستقیماً به طرحواره (Schema) داده‌های حمل‌ونقل دسترسی داشته باشند، هرگونه تغییر در ساختار داده‌های داخلی سیستم حمل‌ونقل می‌تواند سیستم صورتحساب را دچار مشکل کند.

به جای تمرکز بر داده‌ها، رویکرد جایگزین بر قابلیت‌های تجاری (Business Capabilities) سیستم تمرکز دارد. یک قابلیت تجاری، ظرفیت یک سازمان برای انجام موفقیت‌آمیز یک فعالیت تجاری منحصربه‌فرد را تعریف می‌کند. در این رویکرد، سؤال اصلی این است که سیستم واقعاً چه کاری انجام می‌دهد؟

با استفاده از مثال حمل‌ونقل، یک سیستم CRUD محور ممکن است عملیات ایجاد یک محموله (POST)، به‌روزرسانی آن (PUT یا PATCH) و حذف آن (DELETE) را ارائه دهد. اما مفهوم "به‌روزرسانی" در این حالت بسیار مبهم است. چه چیزی در حال به‌روزرسانی است؟ در مقابل، یک رویکرد مبتنی بر قابلیت‌های تجاری، فرآیند حمل‌ونقل را به عنوان یک چرخه حیات (Life Cycle) با مراحل مشخص در نظر می‌گیرد:

هر یک از این مراحل، یک رویداد (Event) با داده‌های مرتبط خود است. به جای یک عملیات "به‌روزرسانی حمل‌ونقل" مبهم، ما مجموعه‌ای از عملیات مشخص داریم که مراحل مختلف گردش کار را نشان می‌دهند.

ثبت صریح گردش کار و رفتارهای سیستم، امکان تکامل آسان‌تر آن را فراهم می‌کند. برای مثال، اگر نیاز به افزودن یک مرحله جدید مانند توقف در مرز باشد، می‌توان این مرحله را به راحتی در گردش کار موجود اضافه کرد بدون اینکه عملکرد قبلی سیستم دچار اختلال شود. همچنین، اگر نوع جدیدی از حمل‌ونقل با گردش کار متفاوت مورد نیاز باشد، می‌توان آن را به طور مستقل مدل‌سازی کرد، نه اینکه سعی شود آن را در مدل CRUD محور موجود جای داد.

علاوه بر این، ثبت صریح رویدادها امکان ایجاد یکپارچگی با سایر سیستم‌ها را به شیوه‌ای انعطاف‌پذیر فراهم می‌کند. برای مثال، هنگام بارگیری محموله، می‌توان رویداد "بارگیری انجام شد" را منتشر کرد و سیستم‌های دیگر (مانند سیستم‌های اطلاع‌رسانی مشتری یا سیستم‌های شخص ثالث) می‌توانند بر اساس این رویداد، اقدامات لازم را انجام دهند (مانند ارسال ایمیل اطلاع‌رسانی یا فراخوانی APIهای خارجی). این سیستم‌ها به یکدیگر متصل نیستند و در صورت تغییر یا حذف یکی از آن‌ها، سایر سیستم‌ها تحت تأثیر قرار نمی‌گیرند.

هدف نهایی، ثبت فرآیند تجاری، قابلیت‌ها و رفتارها و سپس مدل‌سازی داده‌ها بر اساس این رفتارها است. این رویکرد کاملاً متفاوت از صرفاً ارائه ساختارهای داده‌ای داخلی از طریق APIهای CRUD است.

رویکرد مبتنی بر قابلیت‌های تجاری، امکان ایجاد یک مرز API (API Fortress) را فراهم می‌کند. این مرز، یک لایه انتزاعی است که پیچیدگی‌های داخلی سیستم را پنهان کرده و از آن در برابر وابستگی‌های خارجی محافظت می‌کند. API به عنوان یک قرارداد عمل می‌کند و آنچه را که سیستم به دنیای خارج ارائه می‌دهد، تعریف می‌کند. در این حالت، مدل داده‌ای که برای ذخیره‌سازی اطلاعات استفاده می‌شود و مدل دامنه (Domain Model) که گردش کارها را نشان می‌دهد، می‌توانند متفاوت باشند و نباید یکسان در نظر گرفته شوند.

شایان ذکر است که سیستم‌های CRUD ذاتاً بد نیستند. استفاده از آن‌ها بستگی به زمینه و هدف دارد. برای بسیاری از سیستم‌هایی که دارای داده‌های ساده و ایستا هستند و فرآیندهای تجاری پیچیده‌ای بر روی آن‌ها وجود ندارد، APIهای CRUD کاملاً مناسب هستند. مثال‌هایی از این موارد عبارتند از:

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