وب سرویس RESTful چیست؟

RESTful روشی برای ایجاد، خواندن، آپدیت نمودن و یا حذف اطلاعات بر روی سروری است که از HTTP call های ساده استفاده می کنند. در واقع REST یک مدل طراحی برای برنامه های شبکه ای می باشد که ارتباط بین دو سیستم (client-server) را توسط یک پروتکل (مانند http، smtp، ftp و …) ایجاد می کند. برنامه های بر پایه این روش/معماری، ReSTful application نامیده می شوند، چرا که فقط با request های CRUD (مخفف create update read delete) پروتکل واسط، با هدف تعامل برقرار می کنند.

اگر بخواهم جمع بندی کنم، RESTful API ها در واقع API هایی هستند که از معماری REST تبعیت می کنند.

• REST مخفف Representational State Transfer می باشد.
• یک معماری وب سرویس است.
• از HTTP برای انتقال اطلاعات میان کلاینت و سرور استفاده میکند.
• کار کردن با REST بسیار ساده تر از وب سرویس های پیچیده ای مانند SOAP می باشد.
• یک سرویس به اصطلاح RESTful عموما بر روی پروتکل HTTP  و تمام افعال استاندارد این پروتکل را که توسط مرورگرهای وب قابل درک هستند کار میکند مانند (GET, POST, PUT, DELETE)

معماری REST دقیقا چیست؟

اینجا جایی است که غیر فنی مطرح کردن جزئیات کمی سخت است. ما اینجا یک سری ثابت های معماری در REST داریم ، مثل :

• ثبات (Consistency) در کل ساختار API
• موجودیت مستقل (Stateless existence) . مثلا عدم وابستگی به session های سمت سرور
• استفاده از کدهای وضعیت HTTP در جای مناسب
• استفاده از نقاط پایانی URL با سلسله مراتب منطقی
• نسخه بندی (Versioning) در URL به جای درخواست HTTP

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

REST یک متدولوژی یا روش شناسی سبُک است که آن را برای انتقال داده های HTTP مناسب می‌کند. این همان علتی است که REST را در وب انقدر محبوب کرده است و انقدر از طرف عموم به عنوان بهترین روش پیاده سازی API شناخته می‌شود.

همانطور که Vinay Sahni گفته است: “یک API ،رابط کاربری توسعه دهنده است.” همه چیز باید به راحتی قابل استفاده باشد و یک تجربه کاربری خوب را فراهم کند. هدف RESTful API ها همین است.

شرایط لازم معماری REST

• کلاینت سرور (client-server) باشد.
• بدون حالت (stateless) باشد.
• قابلیت cache داشته باشد.
• سیستم لایه‌بندی شده  داشته باشد.
• واسط یکنواخت  داشته باشد.
• دارای قابلیت کد در صورت نیاز  باشد.

از لحاظ رویکرد، برنامه نویسی REST جایگزینی ساده برای سرویس‌های وب است.

توسعه‌پذیری در تعاملات میان اجزا، عمومیت واسط‌ها، توسعه‌ی مستقل اجزا و استفاده از واسطه‌ها  از کلیدی‌ترین اهداف معماری REST می‌باشد؛ و همچنین، استفاده از معماری REST در برنامه‌نویسی، کارایی، سادگی، انعطاف‌پذیری، امکان مشاهده و نظارت، قابلیت حمل و قابلیت اطمینان را افزایش می‌دهد.

مشخصات یک وب سرویس REST

• بوسیله‌ی URI کار می‌‌کند یعنی ریسورس‌ها و کالکشن‌های خود را به صورت https://fullkade.com/resources دریافت می‌کند.
• اطلاعات را به صورت عموما JSON دریافت می‌کند؛ البته می‌تواند اطلاعات به صورت XML و … هم برگردانده شود.
• برخلاف وب سرویس های بر پایه‌ی SOAP ، هیچ استاندارد رسمی برای وب سرویس‌های REST وجود ندارد؛ به دلیل این‌که REST یک معماری است؛ در حالی که SOAP یک پروتکل وب سرویس است.

نکاتی مهم برای RESTful API ها

API User یک توسعه دهنده وب است که می تواند برنامه‌هایی برای اتصال به سرور خارجی API بنویسد و اطلاعات ضروری روی HTTP به او برگشت داده شوند. توسعه دهنده وب سپس می‌تواند اطلاعات را در سایت خود نمایش دهد بدون دسترسی شخصی به سرور خارجی API.

در کل از چهار دستور برای دسترسی به RESTful API استفاده می شود:

GET برای گرفتن یک شی
POST برای ایجاد یک شی
PUT برای ویرایش یا بازنویسی یک شی
DELETE برای حذف یک شی

با هر بار فراخوانی API، یکی از این متدها باید به سرور پاس داده شود تا سرور بداند چطور باید رفتار کند.

اکثریت قریب به اتفاق وب API ها فقط درخواست های GET را اجازه می‌دهند تا بتوان دادهها را از سرور دریافت کرد. احراز هویت کاربر اختیاری است ولی شدیدا ایده خوبی است وقتی که پای متدهای حساس و دارای قابلیت خرابکاری مثل PUT و DELETE درمیان باشد.

با این حال بسیاری از RESTful API ها تا این حد پیش نمی‌روند. Pokéapi را در نظر بگیرید که یک API رایگان برای بازی Pokéapi است. این API برای عموم باز است ولی با یک نرخ محدودیت معقول و مناسب (محدودیت کاربران برای تعداد معینی از ارسال درخواست به API در یک بازه زمانی مشخص) . به علاوه این API فقط متدGET را پشتیبانی می کند.شاید این را بتوان اصطلاحا یک API مصرفی نامید.

نوع داده بازگشتی نیز مهم است و باید با همه‌ی منابع دیگر همگن و هماهنگ باشد. JSON یکی از انوع داده بازگشتی می‌باشد که بسیار نیز محبوب است و جزئیات آنلاین آن نیز ساختار داده در آن را به خوبی توضیح داده است.

RESTful API ها از “اسم” برای نامگذاری اشیا و از “صفت” برای نامگذاری کارهایی که قرار است روی اشیا انجام شود استفاده می‌کند. اعتبارسنجی می‌تواند بخشی از این باشد؛ همچنین نرخ محدودیت؛ ولی یک API کوچک و ساده لازم نیست نگران ایجاد محدودیت برای کاربران باشد.

دسترسی به منابع API

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

دقت کنید که داده‌ی بازگشتی از طرف API می‌تواند به صورت کلی بوسیله‌ی متدهای HTTP تغییر یابد. برای مثال، GET داده‌ها را دریافت کند، ولی POST اطلاعات جدیدی ایجاد کند. بر همین اساس، درخواست می‌تواند به آدرس یکسانی از API ارسال شود ولی نتیجه می‌تواند بسیار متفاوت باشد.

مشاهده‌ی نمونه‌های مشابه آنلاین ممکن است به شما برای درک بهتر مفاهیم کمک کند. ما قبلا در مورد Pokeapi صحبت کردیم ولی بعضی دیگر از نمونه API ها در دنیای واقعی هستند که می توان آنها را مطالعه کرد:

• Reddit API
• GitHub API
• Flickr API
• Pinterest API

API خودتان را بسازید

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

اما اجازه دهید به برخی از اصول ساده معماری API ها نگاهی بیندازیم.

نقاط پایانی کار را ایجاد کنید

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

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

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

در این مورد به نظرم اسم مفرد بهتر است. مخصوصا وقتی یک منبع قرار است برگشت داده شود (توییت).
ولی جواب ۱۰۰٪ قطعی و مستندسازی شده‌ای برای این سوال وجود ندارد و بهتر است شما با توجه به پروژه‌ی خودتان، بهترین اسم را انتخاب کنید.

تنظیم نوع داده برگشتی

مورد دیگری که توجه خاصی می طلبد، نوع داده‌ی برگشتی از API است. خیلی از کاربران وب از API انتظار دریافت داده از نوع JSON را دارند؛ پس این بهترین گزینه می تواند باشد.
XML یکی از گزینه‌های دیگر است؛ اگر می‌خواهید، می‌توانید هر دو را در اختیار کاربران قرار دهید. اما با این حال، اساسی‌ترین گزینه همان JSON است که صحبتش را کردیم.

جزپیات زیادی در مورد طراحی API ها وجود دارد. من پیشنهاد می‌کنم شما ابتدا با API های دیگر مثل Instagram,Twitter, Linkedin و … بازی کنید تا ببینید دیگر توسعه دهندگان چگونه API هایشان را می‌سازند و این‌گونه با روش‌های مرسوم این حوزه بیشتر آشنا خواهید شد.

اگر می‌خواهید شروع کنید، می‌توانید از این منابع استفاده و کدهایش را تغییر دهید :

• REST API Tutorial Site
• Writing a Simple REST API
• Building a RESTful Web Service

منابع بیشتر

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

کتاب ها

• REST API Design Rulebook
• RESTful Web APIs
• RESTful Web Services Cookbook
• Undisturbed REST: A Guide to Designing the Perfect API

مقالات

• A Beginner’s Guide to HTTP and REST
• Creating a RESTful API
• RESTful Resource Naming Guide
• Creating A REST API using the MEAN Stack

برگرفته از: hongkiat به نقل از fotolia