API (اِی پی آی)

0 172

API (اِی پی آی) چیست؟

API یا همان ای پی آی واژه ایست که تاکنون زیاد شنیده اید. اما مفهوم این واژه چیست و چه انواعی دارد؟ بهتر است بجای شروع با پرداختن به امکانات، ابتدا آن‌ها را بخوبی مورد تحلیل قرار داده، و چگونگی بوجود آمدن آن‌ها را درک کنیم، این نوشته، مقدمه‌ای است بر GraphQL و درس‌هایی که در طول ۶۰ سال توسعه اِی پی آی (API) اَپی‌ها آموخته‌ایم.

قصد دارم در این مجموعه مقالات، شما را با GraphQL آشنا کنم. در انتهای این مجموعه، شما باید ماهیت، و البته پایه و اساس، مشکلات و نحوه پایه‌ای استفاده از آن را درک کرده باشید. در بخش اول این مقاله، بجای اینکه سریعاً سراغ پیاده‌سازی برویم، قصد دارم با نگاهی بر درس‌هایی که در ۶۰ سال توسعه اَپی (API)، از RPC تا کنون آموخته‌ایم، توضیح دهم که چگونه تصمیم به بوجود آوردن GraphQL گرفتیم.

بهرحال، همانطور که مارک تواین به زیبایی بیان کرده، چیزی به اسم ایده جدید وجود ندارد.

«چیزی به اسم ایده جدید وجود ندارد. ایده جدید غیرممکن است. ما خیلی ساده، ایده‌های قدیمی را گرفته، به آنها زرق و برق داده و به عنوان ایده جدید معرفی می‌کنیم.»

مارک تواین، در زندگینامه‌ی خود: فصل‌هایی از مجله «North American Review»

ولی در ابتدا، باید به چیزی اشاره کنم که همه از بیانش واهمه دارند. موضوعات جدید همیشه جالب توجه هستند، ولی در عین حال می‌توانند طاقت‌فرسا نیز باشند. شاید شما در مورد GraphQL چیزی شنیده باشید و پیش خودتان فکر کرده باشید «آخه چرا..). شاید هم به این فکر کرده باشید که «چرا باید سراغ یک مدل دیگه‌ی طراحی اَپی برم؟ همون REST … خوب بود دیگه.» اینها سوالات خوبی هستند، پس اجازه بدید برای شما توضیح بدم که چرا باید به این یک مورد توجه داشته باشید.

 

مقدمه‌ای بر اِی پی آی (API) و انواع آن

در هنگام استفاده از ابزار جدید در تیم خود، باید فواید و معایب آن را سبک و سنگین کنید. مسائل زیادی نیاز به اندازه‌گیری خواهند داشت. زمانی که برای یاد گرفتن آن باید صرف شود؛ زمانی که می‌تواند برای توسعه امکانات جدید صرف شود و البته زمان سربار که برای رسیدگی به دو سیستم همزمان نیاز دارید.

با وجود چنین هزینه‌های سنگینی، هر فناوری جدید باید با اختلاف بسیار بهتر، سریعتر و پربارتر باشد. بهبودهای آهسته، هیجان انگیزند، ولی ارزش سرمایه‌گذاری را نخواهند داشت.

انواع اِی پی آی (API) که من قصد صحبت در مورد آنها را دارم و بطور ویژه GraphQL، به عقیده من قدم بسیار بزرگ رو به جلو هستند، و فوایدی که فراهم می‌آوردند برای توجیه هزینه‌ها، زیادی هم خواهند بود.

بهتر است بجای شروع با «پرداختن به امکانات» ابتدا آن‌ها را بخوبی مورد تحلیل قرار داده، و چگونگی بوجود آمدن آن‌ها را درک کنیم. برای انجام این کار، با خلاصه‌ای از تاریخ اَپی (API) شروع می‌کنم.

API (اِی پی آی)


RPC اِی پی آی (API)

بطور قطع RPC اولین الگوی اصلی برای اَپی (API) بوده، و وجود آن به سال‌ها قبل یعنی اواسط دهه ۶۰ میلادی برمی‌گردد. در آن زمان، کامپیوترها هنوز آنقدر بزرگ و گران‌قیمت بودند، که مفهموم توسعه برنامه‌های کاربردی بر اساس اِی پی آی، آنگونه که ما امروز آن‌ها را می‌شناسیم، فقط در حد تئوری وجود داشت.

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

از زمان ARPANET در دهه ۶۰، تا زمان CORBA و Java RMI در اواسط دهه ۹۰ میلادی، بیشتر کامپیوترها با استفاده از «فراخوانی‌های رویه‌ای راه‌دور» یا همان RPC با هم تعامل داشند.

RPC مدلی برای تعامل بین سرور و کلاینت است که در آن کلاینت از راه دور، رویه (یا متدی) برای اجرا روی یک سرور ایجاد می‌کند. بسیاری مسائل در مورد RPC کاملاً مطلوب هستند.

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

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

در طول این چند دهه، تحقیقات بسیار زیادی در مورد این موضوع انجام شد، که چگونه توسعه‌دهندگان می‌توانند رفتارهای غیرهمگام اینچنینی را داخل جریان برنامه‌های عادی قرار دهند؛ اگر مفاهیمی مانند Promise ها، Future ها و وظایف زمان‌بندی‌شده در آن زمان وجود داشتند، شاید امروز چشم‌انداز ما در مورد اِی پی آی طور دیگری می‌بود.

یک موضوع عالی دیگر در مورد RPC این است که از آنجا که محدودیتی در مورد نوع ساختمان داده ندارد، روش‌های ویژه‌ای می‌تواند برای مشتریانی که دقیقاً اطلاعات مورد نظر خود را درخواست و دریافت می‌کنند، نوشته شوند. این موضوع می‌تواند به حداقل شدن سربار و payload در هر لایه شبکه کمک کند.

با این حال، چیزهایی هم وجود دارند که کار با RPC را دشوار می‌کنند. اولاً اینکه تداوم نیاز به زمینه دارد. طراحی RPC به این صورت انجام شده است که سیستم‌های محلی و راه‌دور را به شکلی قوی به هم متصل می‌کند. این موضوع باعث می‌شود مرزهای بین کدهای محلی و راه‌دور شما از بین بروند. برای بعضی حوزه‌ها مثل مشتریان SDK، این موضوع بدون اشکال یا حتی مطلوب است، ولی برای اَپی‌هایی که کد مشتری خوب درک نشده باشد، بجای داده‌محور شدن، باعث کم شدن انعطاف‌پذیری می‌شود.

ولی از آن مهم‌تر، پتانسیل تکثیر متدهای اِی پی آی (API) است. در تئوری، یک سرویس RPC در حقیقت اِی پی آی (API) کوچک و فکرشده‌ای را ارائه می‌دهد که قادر به انجام هر کاری باشد. اما در عمل، endpointهای بسیاری، بدون ساختار خاصی با هم ترکیب می‌شوند. بنابراین به مرور زمان و همانطور که اعضای تیم کم و زیاد می‌شوند و پروژه تغییر مسیر می‌دهد، ایجاد نظمی بسیار شدید و سختگیرانه برای جلوگیری از هم‌پوشی اَپی‌ها و ایجاد نسخه‌های تکراری، مورد نیاز خواهد بود.

درست است که در صورت داشتن ابزار و مستندسازی مناسب، مانند موردی که ذکر کردم، تغییرات قابل مدیریت و انجام هستند، ولی در طول مدت برنامه‌نویسی خودم، تعداد فوق‌العاده کمی سرویس دیدم که دارای مستندسازی و نظم مناسب باشند. برای من این موضوع بیشتر شبیه به نخود سیاه است.

 

SOAP اِی پی آی (API)

نوع اصلی دیگر اِی پی آی (API) که بوجود آمد، SOAP بود، که در اواسط دهه ۹۰ و توسط مرکز تحقیقات مایکروسافت متولد شد. SOAP یا «پروتوکل دسترسی ساده اشیاء» توصیف پروتوکل جاه‌طلبانه‌ای برای ارتباطات مبتنی بر XML میان برنامه‌های کاربردی است. هدف اصلی SOAP، برطرف کردن برخی اشکالات عملی در RPC و بطور خاص RPC مبتنی بر XML بوده، توسط ساختن زیرساخت خوش‌ساختی برای سرویس‌های پیچیده وب بوده است. اما در حقیقت، بیش از موانعی که برطرف می‌کند، موانع ایجاد می‌کند. این موضوع که امروزه تعداد بسیار کمی endpoint توسط SOAP ساخته شده‌اند، خود گواهی بر این موضوع است.

«بیشتر مردم SOAP را موفقیتی نصفه و نیمه می‌دانند.»

-دان باکس

علیرغم قلنبه سلمبه بودن و اسم‌گذاری‌های بد، SOAP چیزهای خوبی نیز دارد. قراردادهای قابل اجبار برای WSDL و WADL (که به ترتیب ویزدل و وادل تلفظ می‌شوند) بین کلاینت و  سرور، از قابل پیش‌بینی بودن و امنیت نوع داده نتایج اطمینان حاصل می‌کند، و WSDL می‌تواند برای تولید مستندسازی و یا یکپارچه‌سازی بین IDE ها و دیگر ابزار استفاده شود.

انقلاب بزرگ SOAP در اِی پی آی (API) این بود که بطور تدریجی و شاید حتی ناخواسته، فراخوان‌های منبع‌گرا را معرفی کرد. Endpointهای SOAP اجازه می‌دهند بجای اینکه برای تولید داده‌ها به چه متدهایی نیاز داریم درخواست‌هایی با ساختار از پیش تعیین شده داشته باشیم (البته اگر اینطور از آن استفاده کنیم). مهمترین ایراد SOAP قلمبه و سلنبه بودن آن است. استفاده از SOAP بدون استفاده از ابزارهای بسیار زیاد، تقریباً غیرممکن است. برای نوشتن تست، برای مشاهده پاسخ‌های دریافت شده از سرور و برای parse کردن داده‌ها به ابزارهای مختلف نیاز خوهیم داشت. خیلی از سیستم‌های قدیمی هنوز از SOAP استفاده می‌کنند، ولی نیاز به استفاده از ابزارهای زیاد، باعث می‌شود استفاده از آن در پروژه‌های جدید بسیار خسته کننده باشد، و تعداد بایت‌های مورد نیاز برای ساختار XML باعث شده که SOAP انتخاب بسیار بدی برای موبایل‌ها و سیستم‌های توزیع شده که تعداد مراجعات در آن‌ها زیاد است باشد.

برای اطلاعات بیشتر، خواندن مشخصات SOAP خالی از فایده نخواهد بود. همینطور مقاله بسیار جالب تاریخچه SOAP توسط دان باکس، یکی از اعضای اصلی تیم.

 

REST

دست آخر، رسیدیم به الگوی طراحی اِی پی آی (API) محبوب همه: REST. معرفی شده در پایان‌نامه دکتری روی فیلدینگ در سال ۲۰۰۰، REST ذهن همه را کلاً به سمت و سوی دیگری برد. REST از خیلی نظرها، کاملاً با SOAP در تضاد بوده، و مقایسه این دو، باعث می‌شود که پایان‌نامه روی فیلدینگ نوعی عقده‌گشایی به نظر بیاید.

SOAP از HTTP استفاده کرده و بدون اینکه حتی لایه انتقال داده شبکه را در نظر بگیرد، ساختار خود را در بدنه‌ی تقاضاها و پاسخ‌ها ایجاد می‌کند. از طرف دیگر، REST قراردادهای بین کلاینت و سرور، ابزارها، XML و هِدِرهای قراردادی را کنار گذاشته، و مفاهیم اساسی HTTP را جایگزین آن‌ها می‌کند، چرا که بجای اینکه از verbهای HTTP برای تعامل با داده و از URIها برای رجوع به ساختار منابع سلسه‌مراتبی استفاده کند، ساختار داده در آن قابل انتخاب است.

 

SOAP REST
Verbهای HTTP هرگز! GET, PUT, POST, PATCHT DELETE
قالب داده‌ها XML هرکدام که بخواهید
قراردادهای بین کلاینت و سرور همواره! کی همچین چیزی لازم داره؟
سیستم نوع داده بله نوع داده چی هست؟!
URLها بسته به عملیات منابع مشخص شده

 

REST بطور کامل و صریح طراحی اِی پی آی (API) را دستخوش تغییر قرار داد و آن را از مدلسازی فعل و انفعالات، به مدلسازی برای دامنه داده‌ها تبدیل کرد. بخاطر کاملاً منبع‌گرا بودن اَپی تحت REST، نه لازم است بدانید، یا اهمیتی قائل شوید که برای دریافت اطلاعات مورد نظرتان چه پروسه‌ای انجام می‌شود؛ نه لازم است اصلاً چیزی در مورد نوع پیاده‌سازی سرویس backend بدانید.

این موضوع تنها خبر خوش برای توسعه‌دهندگان نبود. بدلیل آنکه URL ها اطلاعات ثابتی می‌دهند، این اطلاعات براحتی قابل نگهداری در حافظه نهان هستند، و مهم نبودن نوع داده باعث، بخودی خود باعث ساده شدن کارهاست، و در نهایت از آنجا که REST بجای اینکه با نیازهای مصرف‌کننده کار داشته باشد، به دنبال مدلسازی داده‌هاست، باعث کوچکتر و ساده‌تر شدن اِی پی آی (API) می‌شود.

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

صفحه ‌اصلی وبلاگ که عنوان و نویسنده هر پست را نمایش می‌دهد.

 

 

API

 

صفحه ‌اصلی وبلاگ که عنوان و نویسنده هر پست را نمایش می‌دهد.

باید کدی بنویسیم که داده‌های صفحه اصلی را از یک اَپی REST دریافت کنیم. با تعدادی تابع مربوط به منابعمان شروع می‌کنیم.

 

API چیست؟

 

حالا، این توابع را مرتب می‌کنیم.

REST

کارهایی که کد ما انجام می‌دهد به شرح زیر است:

-واکشی تمام پست‌ها؛

-واکشی جزئیات هر پست؛

واکشی منابع مربوط به نویسنده برای هر پست؛

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

REST API

البته این ایراد به این مثال وارد است که اَپی ما می‌توانست یک endpoint جداگانه بصورت /posts برای پست‌های وبلاگ داشته باشد، ولی در واقع این بسیار ریز بینانه است. واقعیت این است که اغلب مواقع مجبور خواهید بود فراخوانی‌های مختلفی به اِی پی آی (API) انجام دهید، که در نهایت برای تشکیل یک صفحه یا برنامه کاربردی به یکدیگر وابسته خواهند بود.

توسعه سرور و کلاینت‌های تحت REST مسلماً بهتر از استفاده از چیزهایی است که قبل از آن وجود داشتند، یا حداقل اینکه امکان ارتکاب اشتباه در آن کمتر است، ولی از زمان مقاله فیلدینگ تا به امروز،   اوضاع خیلی تفاوت کرده‌ است. در آن زمان، کامپیوترها پلاستیکی و کرم‌رنگ بودند، ولی در حال حاضر آلومینیومی هستند! گذشته از شوخی، سال ۲۰۰۰ تقریبا اوج رشد کامپیوترهای شخصی بود.

هر سال قدرت پردازنده‌ها دو برار می‌شد، و سرعت شبکه‌ها با نرخ خیره‌کننده ای در حال سریع شدن بودند. ضریب نفوذ اینترنت حدود ۴۵ درصد بود، و به نظر نمی‌رسید دیگر از آن بالاتر بروند.

پس از آن، در حدود سال ۲۰۰۸، کامپیوترهای موبایل به امری عادی تبدیل شدند، و با رشد موبایل‌ها، عملاً یک‌شبه به اندازه یک دهه از نظر نسبت سرعت به کارایی عقب افتادیم. در سال ۲۰۱۷، نفوذ موبایل به حدود ۸۰% در آمریکا و در تمام جهان به بیش از ۵۰% رسیده، و وقت آن شده است که در بعضی از فرضیاتمان در مورد طراحی اَپی (API)، تجدید نظر کنیم.

 

ضعف‌های REST

در ادامه از دید یک توسعه‌دهنده برنامه کاربردی، بطور خاص برای موبایل به REST نگاهی خواهیم داشت. GraphQL و اِی پی آی (API) مبتنی بر آن، موضوع جدیدی نیستند، و مشکلات خارج از دسترسی توسعه‌دهندگان REST را برطرف نمی‌کنند. مهمترین کار GraphQL ، توانایی آن در حل سیستماتیک این مشکلات و با ایجاد سطحی از یکپارچه‌سازی است که جای دیگری در دسترس نیست. به عبارت دیگر، GraphQL راه حلی است مانند باطری‌هایی است که داخل جعبه دستگاه‌های مختلف می‌گذارند.

نویسندگان اصلی REST که شامل فیلدینگ هم می‌شود، در سال ۲۰۱۷ مقاله‌ای منتشر کردند (Reflections on the REST Architectural Style and “Principled Design of the Modern Web Architecture”) که بازتاب دهنده دو دهه کار با REST و الگوهای دیگری است که از آن الهام گرفته‌اند. این مقاله برای تمام افرادی که به طراحی اَپی (API) علاقه‌مندند، بسیار مختصر و مفید است.

بعد از این مقدمه تاریخی و مثال کاربرد، نگاهی داشته باشیم به سه ایراد بزرگ REST.

 

REST پرحرف است

بخاطر اینکه برای دریافت داده به اندازه کافی برای استفاده در یک اپلیکیشن، باید رفت و آمد زیادی بین کلاینت و سرور رخ دهد، سرویس‌های REST حداقل اینکه «پرحرف» قلمداد می‌شوند. این فوران درخواست‌، اثرات مخربی بر کارایی، مخصوصا در موبایل دارد. اگر دوباره به مثالی که پیش‌تر زدیم رجوعع کنیم، حتی در بهترین حالت ممکن با یک گوشی موبایل جدید و اتصال سریع نسل۴، حداقل نیم ثانیه فقط تأخیر سربار خواهید داشت، پیش از اینکه حتی شروع به دریافت داده‌ها کنید.

۵۵میلی‌ثانیه × ۸ درخواست = ۴۴۰میلی‌ثانیه تأخیر

تأخیر واکنش کاربر
۰ – ۱۰۰ میلی‌ثانیه بلافاصله
۱۰۰ – ۳۰۰ میلی‌ثانیه کمی کند
۳۰۰ – ۱۰۰۰ میلی‌ثانیه صبر برای اتمام کار ماشین
بیش از ۱ ثانیه تغییر زمینه فکری
بیش از ۱۰ ثانیه بعداً مزاحمتون میشم…

جدولی که واکنش کارابر به سطوح مختلف کارایی اپلیکیشن را نشان می‌دهد.

مشکل دیگر سرویس‌های پرحرف، این است که در بسیاری موارد دریافت یک صفحه بزرگ، زمان کمتری از دریافت یک صفحه کوچک نیاز دارد. کم شدن کارایی درخواست‌های کوچک دلایل زیادی دارد، از جمله شروع آهسته و کند پروتوکل TCP، فقدان فشرده‌سازی هِدِر و کارایی gzip. اگر در مورد این موضوع کنجکاو هستید، خواندن مقاله ایلیا گریگوریک با عنوان شبکه مرورگر پرسرعت را قویاً پیشنهاد می‌کنم. وبلاگ MaxCDN نیز مرور بسیار خوبی در این مورد انجام داده است.

این مشکل، در حقیقت ایراد فنی خود REST نیست، بلکه ایراد HTTP است، مخصوصا نسخه ۱ آن. HTTP/2 مشکل پرحرف بودن همه سبک‌های اَپی (API) را برطرف نموده، و در کلاینت‌ها مثل مرورگرها و SDKها بخوبی پشتیبانی ‌می‌شود. متأسفانه، استفاده از آن در اَپی‌ها محدود بوده است. در حال حاضر در سال ۲۰۱۷، بین ۱۰هزار وبسایت بزرگ دنیا، حدود ۲۰% آن‌ها به HTTP/2 کوچ کرده‌اند.

در کمال تعجب، حتی Node.js پشتیبانی از HTTP/2 را تا نسخه ۸ خود ایجاد نکرده بود. اگر توانش را دارید، لطفا زیرساخت‌هایتان را بروزرسانی کنید! در عین حال، نباید بیش از اندازه هم به این موضوع بپردازیم، چرا که این تنها بخشی از معادله است.

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

 

TMI (واکشی بیش از اندازه)

اشکال بعدی که سرویس‌های مبتنی بر REST دارند، این است که اطلاعات بسیار بیشتر از آنچه مورد نیاز است ارسال می‌کنند. در مثالی که بالاتر زدیم، ما فقط عنوان و نام نویسنده هر پست را نیاز داریم، که فقط حدود ۱۷% از داده‌های برگشت داده شده را تشکیل می‌دهند، این یعنی ۶برابر زیان برای یک payload بسیار ساده. در یک اِی پی آی (API) واقعی، این حجم از سربار فوق‌العاده زیاد است. به عنوان مثال، فروشگاه‌های اینترنتی، معمولاً یک محصول را با هزاران خط کد JSON نمایش می‌دهند. همانند مشکل «پرحرف بودن»، امروزه سرویس‌های REST می‌توانند با استفاده از fieldset های اسپارس و با ایجاد شروط برای شامل شدن یا نشدن قسمت‌های داده‌ها، این مشکل را حل کنند. متاسفانه، پشتیبانی از این موضوع نادر، ناقص و برای سیستم حافظه‌نهان شبکه مشکل‌زا است.

 

شکل دهی و خودآزمایی

آخرین نکته‌ای که اَپی‌های REST دچار فقدان آن هستند، مکانیزمی برای خودآزمایی است. بدون داشتن هیچگونه قراردادی در مورد نوع داده‌های برگشتی، یا ساختار یک endpoint، هیچ راه قابل اعتمادی برای تولید مستندسازی، ایجاد شکل‌دهی و تعامل با داده‌ها وجود ندارد. کارکردن بر روی REST برای رفع این مشکل تا حدودی امکان‌پذیر است. پروژه‌هایی که بطور کامل OpenAPI، OData و یا JSON API را پیاده‌سازی می‌کنند، اغلب تمیز، بخوبی مشخص شده و تا حد متناسبی دارای مستندسازی خوبی هستند، ولی backendهای اینچنینی نایابند.

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

 

نتیجه‌گیری اِی پی آی (API)

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

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

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

 

اِی پی آی (API)

ترجمه: توسط اَپی ِاکو اولین اِی پی آی مارکت ایرانی

 

 

 

 

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.