يکپارچه سازي(Integration)
سرويس مارکتينگ اتوماسيون zebline در قسمت يکپارچه سازي، اين امکان را براي شما فراهم مي نمايد تا بتوانيد از API هاي موجود در زبلاين استفاده کرده و اطلاعات کاربران و خصوصیات آن ها، رویداد های انجام شده توسط کاربران، محصولات ثبت شده و رویداد های محصولات خود را رديابي کنید. از طرفي، در اين قسمت، تمامي اسناد و API های مورد نیاز جهت يکپارچه سازي(Integration) و همچنین لاگ های رویدادها و محصولات قابل دسترس می باشند.
API چیست؟
API یا رابط برنامهنویسی کاربردی (Application Programming Interface) مجموعهای از توابع است که به برنامه ها امکان دسترسی به داده ها و تعامل با اجزای نرم افزار خارجی، سیستم عامل ها یا سرویسهای خرد را میدهد. مشخص میکند که یک نرمافزار چطور با جهان خارج ارتباط برقرار کند. شرکتی که نرمافزاری را تولید میکند باید یک رابط کاربری برای آن طراحی کند تا سایر افراد بدون دانش برنامهنویسی بتوانند با آن نرمافزار ارتباط برقرار کنند و حتی فراتر از آن، به گونهای ارتباط برقرار کنند که خواستههایشان را از نرمافزار بگیرند بدون اینکه نیازی باشد طرز کار آن را بدانند.
به عبارتي، API، مجموعهای از پروتکلهایی است که به منظور ساخت و یکپارچهسازی نرمافزار استفاده میشود و اجازه میدهد تا محصول یا خدمات شما با سایر محصولات و خدمات دیگر، ارتباط برقرار کند بدون اینکه بداند چطور آن ها برنامهنویسی شدهاند. این امر میتواند توسعه برنامه، صرفهجویی در وقت و هزینه را برای شما آسان کند. هنگامی که محصولات و نرم افزارهای جدیدی را طراحی کرده و آن ها را مدیریت میکنید، API به شما انعطافپذیری و آزادی عمل میدهد و فرصت هایی برای ایده های جدید فراهم میکند.
در تعريف ديگر، API، واسطهای نرمافزاری است که برای کاربرد خاصی طراحی شده است و به دو برنامه اجازه میدهد تا با یکدیگر ارتباط داشته باشند. هر بار که از یک برنامه مثل اینستاگرام استفاده میکنید یا یک پیام ارسال میکنید و یا حتی وضعیت تلفن خود را بررسی میکنید، در حقیقت از یک API استفاده میکنید. این اتفاق هر روز، بارها و بارها توسط هر یک از کاربران اتفاق میافتد. به عنوان مثال به هنگام خرید آنلاین از فروشگاه اینترنتی، با کلیک روی آيکون "افزودن به سبد خرید"، پاسخی به سیستم ارسال میشود که در ازای آن، سیستم به شما اعلام میکند که محصول مورد نظر به سبد خرید شما اضافه شده است و سبد خرید شما به روز میشود.
انواع API:
API ها انواع مختلفی دارند که میتواند مورد استفاده کسب و کارها یا توسعهدهندگان نرمافزار قرار بگیرد. چهار نوع اصلی از API ها که معمولاً در وب اپلیکیشن ها استفاده میشود عبارتند از:
- API هاي عمومي/ باز(Open API):
علت نام گذاری این نوع API ها این است که جهت استفاده عموم افراد و کسب و کارها در دسترس هستند. از نمونه این نوع API ها، میتوان به OAuth API گوگل اشاره کرد.
- API هاي خصوصي/ داخلي(Internal API):
این نوع API ها با هدف استفاده در سیستمهای داخلی کسب و کارها توسعه داده میشوند و تنها در دسترس کارکنان سازمان هستند. با استفاده از API های داخلی، سازمان ها میتوانند نرمافزارها و سیستم های خود را به یکدیگر متصل کرده و به تبادل داده ها میان آن ها بپردازند.
- API هاي مشارکتي(Partner API):
این نوع API ها در دسترس عموم قرار ندارد و دسترسی به آن ها نیازمند امتیازات یا مجوزهای خاصی است. کاربرد اصلی این نوع API برای تبادل اطلاعات میان کسب و کارهاست. به عنوان مثال، یک کسب و کار میتواند برخی از اطلاعات مشتریان خود را با استفاده از این ابزارها در اختیار تبلیغ کنندگان قرار دهد.
- API هاي ترکيبي(Composite API):
این نوع API ها جهت انجام عملیات های متوالی، چندین API را با هم ترکیب کرده و اطلاعات گوناگون آن ها را به اشتراک میگذارند.
API های عمومی، ارزش تجاری منحصر به فردی دارند، به اين دليل که میتوانند چگونگی اتصال شما با شرکای خود و همچنین کسب درآمد بالقوه از سایر داد هها را سادهتر کرده و آن ها را گسترش دهند. API گوگل مپ یک نمونه محبوب به حساب میآید.
نمونه هاي API:
امروزه API ها در نرمافزارها و سرویسهای نرمافزاری متعددی مورد استفاده قرار میگیرند و به توسعه دهندگان کمک میکند تا اطلاعات را با سرعت هرچه بیشتر به مصرفکنندگان برساند. برخی از نمونههای رایج و عمومی این API ها عبارتند از:
- API براي تراکنش هاي مالي:
بسياري از وب سایت های اینترنتی و سرویسهای نرم افزاری در راستای ارائه خدمات خود یا جهت فروش یک محصول، نیازمند ساز و کاری برای پردازش تراکنشهای مالی هستند. طرفین این تراکنش برای این که بتوانند از خدمات پرداخت اینترنتی و پردازش تراکنشهای مالی سایر شرکت ها استفاده کنند، ناچار به انتقال اطلاعات تراکنش خود به این شرکت ها هستند. این مورد یکی از نمونههای رایج استفاده از API است که به شما اين امکان را میدهد تا انتقال دادههای مربوط به تراکنشهای مالی را با امنیت بالا انجام دهید.
- API براي مقايسه قيمت ها:
سرویس های اینترنتی متعددی وجود دارند که کار اصلی آن ها مقایسه قیمت اجناس یا خدمات مختلفی است که از سوی سایر شرکت ها ارائه میشود. برای ارائه این خدمت، آن ها نیاز دارند تا اطلاعات قیمت ها را به صورت بروزشده، از تعداد بسیار زیادی شرکت و فروشنده دریافت کنند. از اين رو، جهت دریافت این اطلاعات به شکلی بهینه، از API استفاده مي کنند.
- API براي قيمت گذاري پويا
قیمت گذاری پویا به معنای تعیین منعطف قیمت ها با در نظر داشتن شرایط مختلف است. به طور مثال، کسب و کارهای مبتنی بر تاکسی آنلاین با در نظر داشتن مسافت، وضعیت آبوهوا، سطح ترافیک، ساعت درخواست و تعداد رانندگان، قیمتهای متغیری را برای مشتریان تعیین میکنند. بهینهسازی قیمتها، تجزیه و تحلیل قیمت و امکان ایجاد مقایسه بین قیمتها، کاربردهای اصلی این نوع از APIهاست. به عبارتي، تمامي روند ارسال درخواست تاکسی، مشخص کردن مبدأ و مقصد، تعیین نرخ، ارسال درخواست به نزدیک ترین رانندگان تا رسیدن به مقصد، توسط API ها صورت میگیرد. تصور کنید که چه حجمی از اطلاعات در سریعترین زمان ممکن جابجا میشوند تا شما بتوانید تنها در چند دقیقه، سرویس تاکسی آنلاین خود را دریافت کنید.
- API براي نمایش اطلاعات محصولات
با استفاده از این API، شما مي توانيد صفحات مربوط به محصولات را به طور مستقيم به درگاه یکی از بانک ها وصل کنید. هدف از این رابط ها، به اشتراک گذاشتن اطلاعات گسترده در مورد هر یک از محصولات است. این قابلیت به کسب و کارها و فروشگاه های آنلاین کمک میکند تا تصاویر برند، توضیحات محصول، ویژگی ها و عناوین مرتبط با هر یک را به صورت کامل به مخاطبان نمایش دهد و امکان پرداخت را ایجاد کند.
- API براي جست و جو در سایت
با استفاده از این API، شما مي توانيد محصولات مورد نیاز خود را در سريع ترين زمان ممکن، در سایت پیدا کنيد. اغلب سایت های بزرگ با طراحی جست و جوی پیشرفته، باعث بهبود تجربۀ مشتریان از خرید میشوند.
- API براي شخصیسازی محتوا
یکی از بهترین مزیت های APIها، امکان شخصیسازی محتوا براساس نیاز کاربر است. به این ترتیب که نیاز هر مشتری را در نظر گرفته و هر آنچه لازم است را برای او به نمایش میگذارد. این قابلیت، اغلب به صورت خودکار انجام میشود. به طور مثال، در صفحۀ Explore اینستاگرام، اغلب محتواهایی که مورد پسند کاربران است به نمایش درمیآید. همچنین در فروشگاه های آنلاین نیز، کالاهایی که بیشتر مورد علاقۀ خریداران مختلف است را، نمایش میدهد.
- API براي اتوماسیون فرآیند مارکتینگ
این قبیل از APIها به منظور خودکارسازی و ایجاد اتوماسیون در کسب و کارهای مبتنی بر فروش آنلاین است. به طور مثال، مي توانند به صورت خودکار، مشتریان مختلف وب سایت را در گروه بندی های مختلف قرار دهند که اين کار از طریق تجزیه و تحلیل سفارشات و بر اساس کالاهای خریداری شده انجام میشود.
- API براي تجزیه و تحلیل سایت
ابزارهای تجزیه و تحلیل سایت، روند مهمی را در ارتقای وب سایت ها طی میکنند. مدیران سایت ها با استفاده از چنین APIهایی قادر به شناسایی نقاط ضعف و قوت وب سایت خود خواهند بود.
- API براي شبکههای اجتماعی
اکثر کسب و کارهاي امروزي، از شبکههای اجتماعی جهت معرفی برند یا فروش محصولات خود، استفاده میکنند. اين قبيل از API ها، ابزارهایی قدرتمند برای بازاریابی محصولات به حساب میآیند که متداولترین آن، توزیع محصولات از طریق شبکه های اجتماعی است. به عنوان مثال، آیکون های به اشتراکگذاری محتوا در شبکههای اجتماعی. شاید محصول جالبی را در یک فروشگاه آنلاین ببینید و بخواهید آن را سریعاً به یکی از دوستان خود معرفی کنید. این کار، تنها با یک کلیک روی آيکون شبکۀ اجتماعی مورد نظر انجام خواهد شد.
چرا کسب و کارهای آنلاین، مي بايست از API استفاده کنند؟
API، طیف وسیعی از خدمات را به خود اختصاص داده است. کسب و کارهای آنلاین بیشترین استفاده را از آن دارند. خریدهای اینترنتی، درخواست های آنلاین و شبکه های اجتماعی بیش از هر زمان دیگری توسعه یافته اند.
API، مزایای مهمی برای سایت های تجارت الکترونیک داشته است که برخي موارد آن به شرح ذيل است:
تامین امنيت با API: استفاده از API برای سایت ها موجب امنیت بیشتر آن ها میشود، به اين دليل که، کاربران، اطلاعات کمتری را ارسال میکنند و در ازای آن، خطر افشاي داده های آنان به حداقل میرسد.
افزایش سرعت با API: استفاده از API موجب میشود تا سرعت تبادل اطلاعات بین کاربر و سیستم و متقابلا بین سرور و کاربر، به شکل قابل توجهی افزایش یابد.
مقیاس پذیری بیشتر با API: اغلب طراحی API به این صورت است که انعطاف و مقیاسپذیری بالایی برای هماهنگی و اجرای کارکرد های مختلف دارد. بنابراین میتواند شکل خاصی به خود بگیرد.
چرا به رابط برنامهنویسی کاربردی(API) نیاز داریم؟
اکثر شرکت ها، سرویس ها و برنامه های مختلف جهت هماهنگ سازی و دسترسی آسان، به رابط برنامه نویسی کاربردی (API)، روي میآورند. بدون API، چرخه عملکرد بسیاری از سرویسها از کار میافتد یا حداقل ناقص عمل میکند. به عنوان مثال، در صورتي که API ها، در اتصال به درگاه های پرداخت، وجود نداشتند، عملا فروشگاه های اینترنتی نيز، رونق خود را از دست می دادند. علاوه بر اين، نیاز به اشتراک گذاری مقدار زیادی از داده ها در بخش های مختلف و با افراد و سیستم ها، موجب شد تا موضوع API ارائه شده و مورد توجه عموم قرار گرفت. API در ابتدایی ترین اقدام خود، به عنوان یک درب یا پنجره به یک سرویس یا همان برنامه نرمافزاری، عمل کرده و به سایر برنامه ها، اين مکان را مي دهد تا بدون نیاز به یک توسعه دهنده جهت به اشتراک گذاشتن کل کد خود، با آن ارتباط برقرار کنند.
به دلیل وجود APIهایی نظیر توئیتر، فیسبوک، تلگرام و نظیر این هاست که کاربران به راحتی و بدون دردسر از طریق تلفن همراه خود و هزاران بخش دیگر به داده های خود دسترسی دارند و میتوانند آن ها را ویرایش، ایجاد و یا حذف کنند.
به طور خلاصه، API ها این امکان را به شما میدهند که ضمن حفظ امنیت و کنترل، بتوانید دسترسی به منابع خود را باز کنید. تمام امنیت API، در مورد نحوه مدیریت خوب آن است. اتصال به APIها را میتوان با ایجاد برنامه هایی که داده یا عملکردی را با استفاده از همین API ها در معرض مصرف قرار گرفتند، با یک پلت فرم ادغام شده توزیعکننده که همه چیز را به هم متصل میکند، انجام داد.
API چگونه کار میکند؟
API يا همان رابط برنامهنویسی کاربردی، به یک توسعه دهنده اين امکان را مي دهد تا جهت ارسال یا دریافت اطلاعات، "تماس" یا "درخواست" خاصی برقرار کند. این ارتباط با استفاده از یک زبان برنامه نویسی به نام JSON انجام میشود. همچنین میتواند برای انجام یک عمل تعریف شده مانند به روزرسانی یا حذف داده ها مورد استفاده قرار گیرد.
چهار روش درخواست اصلی وجود دارد که میتوان با API انجام دا و داده ها را مديريت نمود:
- GET: اطلاعات را واکشي میکند. (مثال: واکشي اطلاعات تمامي کدهای کوپن)
- PUT: اطلاعات را به روز رساني میکند. (مثال: به روزرسانی قیمت گذاری محصول)
- POST: اطلاعات جديد را درج و ثبت میکند. (مثال: ایجاد یک گروه جدید محصول)
- DELETE: اطلاعات را حذف مي کند. (مثال: حذف یک پست وبلاگ)
JSON چیست و به چه دليل از آن استفاده میشود؟
JSON(JavaScript Object Notation)، جهت نمایش داده ها در یک سرور استفاده میشود. خواندن آن توسط انسان و درک آن برای ماشینآلات و برنامه ها آسان است. این زبان قابل درک است زیرا در جفت کلید یا مقدار، با کلید در سمت چپ و مقدار در سمت راست، تولید میشود. کلیدها یک شیء ثابت هستند که توسط برنامه تعریف شدهاند.در حالی که مقادیر منحصر به فرد خواهند بود.
درخواست API چیست؟
برای عملکرد API چندین مولفه وجود دارد که در يک نماي کلي جهت درک بيشتر، بدان اشاره مي شود:
نقطه پایان(EndPoint): به هنگام درخواست API، دو قسمت کلیدی برای یک نقطه پایانی وجود دارد که یکی از آنها، آدرس(URL) و ديگري، مسیر(PATH) است. مسیر، بسته به آنچه که میخواهید به انجام برسانید، متفاوت خواهد بود. زماني که این دو قسمت، کنار هم قرار بگيرد، یک نقطه نهایی کامل بدست میآيد. از طرفي، متغیرها نیز اجزای منحصر به فردی برای یک نقطه پایانی مي باشند و بسته به اطلاعات فروشگاه شما متفاوت خواهند بود. شما میتوانید یک متغیر را با براکتهای باز و بسته "{}" مشاهده کنید.
سرتیتر يا هدر(Header): هدرها اطلاعات را به مشتری و سرور ارائه میدهند.
مثالهای متداول یک سرصفحه، احراز هویت معتبر مانند "Auth Token" يا "Client ID" است. این اعتبارنامه ها هنگام ایجاد حساب API به طور خودکار در اختیار شما قرار میگیرند. هدر دیگری با نام "Content Type" شناخته میشود که به سرور در مورد نوع ارسال محتوا اطلاع میدهد. به عنوان مثال، یک نوع محتوای متداول "application / json" است که به سرور اطلاع میدهد که ما دادههای JSON را ارسال می کنیم.
روش(Method): روشها اقداماتی هستند که هنگام ارسال درخواست انجام میشوند: GET، POST، PUT، DELETE.
دادهها(Body): دادههای درخواست، که معمولاً "body" نامیده میشوند، اطلاعاتی هستند که به سرور ارسال شده یا توسط آن برمیگردند. گاهي اوقات، متن اصلی یک درخواست قبل از تحویل، به اطلاعات خاصی نیاز دارد. به عنوان مثال، درصورتي که شما در حال ویرایش یک محصول هستید، قبل از ایجاد هرگونه تغییر، شناسه محصول، مورد نیاز خواهد بود.
مفهوم پروتکل(Protocol)
پروتکل (اینترنتی)، به سیستمی از قواعد گفته میشود که شیوه تبادل داده ها را در درون یا بین رایانه ها تعریف میکند. ارتباط بین دستگاه ها نیازمند این است که دستگاه ها، روی قالب داده هایی که به مبادله میپردازند، توافق داشته باشند. مجموعه قواعدی که قالب این داده ها را تعریف میکنند، پروتکل نام دارند.
پروتکل HTTP چیست؟
HTTP، پروتکلی است که امکان واکشی منابعی از قبیل سندهای HTML را به شما میدهد.HTTP، مبنای هر نوع مبادله داده روی وب را، تشکیل میدهد و یک پروتکل کلاینت-سرور است، یعنی درخواست ها از سوی گیرنده آغاز میشوند که عموماً یک مرورگر وب است. به این ترتیب یک سند کامل با ترکیب سند های کوچک و جزئی واکشی شده مانند متن، توضیح چیدمان، تصاویر، ویدئوها، اسکریپت ها و موارد دیگر در مرورگر وب بازسازی میشود.
کلاینتها و سرورها از طریق مبادله پیامهای منفرد (بر عکس جریان دادهها) با هم ارتباط میگیرند. این پیامها از سوی کلاینت ارسال میشوند که عموماً یک مرورگر وب است و "درخواست(Request)"، ناميده مي شوند. از طرفي، پیامهایی که از سوی سرور ارسال میشوند، "پاسخ(Response)"، نامیده میشوند.
کلاینت/ مشتري(Client) چیست؟
کلاینت/ مشتري(Client)، شخص يا نرم افزاري است که از API استفاده میکند.
کلاینت میتواند يک توسعه دهنده باشد. به طور مثال، یک شخص به عنوان توسعه دهنده میتواند در برنامه ای که مینویسد API توييتر را برای خواندن و نوشتن داده ها از توییتر، ایجاد یک توییت جدید و کارهای بیشتر به کار گیرد. بنابراین، برنامه آن توسعه دهنده، API توييتر را فراخوانی میکند.
کلاینت میتواند یک مرورگر وب باشد. به طور مثال، زماني که شخصي وب سایت توییتر را باز میکند، مرورگر، کلاینتی است که API توییتر را فراخوانی کرده و از داده های دریافتی جهت پردازش(Render) اطلاعات بر روی صفحه استفاده میکند.
منبع(Resource) چیست؟
یک منبع(Resource)، میتواند هر شیئی باشد که API امکان فراهم سازی اطلاعاتی را در موردش داشته باشد. به عنوان مثال در API اينستاگرام، منبع میتواند یک کاربر، یک عکس یا یک هشتگ باشد. هر منبع دارای یک شناسه منحصربهفرد (Unique Identifier) است. شناسه میتواند یک نام یا یک عدد باشد.
وب سرور(Web Server) چيست؟
سرور، اسناد درخواستی از سوی کاربر را عرضه میکند و مجازاً به صورت یک رایانه منفرد ظاهر میشود، اما ممکن است مجموعهای از سرورها باشند که بار کاری را با هم به اشتراک بگذارند یا یک نرمافزار پیچیده باشد که از رایانههای دیگر که مسئول بخشهای کش، پایگاه داده، یا سرورهای e-commerce پرسوجو کرده و سند را بسته به تقاضا به صورت کامل یا جزء به جزء تولید میکند.
داده ها در اپلیکیشن ها از کجا میآیند ؟
دادههای استفاده شده در اپلیکیشن ها و وب سایت ها از سرور یا همان وب سرورها (Web-Server) دریافت میشوند. بنابراین، کلاینت از طریق API اطلاعات مورد نیاز را از سرور درخواست میکند و سپس، سرور به کلاینت پاسخ لازم را ارسال خواهد کرد. در اینجا، پاسخ ارسال شده به کلاینت در قالب یک صفحه وب HTML است. ارسال داده توسط سرور در قالب HTML مناسب نيست. چرا که کلاینت ترجیح میدهد به جای یک صفحه HTML، دادهها را در یک قالب ساختاریافته (Structured Format) دریافت کند. به همین دلیل است که ارسال داده از سمت سرور در پاسخ به درخواست کلاینت در قالب JSON و يا XML، روش بهتري است.
REST و SOAP چيست؟
در حالی که رابط برنامهنویسی کاربردی از یک سری قوانین خاص پیروی میکند که نحوه ارتباط برنامه ها با یکدیگر را تعیین میکنند، REST و SOAP، نحوه ارائه رابط برنامهنویسی کاربردی را تعریف مینمایند. هر یک از نظر عملکرد شبیه به یکدیگر هستند اما چندین تفاوت کلیدی و موارد استفاده دارند.
REST(Reflection State Transfer): مجموعه قوانینی است که توسعه دهندگان، در هنگام ایجاد API، از آن پیروی میکنند.. یکی از قوانین، این است که رابط برنامهنویسی کاربردی باید به گونهای طراحی شود که کاربري آن آسان و از طرفي برای توسعه دهندگان نيز، منطقی باشد. به طور مثال، عدم رعایت این قانون، داشتن نقطه پایانی محصول "prod_550" به جای فقط "محصولات" است که خود مي تواند باعث شود کار با API آن تقریبا ناخوشایند باشد از طرفي REST، با استفاده از JSON خوانده میشود.
SOAP(Simple Object Access Protocol): یکی دیگر از موارد طراحی شده برای سرویس های وب است. SOAP، یک استاندارد قوی از قوانین، مانند ساختار پیامرسانی و قرارداد ارائه درخواست یا پاسخ را دنبال میکند و از زبانی استفاده میکند که به عنوان زبان علامتگذاری قابل گسترش (XML) شناخته میشود. XML، به گونهای طراحی شده که قابل خواندن توسط ماشین و انسان باشد.
به طور کلي، REST، يک شیوه معماری و یک رویکرد برای مقاصد ارتباطی است که اغلب در توسعه خدمات مختلف وب مورد استفاده قرار میگیرد. شیوه و سبک معماریگونه REST به مصرف پهنای باند کمتر کمک میکند و باعث میشود یک اپلیکیشن برای اینترنت مناسبتر و بهتر باشد. برای درک بهتر، لازم است بررسی عمیقتری انجام شده و نحوه کارکرد یک REST API را شناخت.
وب اپلیکیشن RESTful چیست ؟
یک وباپلیکیشن RESTful از شیوه معماری REST تبعیت کرده و اطلاعات مربوط به خودش را در قالب اطلاعات درباره منابعش ارائه میدهد. همچنین این وباپلیکیشن یا برنامه کاربردی تحت وب، این امکان را برای کلاینت به وجود میآورد تا اقداماتی را در خصوص آن منابع، انجام دهد. این اقدامات میتواند ایجاد منابع جدید (مثال: ایجاد یک کاربر جدید) یا تغییر منابع فعلی (مثال: ویرایش یک پست) و سایر اقدامات از این دست باشد.
RESTful API چيست؟
برای این که یک API با REST مطابقت داشته باشد( به عبارتي، RESTful باشد)، لازم است مجموعه اي از محدودیت ها و قواعد در کد نويسي آن ها، رعایت شود. این مجموعه قوانین، کاربری و استفاده از API را سادهتر میکند و همچنین باعث کشف سریعتر آن API خواهند شد. از اين رو، زماني که یک توسعه دهنده به تازگی شروع به استفاده از آن API میکند، با چالش ها و مشکلات کمتری مواجه خواهد شد.
تفاوت REST و RESTful چیست ؟
REST، یک سبک يا شيوه از معماری نرمافزار است که به بیانی ساده تکنولوژی و پروتکلهای موجود در وب را به کار میگیرد.
RESTful، برای اشاره به وب سرویس هایی به کار گرفته میشود که سبک يا شيوه معماری REST را پیادهسازی میکنند.
در حقيقت، پسوند "ful" که به "REST" اضافه شده است، به معناي "داشتن قابلیت" REST يا تطابق داشتن با این سبک معماری است. یعنی این وب سرویس ها یا APIها از سبک و شیوه معماری REST استفاده میکنند.
محدودیت های REST API چه هستند ؟
محدوديت هاي REST API شامل شش اصل است که عبارتند از:
- مستقل از حالت(Stateless)
سرور، چيزي در مورد کاربری که از APIاستفاده میکند، نمیداند. سرور به یاد نمیآورد که آیا کاربر API قبلاً یک درخواست GET برای همان منبع در گذشته دریافت کرده است یا خیر و همچنین، سرور به یاد نمیآورد که کاربر API قبلاً درخواست برای دریافت کدام منابع ارسال کرده است.
درخواست هایی که از جانب یک کلاینت به سرور ارسال میشوند حاوی تمامي اطلاعات لازم خواهد بود تا سرور بتواند دقیقاً متوجه شود که چه چیزی مدنظر کلاینت است. این میتواند بخشی از URL (آدرس منبع)، پارامترهای رشته پرس و جو (Query-String Parameter)، بدنه (Body) یا حتی سربرگ (Header) باشد. URL برای شناسایی منبع به صورت منحصربهفرد استفاده میشود و بدنه حالت (وضعیت) منبع درخواست شده را نگهداری میکند. وقتی سرور درخواست را پردازش کند، یک پاسخ از طریق بدنه، حالت یا سربرگ ها به کلاینت ارسال میشود.
- تفکيک کلاینت-سرور(Client- Server)
کلاینت و سرور، هر یک به تنهایی و به صورت مستقل عمل میکنند و تعامل میان این دو، تنها در قالب درخواست ها(Request) و پاسخ ها (Response) مي باشد. شروع کننده این درخواست ها تنها کلاینت است و پاسخ ها فقط در واکنش به یک درخواست از جانب سرور به کلاینت ارسال میشوند. در مقابل، سرور منتظر دریافت درخواست از جانب کلاینت میماند و هیچ وقت خودسرانه شروع به ارسال و توزيع اطلاعات در خصوص حالت منابع نمیکند.
- واسط یکپارچه(Uniform Interface)
جهت دستیابی به یکپارچگی(Uniformity)، در سراسر برنامه کاربردی، REST دارای چهار محدودیت واسط کاربری است که در ادامه مطلب، به آن ها اشاره شده است:
- شناسایی منابع(Resource Identification):
یعنی درخواست ارسالی به سرور باید دارای یک شناسه منبع باشد.
- دستکاری منابع (Resource Manipulation):
یعني پاسخی که سرور بازمیگرداند باید حاوی اطلاعات کافی باشد تا کلاینت بتواند منبع را تغییر داده و ویرایش کند.
- پیامهای خود-توصیفگر(Self-Descriptive Messages):
یعنی هر درخواست به API، باید شامل تمام اطلاعاتی باشد که سرور برای اجرای آن درخواست به آن نیاز دارد و هر پاسخی که سرور باز میگرداند، باید شامل تمام اطلاعاتی باشد که کلاینت برای درک آن پاسخ، به آن اطلاعات، نیازمند است.
- ابررسانه به عنوان موتور حالت اپلیکیشن(Hypermedia as the Engine of Application State):
یعني سرور در یک پاسخ میتواند کلاینت را از روشهای تغییر حالت وب اپلیکیشن مطلع سازد. اگر کلاینت در مورد یک کاربر خاص، درخواست ارسال کند، نه تنها سرور میتواند حالت آن کاربر را فراهم کند، بلکه میتواند اطلاعاتی در مورد نحوه تغییر حالت آن کاربر مانند چگونگی ویرایش نام آن کاربر یا حذف کاربر نیز ارائه دهد. میتوان در مورد نحوه انجام آن، این گونه تصور کرد که یک سرور پاسخی را در قالب HTML به یک مرورگر (کلاینت) باز میگرداند.
- قابل ذخیرهسازی بودن(Cacheable):
بدين معناست که دادههای ارسال شده از سمت سرور حاوی اطلاعاتی در این مورد هستند که آیا این دادهها قابل ذخيره سازي در حافظه موقت (Cahce) هستند یا خیر. اگر داده ها قابل ذخیرهسازی باشند، ممکن است حاوی نوعی شماره نسخه باشند. شماره نسخه، ذخیره سازی را امکانپذیر میکند.
چون کلاینت میداند که در حال حاضر کدام نسخه داده را (از یک پاسخ قبلی) در اختیار دارد، میتواند از ارسال درخواست پیدرپی برای دادههای یکسان خودداری کند. همچنین، کلاینت باید بداند که آیا نسخه فعلی داده منقضی شده است یا خیر. در این صورت کلاینت متوجه خواهد شد که باید یک درخواست دیگر برای دریافت بهروزترین داده ها درباره حالت یک منبع به سرور بفرستد.
- سیستم لایهبندی شده(Layered System):
ممکن است چندين سرور در بين راه، میان یک کلاینت که حالت یک منبع را درخواست میکند و سرور که پاسخ را بازمیگرداند، وجود داشته باشد. همچنين، دارای یک لایه امنیتی، یک لایه ذخیرهسازی موقت یا یک لایه توازن بار باشند یا هر قابلیت دیگری را ارائه دهند. آن لایه ها نباید درخواست یا پاسخ را تحت تاثير قرار دهند. کلاینت هیچ دخالتی ندارد در این که چه تعداد لایه میان کلاینت و سرور پاسخ دهنده مورد نظر وجود دارد.
- کد در صورت تقاضا(Code On Demand):
یک API حتی بدون فراهم کردن کد در صورت تقاضا میتواند RESTful در نظر گرفته شود. کلاینت میتواند از سرور درخواست کد بدهد و سپس، پاسخ از سرور حاوی مقداری کُد خواهد بود. وقتی پاسخ در قالب HTML است، معمولاً این پاسخ به صورت یک اسکریپت خواهد بود. پس از دریافت کد، کلاینت میتواند آن را اجرا کند.
REST API چگونه کار میکند ؟
RESTful API، یک تراکنش را برای ایجاد یک سری ماژول های کوچک تجزیه میکند. هر ماژول یک بخش زیربنایی از تراکنش را خطاب قرار میدهد. این ماژول بندی انعطافپذیری بسیاری را برای توسعه دهندگان فراهم میکند. اما میتواند برای توسعهدهندگان چالشبرانگیز باشد که بخواهند REST API خود را از صفر بسازند.
RESTful API، از دستوراتی جهت دستیابی به منابع استفاده میکند. حالت یک منبع در هر برچسب زمانی (Timestamp) مربوطه را یک بازنمایی منبع مینامند. یک RESTful API از روشهای موجود HTTP استفاده میکند.
عملیات اصلی REST
شیوه عملکرد RESTful API در چهار عمل حیاتی خلاصه میشود. این چهار عمل در ادامه فهرست شدهاند.
- دریافت دادهها در یک قالب مناسب
- ایجاد داده جدید
- بهروزرسانی دادهها
- پاک کردن دادهها
REST، به شدت به HTTP وابسته است. هر کدام از عملیات بیان شده در بالا، از متُد HTTP مختص خودش استفاده میکند.
متدهای HTTP استفاده شده درREST:
- GET: برای دریافت دادهها استفاده میشود.
- POST: برای ایجاد داده جدید استفاده میشود.
- PUT: برای بهروزرسانی (ویرایش) دادهها استفاده میشود.
- DELETE: برای حذف دادهها مورد استفاده قرار میگیرد.
فرمت(قالب) هاي داده در REST:
فرمت(قالب)هايي که یک REST API از آنها پشتیبانی میکند شامل موارد زیر است:
متد های درخواست
تمام درخواست هایی که ارسال میشوند کد های حالت HTTP مختص به خودشان را دارند. تعداد زیادی از این کدها وجود دارد که به پنج دسته طبقهبندی میشوند. اولین رقم تعیین میکند که یک کد به کدام دسته تعلق دارد. این پنج دسته در ادامه فهرست شده است:
- 1xx- اطلاعاتی (Informational)
- 2xx- موفقیت (Success)
- 3xx- تغییرمسیر (Redirection)
- 4xx- خطای کلاینت (Client Error)
- 5xx- خطای سرور (Server Error)
چه زمانی باید از REST استفاده شود؟
پهنای باند و منابع محدود: به دلیل اینکه پیامهای SOAP در محتوا حجیمتر هستند و پهنای باند بسیار بیشتری را مصرف میکنند، در مواقعی که محدودیت در پهنای باند شبکه وجود دارد، باید از سبک معماری REST استفاده شود.
کاربردهای REST API:
چون فراخوانیها مستقل از حالت هستند، REST، برای کاربردهای ابری مناسب است. در صورت بروز نقص، میتوان اجزاء مستقل از حالت را مجدد به کار گرفت. همچنین، برای پاسخ دهی به تغییرات بار (Load) وارده میتوان مقیاس این اجزاء را تنظیم کرد. این امکان به این دلیل وجود دارد که هر درخواستی را میتوان به هر رخداد (Instance) از یک جزء هدایت کرد.
در الگوی REST چیزی که نیاز باشد به وسیله تراکنش بعدی به خاطر سپرده شود را، نمیتوان ذخیره کرد؛ این مساله، REST را برای استفاده در وب، مطلوب ساخته است.
در مجموع، REST API، به شما این امکان را می دهد که به صورت برنامه نویسی شده، اطلاعات خود را با قالب مشخص در اینترنت ارسال کنید.
در حال حاضر، سرويس مارکتينگ اتوماسيون zebline در قسمت يکپارچه سازي، شامل سه بخش است که در ادامه به توضيحات بيشتري اشاره مي شود:
- اعتبارنامه (Credentials)
در این بخش Access Token و License Code پنل کاربری شما جهت استفاده در فرآیند يکپارچه سازي قرار داده شده است.
- پلاگين ها (Plugins)
در این بخش، شما می توانید پلاگین های سرویس دهنده های شخص ثالث خود را افزوده و مدیریت کنید. لیست پلاگین های شما در این بخش قابل دسترسي است.
اعتبارنامه (Credentials)
در سرويس مارکتينگ اتوماسيون zebline، در قسمت اعتبارنامه، Access Token و License Code پنل کاربری شما جهت استفاده در فرآیند يکپارچه سازي قرار داده شده است. در اینجا، میتوانید جهت نمايش توکن ها و کپي کردن آن ها بر روي نماد مربوطه کليک نماييد.
با انتخاب Integration> Credentials می توانید به اطلاعات مربوط به اعتبارنامه ها در پلتفرم خود، دسترسی داشته باشید.
شکل 381-نماي کلي اعتبارنامه(Credentials)، را نشان مي دهد.
نکته: لطفا توجه داشته باشید جهت مشاهده اعتبارنامه در قسمت يکپارچه سازي، به مجوز لازم، نیاز دارید.