در قسمت قبل به معرفی سرویس های REST و برخی از ویژگی های سرویس های آن پرداختیم در ادامه به باقی ویژگی ها می پردازیم
تفاوت میان PUT و POST
توضیحی مختصر که از این دو روش در بالا توضیح داده شد شبیه به هم است.این دو روش بسیاری از توسعه دهندگان را گمراه می کنند. بنابراین بیایید این دو را جداگانه توضیح دهیم:
تفاوت اصلی میان این دو روش در آن است که PUT خودپنداره است درحالی که POST اینگونه نیست.فرقی نمی کند گخ چندبار درخواست PUT را بفرستید نتیجه یکسان خواهد بود.POST اینگونه نیست. درخواست POST به صورت دوبار پشت سر هم ممکن است دو منبع مختلف را بر روی منبع تولید کند.
تفاوت دیگر در آن است که، با PUT شما باید URI منبع را به صورت کامل مشخص کنید. این بدین معنی ست که حتی اگر منبعی بر روی سرور وجود نداشته باشد، کلاینت باید قادر به ساخت URIای از منبع باشد.این امر زمانی که وظیفه کلاینت اتخاب یک نام و یا ID منحصر به فرد برای منبع است، ممکن است؛ دقیقا شبیه به این موضوع که برای ساخت یک کاربر بر روی سرور نیازمند آنیم که کلاینت یک ID را انتخاب کند. اگر یک کلاینت قادر به حدس URIای کامل از منبع نباشد شما گزینه دیگری جز استفاده از POST ندارید.
در جدول بالا مشخص است که یک درخواست PUT بیش از یک منبع را فارغ از آنکه چندبار اجرا شود تغییر نمی دهد و یا نمی سازد ( اگر URI یکسان باشد) .اگر منبع از پیش موجود باشد تفاوتی مابین PUT و POST وجود ندارد، هر دو این روش ها منبع را به روزرسانی خواهند کرد.درخواست سوم یک منبع جدید را هر بار که ارسال می شود می سازد. بسیاری از توسعه دهندگان فکر می کنند REST به POST اجازه استفاده از POST برای عملیات به روز رسانی را نمی دهد هر چند REST چنین محدودیتی را اعمال نمی کند.
وابسته نبودن به مکان خاصی (Stateless)
یک سرویس دارای REST، Stateless است و حالت نرم افزار را برای هیچ کلاینتی حفظ نمی کند. یک درخواست نمی تواند وابسته به یک درخواست قدیمی باشد و یک سرویس با هر درخواست به صورت مستقل رفتار می کند. HTTP از نظر طراحی یک پروتکل Stateless است و شما نیاز به چیزی اضافه برای پیاده سازی یک سرویس Stateful با استفاده از HTTP هستید. ولی این امر کاری آسان است که با تکنولوژی های کنونی یک سرویس Stateful پیاده سازی کنید.ما نیاز به درک طراحی فاقد مکان خاص و طراحی مقدماتی داریم تا بتوانیم از تفسیر اشتباه بپرهیزیم.
یک طراحی Stateless مانند زیر است:
درخواست ۱: GET http://MyService/Persons/1 HTTP/1.1 درخواست ۲: GET http://MyService/Persons/2 HTTP/1.1
هر یک از این درخواست ها می تواند به صورت جداگانه مورد بررسی قرار گیرد.
در طرف دیگر یک طراحی Stateful به صورت زیر است:
درخواست ۱: GET http://MyService/Persons/1 HTTP/1.1 درخواست ۲: GET http://MyService/NextPerson HTTP/1.1
برای پردازش درخواست دوم سرور نیاز به حفظ آخرین PersonID که کلاینت واکشی(fetch) کرده است دارد. به عبارت دیگر سرور باید وضعیت کنونی را حفظ کند، درغیر این صورت درخواست ۲ پردازش نمی شود. سرویس خود را به حالتی طراحی کنید که نیاز به درخواست های گذشته نباشد.سرویس های Stateful برای میزبان آسان تر هستند، برای حفظ کردن راحت تر هستند و بسیار مقیاس پذیرند.به علاوه این این نوع سرویس ها می توانند پاسخ را در زمان بهتری به درخواست ها تخصیص بدهند و بارگذاری متعادل بر روی آن‌ها آسان تر است.
اتصالات میان منابع
یک ارائه منبع می تواند شامل اتصالات به سایر منابع همچون صفحات HTMLای که شامل لینک سایر صفحات هستند، باشد. ارائه هایی که توسط سرویس بازگردانده می‌شود باید جریان پردازش را همچون یک وب سایت اداره کنند. وقتی شما یک وبسایت را مشاهده می‌کنید، شما با یک شاخص صفحه رو به رو می شوید. شما روی یکی از لینک ها کلیک می کنید و به صفحه دیگری برده می شوید و قص علی هذا. اینجا ارائه در اسناد HTML است و کاربر به سمت وبسایت با استفاده از اسناد HTML اداره می شوند.کاربر نیاز به یک نقشه راه جهت آمدن به یک وبسایت ندارد. یک سرویس باید(بهتر است) بر طبق این روش طراحی شود.
از آنجایی که REST به عنوان پیش فرض برای اکثر سایت‌ها و نرم افزارهای موبایل قرار گرفته، یادگیری پایه‌های آن امری ضروری به شمار می‌رود.
بیایید حالتی را فرض کنیم که یک کلاینت درخواستی از منبعی را می‌فرستد که خود شامل چند منبع دیگر است. به جای روبرداری کردن از همه منابع شما می توانید منابع را فهرست کنید و اتصالات میان آن‌ها را فراهم سازید. اتصالات به کوچک نگه داشتن اندازه ارائه کمک می کند.
برای مثال اگر Personها بتوانند بخشی از یک Club باشند و یک Club بتواند به عنوان یک Mysevice در لیست شماره ۶ قرار بگیرد.
لیست شماره ۶ : یک Club متصل به Personها
<Club> <Name>Authors Club</Name> <Persons> <Person> <Name>M. Vaqqas</Name> <URI>http://MyService/Persons/1</URI> </Person> <Person> <Name>S. Allamaraju</Name> <URI>http://MyService/Persons/12</URI> </Person> </Persons> </Club>
ذخیره سازی
ذخیره سازی مفهومی برای ذخیره سازی نتایج حاصله و استفاده از این نتایج به جای ساخت مجدد آن‌ها است اگر درخواستی مشابه در آینده نزدیک برسد. این می تواند در سمت کلاینت پیاده سازی شود و یا سمت سرور و یا هر یک از اجزای موجود در بین آن ها به عنوان مثال سرور پروکسی.
ذخیره سازی راهی مناسب برای تقویت پردازش سرویس است ولی اگر به درستی مدیریت نشود می تواند باعث از بین رفتن و کهنه شدن کلاینت‌شود.
ذخیره سازی توسط سربارهای HTTP می تواند کنترل شود:
ارزش این سربارها می تواند با دستورالعمل های موجود در سربار Cache-Control برای چک کردن این که آیا نتایج ذخیره شده همچنان معتبرند یا نه ادغام شود. رایج ترین این دستورالعمل‌ها عبارتند از:
شما برخی از این دستورالعمل ها و سربارها را در لیست شماره ۵ می توانید مشاهده کنید. بسته به ذات منابع، یک سرویس می تواند ارزش این سربارها و دستورالعمل‌ها را مشخص کند. برای مثال یک سرویسی که می تواند بازار سهام را فراهم سازد باید محدوده age را به کوچکترین مقدار ممکن تقلیل دهد و یا حتی اطلاعات حیاتی وجود داشته باشد به طور کامل خاموش شود و کاربران باید آخرین تغییرات را به طور دائم دریافت کنند. در دست دیگر یک انبار عمومی عکس که محتویاتش یا تغییر نمی کند و یا به ندرت تغییر می کند باید از یک age بزرگتر برای ذخیره سازی استفاده کند و قوانین ذخیره سازی را پشت گوش بیندازد. سرور، کلاینت و هر جز میانجی میان این دو باید از این دستورالعمل ها برای جلوگیری از خدمت رسانی به اطلاعات منسوخ شده استفاده کند.
مستندسازی یک سرویس دارای REST
سرویس‌های دارای REST ملزوم به استفاده از مستند برای کمک به کلاینت جهت کشف آن‌ها نیستند.باتوجه به URIها ، لینک‌ها، و یک رابط واحد می توان به راحتی در زمان اجرا سرویس‌های دارای REST را درک نمود. یک کلاینت آدرس گایه سرویس را می داند و از آنجا می تواند سرویس را بر روی خودش با پیمودن منابع با استفاده از لینک‌ها درک نماید.متد OPTIONS به طور موثر برای فهم یک سرویس به کار می رود.
این بدین معنا نیست که سرویس های دارای REST به هیچ متندسازی ای نیاز ندارند. هیچ عذری برای عدم مستندسازی سرویس‌تان وجود ندارد.شما باید هر منبع و URIای را برای توسعه‌دهندگان کلاینت مستندسازی کنید. شما می توانید از هر فرمتی برای ساختمان بندی مستندتان استفاده کنید ولی این فرمت باید به اندازه کافی اطلاعات از منابعتان، URIها، متدهای دردسترس و سایر اطلاعات مورد نیاز برای سرویس‌تان به دست بدهد.جدول زیر یک نمونه از مستندسازی MyService را نشان می دهد.این نمونه، نمونه ای ساده و کوتاه از مستندی است که تمام جوانب MyService را شامل می شود و باید برای توسعه یک کلاینت کافی‌ست.
نام سرویس : MyService
آدرس :http://MyService/
| شرح وظایف | URI | متدها | منبع |
|---|---|---|---|
| اطلاعاتی را درباره شخص دراختیار قرار می دهد {PersonID} اختیاری ست فرمت: text/xml | http://MyService/Persons/{PersonID} | GET,POST,PUT, DELETE | Person |
| اطلاعاتی را درباره باشگاه دراختیار قرار می دهد. در یک باشگاه چندین شخص می توانند عضو شوند {ClubID} اختیاری است فرمت: text/xml | http://MyService/Clubs/{ClubID} | GET,POST,PUT | Club |
| یک شخص یا باشگاه را جست و جو می‌کند فرمت: text/xml پارامترهای کوئری: نام: رشته, نام یک شخص یا باشگاه شهر: رشته, اختیاری, نام شهر محل استقرار یک شخص یا باشگاه نوع: رشته, اختیاری, شخص یا باشگاه. اگر ارائه نشده بود سپس نتیجه جست و جو هم باشگاه و هم شخص خواهد بود | http://MyService/Search? | GET | Search |
شما همچنین ممکن است که ارائه ای از هر منبع را مستند سازی کنید و چندین نمونه آزمایشی برای ارائه فراهم سازید.
نتیجه گیری
REST روش مناسبی برای وب سرویس های سبک است که به راحتی قابل فهم، قابل پیاده سازی و قابل ذخیره سازی ست.HTTP یک رابط عالی برای پیاده سازی سرویس های دارای REST با ویژگی‌هایی همچون رابط واحد و ذخیره سازی است. اگر چه این امر بسته به توسعه دهندگان و استفاده صحیح از این ویژگی هاست. اگر پایه را به درستی درک کنیم، یک سرویس دارای REST به راحتی با استفاده از هر تکنولوژی موجود نظیر Python، .NET یا Java قابل پیاده سازی است. امیدوارم این مقاله اطلاعات کافی برای شما برای توسعه سرویس دارای REST منحصر به خودتا را بدهد.
