انواع پروتکل‌های API

در این مقاله می‌خواهیم در مورد انواع پروتکل‌های API توضیح دهیم. اگر نمی‌دانید API چیست توصیه می‌کنم اول این مقاله رو بخونید. اگر هم می دانید که در ادامه مقاله همراه ما باشید.

به طور کلی هفت پروتکل‌ API داریم:

• SOAP
• REST
• JSON-RPC
• gRPC
• GraphQL
• XML-RPC
• Apache Thrift

هر کدام از این پروتکل‌ها مزایا، معایب و کاربردهای خاص خودشون رو دارند. حالا به ترتیب هر کدام از این پروتکل‌ها رو توضیح می‌دهم.

SOAP (Simple Objects Access Protocol)

این پروتکل API به فرمت XML اجازه می‌دهد تا به عنوان یک API عمل کند. این پروتکل قدیم‌ترین پروتکل در حال استفاده بوده و در سال ۱۹۹۸ معرفی شده است. در واقع پروتکل SOAP از فایل‌های XML برای انتقال داده بین وب‌سرویس‌ها استفاده می‌کند.

این فایل‌ها مانند بسیاری دیگر از داده‌ها بر بستر HTTP/HTTPS ارسال می‌شود. با این حال SOAP به کاربران اجازه می‌دهد تا اطلاعات را بر بسترهای دیگر مانند TCP، SMTP، UDP و… نیز منتقل کنند.

پیام‌ها در SOAP‌ به وسیله XML رمزنگاری شده‌اند و یک ساختار مشخص دارند:

Envelope: کل داده‌ها را در تگ‌ها می‌پوشاند.

Header: حاوی تمام اطلاعات اضافه است که ممکن است برای پردازش داده مورد نیاز باشد. این قسمت اختیاری است.

Body: در این قسمت داده‌های مورد نیاز را درخواست می‌کنیم.

Fault: این قسمت تمام خطاهای احتمالی را تعریف و راهکار رفع آن‌ها را ارائه می‌کند.

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

REST (Representational State Transfer)

پروتکل REST مشکل SOAP را با پشتیبانی از چندین فرمت برای انتقال داده از جمله JSON، پایتون، HTML، متن ساده و فایل‌های رسانه برطرف می‌کند. با این حال REST برای انتقال داده تنها متکی بر HTTP/HTTPS است. APIهایی که از REST استفاده می‌کنند، APIهای RESTful نامیده می‌شوند.

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

URL :Endpoint مقصد که داده از آن درخواست می‌شود.

Method: ما در REST از متدهای از قبل مشخص شده مانند GET, POST, PUT یا DELETE برای فچ کردن داده استفاده می‌کنیم. این متدها در شیوه استفاده با یکدیگر فرق دارند برای مثال وقتی از GET استفاده می‌کنیم، درخواست به دنباله URL ضمیمه شده است. در حالی که در متد POST، داده در قالب یک درخواست HTTP ارسال می‌شود.

Headers: این قسمت جزییات درخواست را تعریف کرده و فرمت مناسب برای دریافت پاسخ را تعیین می‌کند.

Body: داده اصلی که توسط سرویس ارسال می شود.

REST APIها هنگام پیاده‌سازی انعطاف بیشتری داشته و سبک و مقیاس‌پذیر هستند.

JSON-RPC (JavaScript Object Notation- Remote Procedural Call)

پروتکل JSON-RPC در اوایل سال ۲۰۰۰ میلادی معرفی شد و به طور خاص از فرمت JSON برای ایجاد درخواست‌های محدود و ساده استفاده می‌کند. به دلیل محدود بودن دامنه کاربرد، JSON-RPC یک سری فراخوانی را تعریف می‌کند که به راحتی می‌توانند تمام درخواست‌های لازم را پیگیری کرده و نسبت به REST در مواردی خاص کارایی بهتری را ارائه می‌دهد.

در کل، JSON-RPC سبک و بدون وضعیت است و از آبجکت‌های درخواست و پاسخ برای برقراری ارتباط بین وب‌سرویس ها استفاده می‌کند.

gRPC (Google Remote Procedural Call)

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

بر خلاف پروتکل‌های قبلی، gRPC به توسعه‌دهنده اجازه می‌دهد تا توابع خود را برای ارتباطات بین سرویسی مورد نیاز تعریف کنند. gRPC از HTTP به عنوان بستر ارتباطی خود استفاده می کند و امکانات بیشتری نظیر تایم اوت‌ها، کنترل جریان و نیز ارائه می‌دهد. در این پروتکل داده در قالب protocol buffers ارسلا می‌شود.

Protocol buffers با تعریف سرویس شروع می شود، و در ادامه ساختار داده‌هایی که سرویس استفاده می‌کند را ارائه می‌دهد. این قسمت با کامپایلر protoc کامپایل می‌شود، که یک کلاس مملو از انواع داده‌های تعریف شده توسط شما و متدهای اصلی تعریف شده در زبان مورد استفاده شما ایجاد می‌کند.

حالا از این کلاس می‌توانیم برای تعیین جزییات ساز و کار API استفاده کنیم.

GraphQL

GraphQL توسط فیسبوک توسعه داده شده و در سال ۲۰۱۵ معرفی شد.

GraphQL راهکار خیلی جالبی برای ارتباط API در پیش می‌گیرد. عبارت GraphQL مخفف عبارت Graph Query Language است، بنابراین مانند زبان‌های کوئری پایگاه داده مثل SQL در واقع دیتا را از سرور کوئری می‌گیرد. این کار در زمان و حافظه صرفه‌جویی می‌کند زیرا به جای این که یک پکیج کلی با کلی اطلاعات اضافه را فراخوانی کند، تنها داده خاص مورد نیاز را از سرور می‌گیرد. GraphQL طوری توسعه داده شده تا از زبان‌های مختلف برنامه‌نویسی وب پشتیبانی کند. مشکل زمانی ایجاد می‌شود که می‌خواهیم داده را کش کنیم. چون داده به طور خاص ذخیره شده، ممکن است نیاز باشد دیگر جنبه‌های داده را جداگانه درخواست کنید.

XML-RPC(Extensible Markup Language Remote Procedural Call)

XML RPC بسیار شبیه به JSON RPC است، با این تفاوت که داده در قالب فایل‌های XML و بر بستر HTTP/HTTPS انتتقال پیدا می‌کند. XML از یک لغتنامه دورنی برای مشخص کردن ماهیت درخواست‌ها و پاسخ‌ها استفاده می‌کند. کلاینت فرایندی که باید فراخوانی شود و پارامترهای پشتیبانی را تعیین می‌کند، که در نهایت از طریق HTTP ارسال شده و دریافت‌کننده، پاسخ را در قالب XML ارسال می‌کند که می‌تواند حاوی داده درخواست شده یا یک fault باشد.

XML-RPC به خاطر اتکا به XML محدود است، چرا که شی‌های پیچیده نمی‌توانند در XML به صورت بهینه رمزنگاری شوند، و XML نمی‌تواند حاوی داده‌ای باشد که در لغتنامه تعریف نشده است.

Apache Thrift

Apache Thrift هم توسط فیسبوک توسعه داده شده اما ساختار آن با GrapgQL متفاوت است. Apache Thrift در واقع یک نسخه از فریم‌ورک RPC است که از یک موتور تولید کد و به همراه پشته نرم‌افزار برای فعال کردن API استفاده می‌کند. پشته نرم‌افزار به نوشتن کد تعریف‌کننده کلاینت و سرور کمک می‌کند. این کار با استفاده از فایل‌های Thrift انجام می‌شود. ساختار این کد بسیار ساده و کاربردی است. بعد از آن موتور تولید کد، کد لازم را در هر زبانی که توسعه‌دهنده درخواست کرده، تولید می کند.

Thrift با تمرکز بر روی دو هدف توسعه داده شده است.:

• امکان برقراری ارتباط بین سرویس‌های نوشته به زبان‌های مختلف
• مقیاس‌پذیری

استفاده از موتور تولید کد سرویس‌ها را انعطاف‌پذیر می‌کند.

برای انتقال داده بین سرویسی، Thrift از کتابخانه‌های Runtime استفاده می‌کند. معماری Thrift این کتابخانه‌ها را در سطح متفاوتی از سرویسی تعریف می‌کند که توسعه‌دهنده کد آن را نوشته است. بنابراین تغییرات در Thrift می‌تواند به راحتی و بدون نیاز به کامپایل مجدد کد صورت پذیرد. Thrift در کنار فرمت‌های باینری، از HTTP برای انتقال داده‌ها پشتیبانی می‌کند.

در این مقاله با هفت پروتکل مهم در API آشنا شدید. شما به عنوان توسعه‌دهنده از کدام پروتکل‌ها استفاده کرده‌اید؟ به نظر شما کدام‌یک کاربردی‌تر است؟