تحول معماری API از REST تا گرافکیوال
کمتر تقابلی در تاریخ مهندسی نرمافزار به اندازه REST و GraphQL پابرجا مانده است. از منظر سطحی، به نظر میرسد این موضوع صرفاً یک مقایسه فنی است؛ چندین نقطه اتصال در برابر یک نقطه واحد، یا پاسخهای ثابت در برابر پرسوجوهای پویا. اما با کاوش عمیقتر، با دو نادرک متفاوت از حل مسائل آشنا میشویم که قرنها پیش در بسترهای مختلف شکل گرفتند و اکنون در یک سکوی نبرد قرار گرفتهاند. انتخاب آگاهانه میان این دو، تنها زمانی ممکن است که ریشههای تاریخی و اهداف اصلی هر کدام را درک کنیم.
ریشههای تاریخی REST: زمانی که قرار بود فقط وب باشد
روی فیلدینگ پدیدهای دور از واقعیتهای کف پروژه نبود. این مهندس شبکه، نویسنده اصلی استانداردهای HTTP 1.0 و 1.1، از بنیانگذاران پروژه آپاچی و یکی از معماران اصلی شریانهای حیاتی اینترنت محسوب میشود. وقتی فیلدینگ در سال 2000 رساله دکتری خود را منتشر کرد، REST نامی بود برای توصیف معماری خود شبکه جهانی وب. در آن طرح، کل اینترنت قرار بود مطابق با این فلسفه عمل کند، نه اینکه صرفاً به ابزاری برای ساخت APIهای تجاری تبدیل شود. اشاره مستقیم به APIهای وب در آن اسناد اولیه بسیار اندک بود.
پس چگونه REST به زبان مشترک توسعهدهندگان تبدیل شد؟ پاسخ به اواسط دهه 2000 بازمیگردد، زمانی که جامعه برنامهنویسی در دردی به نام SOAP غرق شده بود. این پروتکل پرهزینه، پر از کدهای XML سنگین و نیازمند مستندات گستردهای بود که حتی برای یک پاسخ ساده هم فرآیندی پیچیده خلق میکرد. توسعهدهندگان تشنه راهحلی ساده، سبک و مبتنی بر اصول شناختهشده HTTP بودند و REST دقیقاً همان جایی بود که میدرخشید. حذف ناگهانی پشتیبانی از SOAP در فریمورک Rubi on Rails و انتقادات صریح دیوید هاینمایر هانسون، سرعت انتقال انبوه به سمت این سبک معمار را دوچندان کرد.
جالب است بدانید که اکثر پیادهسازیهای امروزی که با نام REST API شناخته میشوند، با تعریف خالص فیلدینگ فاصله دارند. او در سال 2008 صراحتاً اعلام کرد که یک معماری REST واقعی نباید نیاز به مستندات پیوست داشته باشد و کلاینت دقیقاً بداند چه درخواستهایی میتواند ارسال کند. با این حال، آنچه REST را در تاریخ تکنولوژی جاودانه کرد، چهار مزیت کلیدی بود که اکوسیستم وب را متحول ساخت:
- نگاشت طبیعی افعال HTTP به عملیات CRUD
- طراحی بیحالت که بار پردازش سرور را به شدت کاهش داد
- قابلیت کشگذاری یکپارچه در لایه شبکه
- ایجاد استانداردهای مشترک برای تیمهای سراسر جهان
برای مطالعه دقیقتر محدودیتهای رسمی این معماری میتوان به مستندات استاندارد در ویکیپدیا و اینترفیس یونیفورم رجوع کرد.
معماری منابع در برابر معماری گرافی: تغییر زاویه دید
REST دنیا را تودهای از منابع قابل آدرسدهی میبیند. هر موجودیت یک محل مشخص است و کلاینت با فراخوانی آن آدرس، دادهها را دریافت میکند، سپس خودش آنها را پردازش و ترکیب مینماید. این شیوه فکری شبیه به سیستمهای بایگانی کتابخانه عمل میکند؛ هر منبع شناسه منحصربهفرد دارد، روش دریافت آن استاندارد است و تصمیمگیرنده نهایی برای محتوای برگشتی، سرور مرکزی است. این فلسفه بر شش محدودیت اساسی استوار است که همگی من جمله آنها به استقلال تکامل کلاینت و سرور، بیحالت بودن کامل درخواستها و کاهش خطاهای یکپارچهسازی طراحی شدهاند.
در مقابل، GraphQL با ظهوری جنجالی در فیسبوک، زاویه دید را از دادهمحوری به عملمحوری تغییر داد. در این سبک، کلاینت به جای درخواست مستقیم از منابع، دقیقاً مشخص میکند چه فیلدهایی، با چه ساختاری و در چه اندازهای نیاز دارد. این تغییر پارادایم، مشکل بزرگی به نام Over-fetching و Under-fetching را که سالها توسعهدهندگان فرانتاند را به زحمت انداخته بود، با یک سیستم تایپ قوی، اسکیما متمرکز و کوریر هوشمند حل کرد.
معیارهای استراتژیک برای انتخاب مسیر
هیچ سبک معماری به تنهایی برنده مطلق نیست و انتخاب نهایی کاملاً به معماری محصول، تیم فنی و الزامات عملکردی بستگی دارد. REST همچنان برای سرویسهای عمومی، پروژههایی که نیاز به کشگذاری گسترده در سطح CDN دارند و زیرساختهای قدیمی که نمیتوانند به سرعت تغییر کنند، گزینهای بیرقیب است. پشتیبانی غنی از ابزارهای دیباگ، لاگگیری استاندارد و سادگی در مستندسازی، آن را به کابوی همیشگه بازار میسازد.
گرافکیوال اما در سناریوهای پیچیده، اپلیکیشنهای موبایل با محدودیت پهنای باند و فریمورکهایی که نیاز به آپدیتهای سریع رابط کاربری دارند، درخشش ویژهای دارد. سیستم تایپسیستم قوی و قابلیت کشف خودکار API، تجربه توسعهدهندگان را دگرگون کرده است و در مستندات رسمی سایت رسمی GraphQL با جزئیات کامل شرح داده شده است. اگر تیم شما با چندین کلاینت متنوع سروکار دارد یا نیاز دارد دادهها را از چند منبع مختلف به صورت یکجا درآورد، گرافکیوال بهینهترین مسیر است. انتخاب میان این دو، دیگر یک نبرد ایدئولوژیک نیست، بلکه یک تصمیم مهندسی هوشمندانه بر اساس محدودیتهای پروژه است. آینده ارتباطات وب احتمالا به سمت معماریهای هیبریدی پیش میرود که نقاط قوت هر دو سبک را در خود ادغام میکنند تا نیازهای نسل جدید اپلیکیشنها را بهتر برآورده سازند.
