RESTful API چیست؟

API RESTful یک سبک معماری برای یک رابط برنامه نویسی کاربردی است که از درخواست های HTTP برای دسترسی و استفاده از داده ها استفاده می کند. از این داده ها می توان برای دریافت، قرار دادن، ارسال و حذف انواع داده استفاده کرد که به خواندن، به روز رسانی، ایجاد و حذف عملیات مربوط به منابع اشاره دارد.

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

API های RESTful با نام های وب سرویس های RESTful و API های REST نیز شناخته می شوند. آنها بر اساس انتقال حالت نمایشی، یک سبک معماری و رویکرد ارتباطات هستند که اغلب در توسعه خدمات وب استفاده می شود. این رویکرد همچنین می تواند ارتباط بین انواع دیگر برنامه ها را تسهیل کند.

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

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

عناصر اصلی RESTful API چیست؟

یک REST API اساساً بر سه عنصر اصلی متکی است:

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

برای دسترسی به یک منبع، مشتری یک درخواست HTTP را به سرور ارسال می کند. درخواست های مشتری شامل چهار بخش اصلی است:

• متد HTTP . توضیح می دهد که چه اتفاقی باید برای منبع مشخص شده بیفتد. چهار متد اصلی HTTP به عنوان افعال شناخته می شوند. POST برای ایجاد یک منبع جدید، GET برای بازیابی یک منبع موجود، PUT برای به روز رسانی یا تغییر یک منبع موجود، و DELETE برای حذف یک منبع هستند. همانطور که جدول زیر نشان می دهد، این متدهای HTTP با اقدامات ایجاد، بازیابی، به روز رسانی و حذف مطابقت دارند که به آنها CRUD گفته می شود.
• نقطه پایانی یا Endpoint . نقطه پایانی نشان می دهد که منبع در کجا قرار دارد که معمولاً شامل یک شناسه منبع یکنواخت (URI) است. اگر منبع از طریق اینترنت قابل دسترسی باشد، URI می تواند آدرس اینترنتی باشد که آدرس وب را برای منبع ارائه می دهد.
• Header . یک Header دارای جزئیات مورد نیاز برای درخواست تماس و رسیدگی به پاسخ است. Header درخواست ممکن است شامل داده های احراز هویت، یک کلید رمزگذاری، جزئیات بیشتر در مورد مکان سرور یا دسترسی به اطلاعات و جزئیات مربوط به قالب داده مورد نظر برای پاسخ باشد.
• Body . بدنه حاوی اطلاعات مربوطه به یا از سرور است. به عنوان مثال، یک بدنه ممکن است حاوی داده های جدیدی باشد که باید از طریق روش POST یا PUT به سرور اضافه شود.

سمت سرور میزبان تماس API است و یک پاسخ را برای درخواست کار ایجاد می کند. هنگامی که داده ای درخواست می شود، سرور نمایشی قابل خواندن توسط ماشین از داده های درخواستی را برای کلاینت ارسال می کند. معمولاً جزئیات پاسخ شامل هرگونه اطلاعات مورد نیاز برای تفسیر پاسخ است، مانند اینکه آیا داده‌ها به زبان نشانه‌گذاری توسعه‌یافته (XML)، نمادگذاری شی جاوا اسکریپت (JSON) یا قالب متن ساده هستند. سرور داده های اضافی مانند کدهای خطا و مهرهای زمانی یا سایر دستورالعمل ها را برای مشتری فراهم می کند.

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

چگونه API های RESTful کار می کنند؟

یک RESTful API تراکنش را به یک سری ماژول های کوچک تجزیه می کند. هر ماژول به یک بخش زیربنایی از تراکنش می پردازد. این ماژولار بودن به توسعه دهندگان انعطاف پذیری می دهد، اما طراحی REST API از ابتدا می تواند چالش برانگیز باشد. چندین شرکت، از جمله Amazon S3، Cloud Data Management Interface و OpenStack Swift، مدل هایی را برای توسعه دهندگان ارائه می دهند.

یک API RESTful از دستورات برای بدست آوردن منابع استفاده می کند. وضعیت یک منبع در هر مهر زمانی معین، نمایش منبع نامیده می شود. یک API RESTful از متدولوژی های HTTP موجود استفاده می کند که پروتکل RFC 2616 تعریف کرده است، مانند GET، PUT، POST و DELETE.

فرمت های داده ای که REST API پشتیبانی می کند عبارتند از: application/json، application/xml، application/x-web+xml، application/x-www-form-urlencoded و multipart/form-data.

RESTful API چگونه استفاده می شود؟

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

این رویکرد کار می کند زیرا هر درخواستی را می توان به هر نمونه ای از یک جزء هدایت کرد. هیچ چیزی که تراکنش بعدی باید به خاطر بسپارد ذخیره نمی شود. این باعث می شود استفاده از API های REST برای برنامه های وب ترجیح داده شود.

مدل RESTful در خدمات ابری مفید است زیرا اتصال به یک سرویس از طریق یک API به کنترل نحوه رمزگشایی URL بستگی دارد. محاسبات ابری و میکروسرویس‌ها تقریباً مطمئن هستند که طراحی RESTful API را در آینده به قانون تبدیل می‌کنند.

API های RESTful اغلب در برنامه های موبایل و مبتنی بر وب برای دسترسی و تغییر داده ها در سیستم های راه دور در سراسر اینترنت استفاده می شوند. نمونه های بی شماری از موارد استفاده وجود دارد، اما چهار مورد زیر برخی از محبوب ترین آنها هستند:

• Mobility. برنامه‌های موبایلی مانند Lyft و Uber از REST API برای دسترسی به نقشه‌ها و برنامه‌ریزی سفرها استفاده می‌کنند.
• بانکداری. این برنامه‌ها از REST API برای دسترسی به داده‌های حساب و پشتیبانی از تراکنش‌ها استفاده می‌کنند.
• خدمات پخش جریانی. Spotify، Netflix و سایر سرویس‌های پخش از REST API برای دسترسی به رسانه از سرورهای راه دور استفاده می‌کنند.
• رسانه های اجتماعی. سرویس هایی مانند X و Facebook از REST API برای ایجاد و مدیریت پست ها و همچنین ادغام با سایر برنامه ها استفاده می کنند.

محدودیت های طراحی و معماری RESTful API

دکتر روی فیلدینگ، دانشمند ارشد در Adobe، طراحی RESTful API را در پایان نامه دکترای خود در سال 2000 به عنوان یک سرویس وب که به شش محدودیت معماری REST زیر پایبند است، تعریف کرد:

• رابط یکنواخت. منابع باید از طریق یک URL واحد قابل شناسایی باشند. دستکاری یک منبع باید فقط از طریق روش های پروتکل شبکه DELETE، PUT و GET با HTTP انجام شود.
• مبتنی بر کلاینت-سرور. مرزبندی بین مشتری و سرور باید واضح باشد. نگرانی های UI و جمع آوری درخواست دامنه مشتری نباید به سمت سرور ارتباطی داشته باشد. دسترسی به داده ها، مدیریت حجم کار و امنیت دامنه مرتبط با سرور است. این اتصال آزاد مشتری و سرور به هر یک اجازه می دهد تا مستقل از دیگری توسعه یافته و ارتقا یابد.
• عملیات بدون حالت. همه عملیات سرویس گیرنده-سرور باید بدون حالت باشند. هر گونه مدیریت حالت مورد نیاز باید روی کلاینت اتفاق بیفتد نه سرور.
• کش منابع RESTful. همه منابع باید به کش داده ها اجازه دهند مگر اینکه این امکان وجود نداشته باشد.
• سیستم لایه ای. REST یک معماری متشکل از چندین لایه سرور را فعال می کند.
• کد در صورت تقاضا. معمولاً یک سرور نمایش های ایستا از منابع را در قالب XML یا JSON ارسال می کند. با این حال، در صورت لزوم، سرورها می توانند کدهای اجرایی را برای مشتری ارسال کنند.

مزایای RESTful API چیست؟

API های REST مزایای بی شماری برای توسعه دهندگان و سازمان ها در دسترس قرار می دهند، از جمله موارد زیر :

• سادگی. API های REST از روش های رایج HTTP از جمله درخواست های GET، PUT، POST و DELETE استفاده می کنند که طراحی، پیاده سازی و استفاده از آنها را آسان می کند.
• استقلال. توسعه دهندگان از استقلال پلت فرم لذت می برند زیرا می توانند تقریباً از هر زبان برنامه نویسی برای ایجاد REST API استفاده کنند. آنها با دستگاه های مشتری مختلف، مانند مرورگرهای وب سنتی، دستگاه های تلفن همراه و دستگاه های اینترنت اشیا کار می کنند.
• قابل انعطاف. API های REST از فرمت های داده های مختلف از جمله JSON، XML و متن ساده پشتیبانی می کنند. توسعه دهندگان می توانند قالب داده ای را انتخاب کنند که به بهترین وجه با نیازهای مشتری و داده های موجود در سمت سرور مطابقت دارد.
• مقیاس پذیر. ماهیت بدون حالت API های REST از مقیاس بندی افقی پشتیبانی می کند، جایی که بسیاری از فراخوانی های API به صورت موازی اجرا می شوند.
• قابل کش سازی. API های REST از کش پشتیبانی می کنند و به داده ها اجازه می دهند در حافظه محلی ذخیره شوند. این رویکرد می تواند زمان پاسخ سمت سرور را سرعت بخشد و به طور بالقوه عملکرد API را بهبود بخشد. حتی ممکن است نیاز به تماس API را از بین ببرد اگر داده های مورد نیاز از درخواست قبلی کاربر وجود داشته باشد.
• ایمنی. API های REST می توانند تماس ها و تبادل داده ها را با احراز هویت Open Authorization (OAuth) و Secure Sockets Layer/Transport Layer Security ایمن کنند.
• سازگار. استفاده صحیح از نسخه‌سازی به توسعه‌دهندگان اجازه می‌دهد تا APIها را مانند هر نرم‌افزار در حال تکامل دیگری در نظر بگیرند، و ویژگی‌های جدیدی را در طول زمان با سازگاری به عقب و پشتیبانی از ویژگی‌های قدیمی برای مشتریان فعلی اضافه کنند.

چالش های رایج REST API

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

• ثبات نقطه پایانی. برای سازگاری، مسیرهای نقطه پایانی باید از استانداردهای رایج وب پیروی کنند، که ممکن است مدیریت آن دشوار باشد.
• نسخه API. نشانی‌های وب نقطه پایانی در صورت استفاده داخلی یا همراه با سایر برنامه‌ها نباید باطل شوند.
• زمان پاسخگویی طولانی و داده های بیش از حد. مقدار منابع برگشتی می تواند در طول زمان افزایش یابد و بار و زمان پاسخ را افزایش دهد.
• مسیرهای ناوبری و مکان های ورودی کاربر. از آنجایی که REST از مسیرهای URL برای پارامترهای ورودی استفاده می کند، تعیین فضاهای URL می تواند چالش برانگیز باشد.
• امنیت. مسائل امنیتی زیادی برای مدیریت وجود دارد، مانند استفاده از HTTPS، مسدود کردن دسترسی از آدرس‌های IP ناشناخته و دامنه‌ها، اعتبارسنجی URL، مسدود کردن بارهای غیرمنتظره بزرگ، نظارت و ثبت درخواست‌ها، و بررسی خرابی‌ها.
• احراز هویت. این امر مستلزم آگاهی و استفاده از روش‌های رایج احراز هویت مانند احراز هویت پایه HTTP است که امکان استفاده از نام کاربری و رشته رمز عبور کدگذاری شده با base64 را فراهم می‌کند، کلیدهای API؛ JSON Web Tokens. و سایر نشانه های دسترسی مانند OAuth 2.0 که برای کنترل دسترسی مناسب است.
• درخواست ها و داده ها. درخواست‌ها ممکن است داده‌ها و فراداده‌های بیشتری نسبت به نیاز داشته باشند، یا ممکن است برای به‌دست آوردن همه داده‌ها به درخواست‌های بیشتری نیاز باشد. API ها را می توان برای این تنظیم کرد.
• کدهای خطا و پیام ها. یک روش معمول استفاده از کدهای خطای استاندارد HTTP است. مدیریت خطا ممکن است نتواند تشخیص دهد که آیا یک پاسخ علاوه بر تجزیه بدنه یا بررسی خطا، موفق است یا خیر.
• تست API. ممکن است یک فرآیند طولانی برای راه اندازی و اجرا باشد. هر بخش از فرآیند می تواند چالش برانگیز باشد. آزمایش همچنین می تواند در خط فرمان با ابزار URL مشتری (cURL) انجام شود. چالش‌های مرتبط با تست شامل راه‌اندازی اولیه، به‌روزرسانی‌های طرحواره، ترکیب‌های پارامترهای آزمایشی، ترتیب‌دهی فراخوان‌های API، اعتبارسنجی پارامترهای تست و یکپارچه‌سازی سیستم است.

بهترین شیوه های REST API

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

• از اسم ها در مسیرهای نقطه پایانی استفاده کنید. در جایی که یک REST API قبلاً از یک فعل مانند GET یا PUT برای تشکیل یک درخواست استفاده می‌کند، منبعی که به آن دسترسی پیدا می‌شود باید از تعیین اسم استفاده کند، مانند GET/datasource یا POST/articles. این امر تشکیل درخواست را برای طراحان بصری تر می کند.
• از یک قالب داده به خوبی تثبیت شده استفاده کنید. JSON رایج ترین و محبوب ترین فرمت داده برای بارهای REST API است. همچنین این فرمت پیش فرض برخی زبان های برنامه نویسی محبوب مانند جاوا اسکریپت است.
• از مدیریت دقیق خطا استفاده کنید. مطمئن شوید که مدیریت کامل خطا را در پاسخ‌های REST API لحاظ کرده و از کدهای پاسخ HTTP استاندارد برای نشان دادن نوع خطا استفاده کنید. این کمک می کند تا اطمینان حاصل شود که خطاها برنامه مشتری یا سرور را خراب نمی کنند و می توان آنها را به سرعت درک و اصلاح کرد.
• محدود کردن مجموعه داده ها. از فیلتر کردن، مرتب‌سازی و سایر تکنیک‌های دسترسی به داده‌ها برای محدود کردن یا کاهش حجم داده‌هایی که می‌توانند به مشتری بازگردانده شوند، استفاده کنید. تلاش برای انتقال مجموعه داده های عظیم می تواند API را مختل یا خراب کند. API را طوری طراحی کنید که فقط حداقل داده های درخواستی را درخواست و ارسال کند.
• امنیت را حفظ کنید. REST API را طوری طراحی کنید تا از احراز هویت و رمزگذاری به عنوان روش‌های استاندارد استفاده کند. امنیت جامع باید حتی برای API های عمومی با استفاده از داده های در دسترس اعمال شود.
• تا جایی که ممکن است از کش استفاده کنید. REST API از کش در سمت سرور و کلاینت پشتیبانی می کند. استفاده از حافظه نهان در سمت سرور، زمان پاسخگویی سرور را در هنگام دریافت درخواست مکرر سرعت می بخشد. استفاده از کش در سمت کلاینت به این معنی است که داده ها از قبل روی کلاینت هستند و اصلاً نیازی به برقراری تماس API نیست. در هر دو مورد، عملکرد API بهبود می یابد.

REST در مقابل SOAP

REST و Simple Object Access Protocol روش های مختلفی را برای فراخوانی یک وب سرویس ارائه می دهند. REST یک سبک معماری است، در حالی که SOAP یک مشخصات پروتکل ارتباطی استاندارد را برای تبادل پیام مبتنی بر XML تعریف می کند. برنامه های REST می توانند از SOAP استفاده کنند.

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

SOAP به کد لوله کشی کمتری نیاز دارد - کد زیرساختی سطح پایین که ماژول های کد اصلی را به هم متصل می کند - نسبت به طراحی خدمات REST. زبان توصیف خدمات وب مجموعه‌ای از قوانین را برای تعریف پیام‌ها، پیوندها، عملیات و مکان‌های سرویس توصیف می‌کند. خدمات وب SOAP برای پردازش و فراخوانی ناهمزمان مفید هستند. تشریفات ساختار یافته موجود در SOAP اغلب برای یکپارچه‌سازی‌های نرم‌افزاری پیچیده در سطح سازمانی و گردش‌های کاری که ممکن است طراحی یک REST API مشابه را تحت تأثیر قرار دهد، مناسب‌تر است.

REST و SOAP هر دو روش های مفید و موثر برای ساخت API هستند. انتخاب بین آنها به هدف و ویژگی های مورد نظر API بستگی دارد.

تاریخچه API های RESTful

قبل از REST، توسعه دهندگان از SOAP برای ادغام APIها استفاده می کردند. برای برقراری ارتباط، توسعه دهندگان یک سند XML را با یک درخواست رویه از راه دور در بدنه آن می نوشتند. سپس آنها نقطه پایانی را مشخص می کردند و پاکت SOAP خود را به نقطه پایانی ارسال کردند.

در سال 2000، Roy Fielding و گروهی از توسعه دهندگان تصمیم گرفتند استانداردی ایجاد کنند تا هر سروری بتواند با هر سرور دیگری ارتباط برقرار کند. او REST را تعریف کرد. قوانین جهانی REST ادغام نرم افزار را برای توسعه دهندگان آسان تر می کند.

Salesforce اولین شرکتی بود که API RESTful را به عنوان بخشی از بسته اینترنت به عنوان یک سرویس خود در سال 2000 فروخت. با این حال، تعداد کمی از توسعه دهندگان قادر به استفاده از XML API پیچیده بودند. سپس eBay یک REST API ساخت که بازار خود را به هر سایتی که بتواند به API آن دسترسی داشته باشد گسترش داد. این مورد توجه غول تجارت الکترونیک دیگری را به خود جلب کرد و آمازون API خود را در سال 2002 اعلام کرد.

فلیکر RESTful API خود را در آگوست 2004 راه اندازی کرد و به وبلاگ نویسان اجازه داد به راحتی تصاویر را در سایت ها و فیدهای رسانه های اجتماعی خود جاسازی کنند. فیس بوک و توییتر هر دو API های خود را در سال 2006 منتشر کردند و تحت فشار توسعه دهندگانی که سایت ها را خراش دادند و "API های فرانکشتاین" را ایجاد کردند، خم شدند. هنگامی که خدمات وب آمازون در سال 2006 به راه اندازی ابر کمک کرد، توسعه دهندگان می توانستند در عرض چند دقیقه با استفاده از REST API AWS به فضای داده دسترسی پیدا کنند. درخواست برای APIهای عمومی به سرعت افزایش یافت.

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

منبع: techtarget.com