RESTful
RESTful چیست ؟ وب سرویس RESTful (یا REST مخفف Representational state transfer) روشی برای ایجاد، خواندن، آپدیت نمودن و یا حذف اطلاعات بر روی سروری است که از HTTP call های ساده استفاده می کنند. در واقع REST یک مدل طراحی برای برنامه های شبکه ای می باشد که ارتباط بین دو سیستم (client-server) را توسط یک پروتکل (مانند http، smtp، ftp و …) ایجاد می کند. برنامه های بر پایه این روش/معماری، ReSTful application نامیده می شوند، چرا که فقط با request های CRUD (مخفف create update read delete) پروتکل واسط، با هدف تعامل برقرار می کنند.
REST مخفف Representational State Transfer می باشد .
یک معماری وب سرویس است.
از HTTP برای انتقال اطلاعات میان کلاینت و سرور استفاده میکند.
کار کردن با REST بسیار ساده تر از وب سرویس های پیچیده ای مانند SOAP می باشد.
یک سرویس به اصطلاح RESTful عموما بر روی پروتکل HTTP و تمام افعال استاندارد این پروتکل را که توسط مرورگرهای وب قابل درک هستند کار میکند مانند (GET, POST, PUT, DELETE)
شرایط لازم معماری REST
کلاینت سرور (client-server) باشد.
بدون حالت (stateless) باشد.
قابلیت cache داشته باشد.
سیستم لایه‌بندی شده داشته باشد.
واسط یکنواخت داشته باشد.
دارای قابلیت کد در صورت نیاز باشد.
از لحاظ رویکرد، برنامه نویسی REST جایگزینی ساده برای سرویس‌های وب است.
توسعه‌پذیری در تعاملات میان اجزا، عمومیت واسط ها، توسعه مستقل اجزا و استفاده از واسطه ها از کلیدی ترین اهداف معماری REST می‌باشد و همچنین استفاده از معماری REST در برنامه‌نویسی کارایی، سادگی، انعطاف‌پذیری، امکان مشاهده و نظارت، قابلیت حمل و قابلیت اطمینان را افزایش می دهد.
مشخصات یک وب سرویس RESTful
بوسیله URI کار می کند یعنی ریسورس ها و کالکشن های خود را به صورت http://netparadis.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émon است. این API برای عموم باز است ولی با یک نرخ محدودیت معقول و مناسب (محدودیت کاربران برای تعداد معینی از ارسال درخواست به API در یک بازه زمانی مشخص) . به علاوه این API فقط متدGET را پشتیبانی می کند.شاید این را بتوان اصطلاحا یک API مصرفی نامید
نوع داده بازگشتی نیز مهم است و باید با همه منابع دیگر همگن و هماهنگ باشد.JSON یکی از انوع داده بازگشتی است که بسیار نیز محبوب است و جزئیات آنلاین آن نیز ساختار داده در آن را به خوبی توضیح داده است.
RESTful API ها از “اسم” برای نامگذاری اشیا و از “صفت” برای نامگذاری کارهایی که قرار است روی اشیا انجام شود استفاده می کند. اعتبارسنجی می تواند بخشی از این باشد همچنین نرخ محدودیت.ولی یک API کوچک و ساده لازم نیست نگران ایجاد محدودیت برای کاربران باشد.
دسترسی به منابع API
API های عمومی معمولا از طریق آدرس های وب سایت در دسترس هستند.این به این معنی است که ساختار آدرس (URL) مهم است و فقط بای دبرای API استفاده شود تا تداخلی بین آدرس ها نباشد.بعضی از API های می توانند برای نسخه های بروز شده خود ، یک پیشوند به آدرس اضافه کنند مثلا /v2/ . این روش برای توسعه دهندگانی است که نمی خواهد نسخه قبلی API شان منقرض شود و می خواهند در عین حال که نسخه قبلی قابل استفاده است ، به کاربران امکان استفاده از نسخه جدید را نیز بدهند.
برای اطلاعات بیشتر در این زمینه من این مطلب را دوست داشتم که در مورد ساختار ساده URL توضیحاتی داده است و چند مثال نیز از سرویس های دیگر آورده است.
دقت کنید که داده بازگشتی از طرف API می تواند به صورت کلی بوسیله متدهای HTTP تغییر یابد.برای مثال GET داده ها را دریافت کند ولی POST اطلاعات جدیدی ایجاد کند.بر همین اساس درخواست می تواند به آدرس یکسانی از API ارسال شود ولی نتیجه می تواند بسیار متفاوت باشد
API خودتان را بسازید
مراحل ایجاد یک API برای خودتان نمی تواند خیلی راحت باشد ولی آنقدر ها هم که فکر می کنید سخت و پیچیده نیست. فقط نیاز به آشنایی با الگوهای طراحی API و انتخاب بهترین روش ها دارید تا چیزی را بسازید که ارزش واقعی داشته باشد. هر API باید به سرور شما وصل شود تا داده ها را برگشت دهد. شما نه تنها نیاز به کدنویسی برای انجام این کار دارید بلکه باید داده های برگشتی را فرمت دهی کنید (مثلا به JSON). دیگر نیازمندی های بالقوه شامل اعتبارسنجی (Authentication) و اعمال محدودیت های مختلف برای امنیت و پایداری بیشتر می شود
نقاط پایانی کار را ایجاد کنید
یکی از جنبه های ایجاد API ایجاد نقاط پایانی در ساختار URL است . وقتی دارید منابع (Resources) را ایجاد کنید نیاز دارید تا از اسم استفاده کنید نه از صفت. این به این معنی است که داده های API باید به صورت شخص, مکان و یا چیزی برگشت داده شوند. اغلب هم چیزی با خصیصه های معین (مثلا یک توییت با همه متادیتا هایش).
یادگیری اسم گذاری مثل روش فوق شاید سخت باشد ولی یکی از جنبه های حیاتی طراحی API هاست.ساده سازی هر زمانی که ممکن باشد بهترین راه است .
یکی از نقاط بحث برانگیز استفاده از اسم های مفرد یا اسم های جمع است.
- برچسب ها:
- api
- api rest
- معماری rest
- معماری رست