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

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

REST مخفف Representational State Transfer می‌باشد. REST فقط یک سری از دستور العمل‌ها و سبک‌های معماری است که برای انتقال داده‌ها استفاده می‌شوند. این عموما در مورد اپلیکیشن‌های تحت وب کاربرد دارد؛ ولی می‌تواند داده‌ها را به سایر برنامه‌ها نیز ارسال کند.

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

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

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

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

بیشتر بدانید

کلمه API نیز مخفف Application Programming Interface می‌باشد که به روش های اتصال به سایر کتابخانه ها و برنامه ها اطلاق می‌شود. ویندوز API های مختلفی دارد ، تویتتر نیز یک API وب دارد که البته کارهای مختلفی را با هدف‌های متفاوت از هم انجام می‌دهند. ادامه در این لینک کلیک کنید.

معماری 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 ها در دنیای واقعی هستند که می توان آنها را مطالعه کرد:

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

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

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

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

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

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

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

1 2	$ /tweet/15032934882934 $ /tweets/15032934882934

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

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

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

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

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

منابع بیشتر

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

کتاب‌ها

مقالات