انواع معماری طراحی API

امروزه، بسیاری از مصرف کنندگان API از REST به عنوان “REST در صلح” یاد می کنند و برای Graph ⁇ L خوشحالی می کنند، در حالی که ده سال پیش این یک داستان معکوس با REST به عنوان برنده جایگزینی SOAP بود.مشکل این نظرات این است که آن ها به جای در نظر گرفتن این که ویژگی ها و ویژگی های واقعی آن چگونه با وضعیت موجود مطابقت دارد، خود یک فن آوری را انتخاب می کنند.

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

Remote Procedure Call (RPC): فراخوانی یک تابع روی سیستم دیگر

فراخوانی رویه از راه دور یک ویژگی است که امکان اجرای از راه دور یک تابع در یک زمینه متفاوت را فراهم می کند.RPC مفهوم فراخوانی رویه محلی را گسترش می دهد اما آن را در چارچوب یک API HTTP قرار می دهد.

XML – RPC اولیه مشکل ساز بود زیرا اطمینان از انواع داده های باره ای XML دشوار است.بنابراین، بعدها یک API RPC شروع به استفاده از یک ویژگی JSON – RPC واقعی تر کرد که یک جایگزین ساده تر برای SOAP محسوب می شود.gRPC آخرین نسخه RPC توسعه یافته توسط گوگل در سال ۲۰۱۵ است.با پشتیبانی قابل اتصال برای متعادل سازی بار، ردیابی، بررسی سلامت و احراز هویت، gRPC برای اتصال میکروسرویس ها بسیار مناسب است.

نحوه کار RPC

یک کلاینت یک رویه از راه دور را فراخوانی می کند، پارامترها و اطلاعات اضافی را در یک پیام مرتب می کند، و پیام را به یک سرور می فرستد.پس از دریافت پیام، سرور محتوای آن را تجزیه می کند، عملیات درخواستی را اجرا می کند و نتیجه را به کلاینت باز می گرداند.stub سرور و stub کلاینت از serialization و deserialization پارامترها مراقبت می کنند.

Remote Procedure Calling Mechanism, Source: Guru99

مزایای RPC

تعامل مستقیم و ساده.RPC از GET برای دریافت اطلاعات و POST برای هر چیز دیگر استفاده می کند.مکانیک تعامل بین سرور و کلاینت به فراخوانی نقطه پایانی و دریافت پاسخ ختم می شود.

توابع آسان برای اضافه کردن.اگر یک نیاز جدید برای API خود به دست آوریم، می توانیم به راحتی یک نقطه پایانی دیگر برای اجرای این نیاز اضافه کنیم:

۱)نوشتن یک تابع جدید و انداختن آن پشت یک نقطه پایانی

۲)حالا یک مشتری می تواند به این نقطه پایانی برسد و اطلاعات را مطابق با نیاز تعیین شده به دست آورد.

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

معایب RPC

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

قابلیت کشف پایین.در RPC هیچ راهی برای وارد کردن API یا ارسال یک درخواست و شروع درک اینکه چه تابعی براساس درخواست های آن فراخوانی شود، وجود ندارد.

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

موارد استفاده RPC

الگوی RPC در حدود دهه ۸۰ شروع به استفاده کرد، اما این به طور خودکار آن را منسوخ نمی کند.شرکت های بزرگی مانند گوگل، فیسبوک (Apache Thrift)و توییچ (Twirp)از فریم ورک های با کارایی بالا RPC در داخل استفاده می کنند تا پیام رسانی با کارایی بسیار بالا و کم سر و صدا انجام دهند.سیستم های میکروسرویس عظیم آن ها نیاز به ارتباطات داخلی دارند تا در عین حال که در پیام های کوتاه مرتب شده اند، شفاف باشند.

Command API.یک RPC انتخاب مناسبی برای ارسال دستورها به یک سیستم از راه دور است.به عنوان مثال، API Slack بسیار کاربردی است: پیوستن به یک کانال، ترک یک کانال، ارسال یک پیام.بنابراین طراحان اسلک API آن را به سبک RPC شبیه سازی کردند که استفاده از آن را کوچک، فشرده و آسان می کرد.

API های مخصوص مشتری برای میکروسرویس های داخلی.با داشتن یکپارچگی مستقیم بین یک ارائه دهنده و مصرف کننده، ما نمی خواهیم زمان زیادی را صرف انتقال متادیتای زیادی بر روی سیم کنیم، مانند کاری که REST API انجام می دهد.با نرخ بالای پیام و عملکرد پیام، gRPC و Twirp موارد قوی برای میکروسرویس ها هستند.با استفاده از HTTP ۲ در زیر کاپوت، GRPC قادر است لایه شبکه را بهینه سازی کرده و آن را با ارسال چندین پیام در روز بین سرویس های مختلف بسیار کارآمد کند.با این حال، اگر هدف شما عملکرد بالای شبکه نیست، بلکه یک ارتباط پایدار API بین تیم هایی است که سرویس های میکرو متمایز منتشر می کنند، REST این موضوع را تضمین خواهد کرد.

Simple Objects Access Protocol (SOAP): در دسترس قرار دادن داده ها به عنوان سرویس

SOAP یک پروتکل ارتباطی وب با فرمت XML و بسیار استاندارد شده است.SOAP که یک سال پس از XML – RPC توسط مایکروسافت منتشر شد، چیزهای زیادی را از آن به ارث برد.پس از REST، آن ها برای اولین بار به صورت موازی مورد استفاده قرار گرفتند، اما طولی نکشید که REST برنده رقابت محبوبیت شد.

نحوه کار SOAP

فرمت داده XML تشریفات زیادی را پشت سر می گذارد.با ساختار پیام عظیم، SOAP را به پر سر و صداترین سبک API تبدیل می کند.

یک پیام SOAP از موارد زیر تشکیل شده است:

برچسب پاکتی که هر پیام را شروع و پایان می دهد،

بدنی که حاوی درخواست یا پاسخ باشد

یک سرآیند اگر یک پیام باید هر گونه ویژگی یا الزامات اضافی را تعیین کند، و

خطایی که هرگونه خطایی را که ممکن است در طول پردازش درخواست رخ دهد، اطلاع می دهد.

منطق SOAP API در زبان توصیف سرویس وب (WSDL)نوشته شده است.این زبان توصیف API نقاط پایانی را تعریف می کند و تمام فرایندهایی که می توانند انجام شوند را توصیف می کند.این کار به زبان های برنامه نویسی مختلف و IDE ها اجازه می دهد تا به سرعت ارتباط برقرار کنند.

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

مزیت های SOAP

زبان – و پلتفرم – ندانم گرا.قابلیت داخلی برای ایجاد خدمات مبتنی بر وب به SOAP اجازه می دهد تا ارتباطات را مدیریت کند و پاسخ ها را مستقل از زبان و پلتفرم بسازد.

با انواع پروتکل های حمل و نقل آشنا شوید.SOAP از نظر پروتکل های انتقال انعطاف پذیر است تا برای چندین سناریو در نظر گرفته شود.

کنترل خطای ساخته شده.ویژگی SOAP API امکان بازگرداندن پیغام Retry XML با کد خطا و توضیح آن را فراهم می کند.

تعدادی از افزونه های امنیتی.SOAP که با پروتکل های WS – Security ادغام شده است، کیفیت تراکنش در سطح سازمانی را برآورده می کند.این روش حریم خصوصی و یکپارچگی درون تراکنش ها را فراهم می کند و در عین حال امکان رمزگذاری در سطح پیام را فراهم می کند.

معایب SOAP

این روزها بسیاری از توسعه دهندگان به دلایل مختلف از ایده ادغام یک API SOAP به خود می بالند.

فقط XML.پیام های SOAP حاوی متادیتاهای زیادی هستند و تنها ساختارهای XML را برای درخواست ها و پاسخ ها پشتیبانی می کنند.

سنگین وزن است.به دلیل اندازه بزرگ فایل های XML، سرویس های SOAP به پهنای باند زیادی نیاز دارند.

دانش ⁇ gt؛ فضا – همشهری آنلاین:ساخت سرورهای SOAP API نیازمند درک عمیق از تمام پروتکل های درگیر و قوانین بسیار محدود آن ها است.

به روزرسانی پیام های خسته کننده.با نیاز به تلاش بیشتر برای اضافه کردن یا حذف ویژگی های پیام، طرح SOAP صلب پذیرش را کند می کند.

موارد استفاده SOAP

در حال حاضر، معماری SOAP بیشتر برای یکپارچه سازی داخلی در شرکت ها یا با شرکای مورد اعتماد آن ها استفاده می شود.

انتقال داده با امنیت بالا.ساختار سفت و سخت SOAP، قابلیت های امنیتی و مجوز، آن را به مناسب ترین گزینه برای اجرای یک قرارداد نرم افزاری رسمی بین API و مشتری تبدیل می کند در حالی که با قرارداد قانونی بین ارائه دهنده API و مصرف کننده API مطابقت دارد.به همین دلیل است که سازمان های مالی و دیگر کاربران سازمانی SOAP را انتخاب می کنند.

Representational state transfer (REST): در دسترس قرار دادن داده ها به عنوان منابع

REST یک سبک معماری API خود توضیحی است که توسط مجموعه ای از محدودیت های معماری تعریف شده و برای پذیرش گسترده با بسیاری از مصرف کنندگان API در نظر گرفته شده است.

رایج ترین سبک API امروز در اصل در سال ۲۰۰۰ توسط روی فیلدینگ در رساله دکترایش توصیف شد.REST داده های سمت سرور را در دسترس قرار می دهد که آن ها را در فرمت های ساده، اغلب JSON و XML نشان می دهد.

REST چگونه کار می کند

REST به اندازه SOAP تعریف نشده است.معماری پایدار باید با شش محدودیت معماری مطابقت داشته باشد:

رابط یکنواخت: امکان تعامل یکنواخت با یک سرور مشخص صرف نظر از نوع دستگاه یا برنامه

بدون حالت: حالت لازم برای رسیدگی به درخواست در داخل خود درخواست و بدون ذخیره سازی هر چیز مربوط به جلسه توسط سرور

کاچینگ

معماری کلاینت – سرور: امکان تکامل مستقل دو طرف

سیستم لایه بندی شده برنامه

توانایی سرورها در ارائه کده ای قابل اجرا به مشتری

در واقع برخی سرویس ها تنها تا حدی قابل تغییر هستند.آن ها سبک RPC را در هسته دارند، سرویس های بزرگ تر را به منابع تجزیه می کنند و به طور موثر از زیرساخت HTTP استفاده می کنند.اما بخش کلیدی استفاده از هایپرمدیا معروف به HATEOAS است که مخفف Hypertext به عنوان موتور حالت کاربردی است.اساسا، به این معنی است که با هر پاسخ، یک REST API متادیتا را فراهم می کند که به تمام اطلاعات مربوط به چگونگی استفاده از API متصل می شود.این همان چیزی است که امکان جدا کردن کلاینت و سرور را فراهم می کند.در نتیجه، هم ارائه دهنده API و هم مصرف کننده API می توانند به طور مستقل تکامل یابند بدون اینکه مانع ارتباط آن ها شوند.

Richardson Maturity Model as a goalpost to achieving truly complete and useful APIs, Source: Kristopher Sandoval

در واقع ممکن است یک منطقه خاکستری بین REST و RPC وجود داشته باشد، زمانی که یک سرویس برخی از ویژگی های REST و برخی از RPC را پیاده سازی می کند. REST به جای عمل یا فعل مبتنی بر منبع یا اسم است.

مقایسه عملیات در RPC فعل محور با عملیات در REST فعل محور

در REST کارها با استفاده از روش های HTTP مانند GET، POST، PUT، DELETE، OPTS و خوشبختانه PATCH انجام می شود.

Source: Thomas Davis

بهترین مزایا

کلاینت و سرور مجزا. REST با جدا کردن هر چه بیشتر کلاینت و سرور، امکان انتزاع بهتری را نسبت به RPC فراهم می کند. یک سیستم با سطوح انتزاعی قادر است جزئیات خود را برای شناسایی بهتر و حفظ ویژگی های خود در بر بگیرد. این باعث می شود REST API به اندازه کافی انعطاف پذیر باشد تا در طول زمان تکامل یابد و در عین حال یک سیستم پایدار باقی بماند.

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

دوست دار حافظه نهان. REST با استفاده از بسیاری از ابزارهای HTTP، تنها سبکی است که امکان ذخیره سازی داده ها در سطح HTTP را فراهم می کند. در مقابل، پیاده سازی caching روی هر API دیگری نیازمند پیکربندی یک ماژول حافظه نهان اضافی خواهد بود.

فرمت های چندگانه پشتیبانی می کنند. توانایی پشتیبانی از فرمت های متعدد برای ذخیره سازی و تبادل داده یکی از دلایلی است که REST در حال حاضر گزینه غالب برای ساخت API های عمومی است.

معایب رست:

هیچ ساختار REST واحدی وجود ندارد. هیچ راه درست و دقیقی برای ساخت REST API وجود ندارد. چگونگی مدل سازی منابع و اینکه کدام منابع برای مدل سازی به هر سناریو بستگی خواهد داشت. این امر REST را در تئوری ساده می کند، اما در عمل دشوار است.

محموله های بزرگ. REST فراداده های غنی زیادی را برمی گرداند تا مشتری بتواند همه چیز لازم در مورد وضعیت برنامه را فقط از پاسخ هایش درک کند. و این گپ زدن برای یک لوله شبکه بزرگ با ظرفیت پهنای باند زیاد کار بزرگی نیست. اما همیشه اینطور نیست. این عامل محرک اصلی برای فیسبوک بود که در سال ۲۰۱۲ به توصیف سبک Graph ⁇ L پرداخت.

مشکلات بیش از حد و کم اهمیت. پاسخ های REST اغلب نیاز به درخواست دیگری را ایجاد می کنند.
آخرین موارد استفاده

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

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

: جستجوی داده های مورد نیاز

برای بازگرداندن کارکنان مورد نیاز به REST API نیاز است.بنابراین Graph ⁇ L به عنوان یک تغییر دهنده بازی اختراع شد.

Graph ⁇ L یک نحو است که چگونگی درخواست داده دقیق را توصیف می کند.پیاده سازی Graph ⁇ L برای مدل داده یک برنامه با تعداد زیادی موجودیت پیچیده که به یکدیگر ارجاع می دهند، ارزشش را دارد.

Graph ⁇ L یک نحو است که چگونگی درخواست داده دقیق را توصیف می کند. پیاده سازی Graph ⁇ L برای مدل داده یک برنامه با تعداد زیادی موجودیت پیچیده که به یکدیگر ارجاع می دهند، ارزشش را دارد.

How to retrieve only the needed data from the GraphQL endpoint, Source: Mohit Tikoo

این روزها اکوسیستم Graph ⁇ L با کتابخانه ها و ابزارهای قدرتمندی مانند Apollo، Graphi ⁇ L و Graph ⁇ L Explorer در حال گسترش است.

نحوه کار Graph ⁇ L

Graph ⁇ L با ساخت یک طرحواره شروع می شود، که توصیفی از تمام پرس و جوهایی است که احتمالا می توانید در یک API Graph ⁇ L و تمام انواعی که باز می گردند، انجام دهید. ساخت برنامه سخت است زیرا نیاز به تایپ قوی در زبان تعریف برنامه (SDL)دارد.

با داشتن طرحواره قبل از پرس و جو، یک مشتری می تواند پرس و جو خود را در برابر اطمینان از اینکه سرور قادر به پاسخ دادن به آن خواهد بود، تایید کند. با رسیدن به برنامه backend، یک عملیات Graph ⁇ L در مقابل کل برنامه تفسیر می شود، و با داده های برنامه backend حل می شود. با ارسال یک پرس و جو عظیم به سرور، API پاسخ JSON را دقیقا با شکل داده هایی که ما درخواست کرده ایم، باز می گرداند.

Query execution in GraphQL, Source: Jonas Helfer

علاوه بر عملیات RESTful CRUD، Graph ⁇ L دارای اشتراک است که امکان دریافت اعلان های بلادرنگ از سرور را فراهم می کند.
مزایا و معایب Graph ⁇ L

شمای تایپ شده. Graph ⁇ L از قبل کارهایی که می تواند انجام دهد را منتشر می کند که قابلیت کشف آن را بهبود می بخشد. با اشاره روی یک کلاینت در Graph ⁇ L API می توانیم بفهمیم که چه پرسوناهایی در دسترس هستند.

داده های گراف مانند را به خوبی دسته بندی می کند. داده هایی که به روابط مرتبط می رسند اما برای داده های مسطح خوب نیستند.

هیچ نسخه برداری وجود ندارد. بهترین کار در نسخه نویسی این است که اصلا API را نسخه پیچی نکنید.

در حالی که REST چندین نسخه API را ارائه می دهد، Graph ⁇ L از یک نسخه واحد و در حال تکامل استفاده می کند که دسترسی مداوم به ویژگی های جدید را فراهم می کند و به کد سرور تمیزتر و قابل نگهداری تر کمک می کند.

پیام های خطای دقیق. در روشی مشابه با SOAP، Graph ⁇ L جزئیات خطاهای رخ داده را فراهم می کند. پیغام خطای آن شامل تمام حل کننده ها است و به بخش دقیق پرس و جو در خطا اشاره دارد.

مجوزهای انعطاف پذیر. Graph ⁇ L اجازه می دهد تا به صورت انتخابی عملکردهای خاصی را در حالی که اطلاعات خصوصی را حفظ می کنند، در معرض دید قرار دهیم. در همین حال، معماری REST داده ها را در بخش هایی نشان نمی دهد. یا همه چیز است یا هیچ چیز.
معایب Graph ⁇ L

مسائل مربوط به عملکرد. Graph ⁇ L پیچیدگی را به خاطر قدرتش کنار می گذارد. داشتن تعداد زیادی فیلد تودرتو در یک درخواست می تواند منجر به اضافه بار سیستم شود. بنابراین REST همچنان گزینه بهتری برای پرس و جوهای پیچیده است.

پیچیدگی بسته بندی. از آنجا که Graph ⁇ L از معناشناسی ذخیره سازی HTTP استفاده نمی کند، نیاز به یک تلاش ذخیره سازی سفارشی دارد.

بسیاری از آموزش های پیش از توسعه. بسیاری از پروژه ها که زمان کافی برای فهمیدن عملیات های مناسب Graph ⁇ L و SDL ندارند، تصمیم می گیرند مسیر شناخته شده REST را دنبال کنند.

موارد استفاده از Graph ⁇ L

API موبایل.در این حالت، عملکرد شبکه و بهینه سازی بار تک پیغامی مهم است.بنابراین، Graph ⁇ L بارگذاری داده کارآمدتری را برای دستگاه های موبایل ارائه می دهد.

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

کدام الگوی API مناسب حالت استفاده شما است؟

هر پروژه API الزامات و نیازهای متفاوتی دارد.معمولا انتخاب معماری به

زبان برنامه نویسی مورد استفاده،

محیطی که در آن در حال رشد هستید و

منابعی که باید از آن ها صرف نظر کنید، هم از نظر انسانی و هم از نظر مالی.

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

RPC با تزویج سخت خود برای میکروسرویس های داخلی کار می کند اما گزینه ای برای یک API خارجی قوی یا یک سرویس API نیست.

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

REST بالاترین انتزاع و بهترین مدل سازی API را دارد.اما در صورتی که با موبایل کار می کنید، سنگین تر و پرحرف تر است.

Graph ⁇ L یک گام بزرگ رو به جلو از نظر جمع آوری داده است اما همه زمان و تلاش کافی برای به سرانجام رساندن آن را ندارند.

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

کدام الگوی API مناسب حالت استفاده شما است؟

هر پروژه API الزامات و نیازهای متفاوتی دارد. معمولا انتخاب معماری به

زبان برنامه نویسی مورد استفاده،
محیطی که در آن در حال رشد هستید و
منابعی که باید از آن ها صرف نظر کنید، هم از نظر انسانی و هم از نظر مالی.

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

RPC با تزویج سخت خود برای میکروسرویس های داخلی کار می کند اما گزینه ای برای یک API خارجی قوی یا یک سرویس API نیست.

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

REST بالاترین انتزاع و بهترین مدل سازی API را دارد. اما در صورتی که با موبایل کار می کنید، سنگین تر و پرحرف تر است.

Graph ⁇ L یک گام بزرگ رو به جلو از نظر جمع آوری داده است اما همه زمان و تلاش کافی برای به سرانجام رساندن آن را ندارند.

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

منبع

https://www.altexsoft.com/blog/soap-vs-rest-vs-graphql-vs-rpc/