بررسی سیر تحولات Javascript ، ظهور JQuery ، هماهنگی مثال زدنی JQuery با MVC و حمایت از AJAX - قسمت دوم

    تا اینجا شاید این سوال مطرح شده باشد که با وجود JQuery (که بوضوح عملیات مشابه در مقایسه با JavaScript از کیفیت ، سرعت و دقت بالاتری برخوردار است) طرح برخی جزییات در مورد JavaScript غیر ضروری و بی اهمیت باشد . اما باید توجه داشت که علیرغم اینکه JQuery مخصوصا در زمینه سازگاری با مرورگرهای مختلف و انجام عملیاتی که انتظار داریم از Syntax و روشهای بسیار ساده تری استفاده می کند ، به همان میزان برنامه نویس از بسیاری از جزییات دور نگاه داشته می شود که به نظر می رسد مخصوصا با شرایطی که امروز وجود دارد، حداقل درک بسیاری از این جزییات برای برنامه نویسانی که از تکنولوژی های ASP .NET MVC و WEB API استفاده می کنند ، ضروری است . حداقل درک عمیقی از مفاهیم Request و Response ، Synchronous و Asynchronous ، وجه تمایز بین Verb های HTTP، ساختار URL و نقش AJAX قطعا برنامه نویس را در اتخاذ روش های مناسب و کارآمد یاری داده و امکان انتخاب رویکرد صحیح را در شرایط متنوع میسر می سازد . 
مخصوصا در AJAX موضوع در Javascript کاملا با دقت و تمرکز بیشتری بررسی شده و پس از آن روشهای بسیار ساده تری که در JQuery برای انجام همین عملیات تدارک دیده شده اند معرفی خواهند شد .

در ساده ترین حالت، همه Message ها یا پیام های HTTP در دو گروه عمده Request و Response قابل تقسیم بندی هستند . واضح است که چنانچه از نام آنها نیز مشخص می باشد Request عبارت است از یک درخواست که اطلاعات دقیق تر این درخواست در قالب یک پکیج اطلاعاتی شامل Request Header و Request Body جهت دریافت محتوای اطلاعاتی خاص (Contents) یا انجام عملیات خاص (Actions) به یک سرویس دهنده ارسال می شود . آدرس یا مشخصه یکتایی (Unique) سرویس دهنده در URL و به طور دقیق تر در Request Header قرار می گیرد . 
همچنین اطلاعات ارسال شده در این پکیج شامل یک مشخصه خاص به نام Method یا Verb می باشد. بر اساس اطلاعات ارائه شده پروتکل HTML 1.1 در RFC 2616 ، از مهمترین انواع Method ها می توان به GET و POST اشاره کرد . بر اساس استاندارد مطرح شده توسط W3C تعداد Method ها در واقع بیش از این دو می باشد که در حال حاضر ذکر آنها ضروری نیست . برای اطلاعات دقیقتر می توانید به مستندات W3C و بخشهای مربوط به تقسیم بندی این متدها در RFC 2616 در زیر:

 

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

 

مراجعه نمایید.
امروزه همه مرورگرهای مدرن از هر دو متد GET و POST پشتیبانی می کنند و در مورد سایر متدها اختلاف هایی وجود دارد که جزییات آن در مستندات هر مرورگر وجود دارد . 
قبل از توصیف مختصری در مورد این دو متد و تفاوتهای آنها لازم است توجه داشته باشیم که تایپ URL یا آدرس در Address Bar مرورگر یا کلیک بر روی یک لینک، در حقیقت نمونه های بارز و رایجی از آغاز یک در خواست با متد GET می باشند که از این به بعد آن را Get Request می نامیم . در خواست POST معمولا در مرور گر توسط ارسال (Submit) پکیج اطلاعات یک فرم قابل انجام می باشد که از این به بعد آن را POST Request می نامیم . در اینجا فرض بر این است که خواننده این سطور کاملا با مفهوم Form در HTML و استفاده از Attribute های Action و Method آشنا می باشد . به طور دقیق تر Attribute مشخص شده با نام Method در داخل تگ FORM مشخص کننده نوع متد مورد نظر جهت ارسال پکیج اطلاعات Form به URL یا آدرسی است که در Action ذکر شده است .

نکته:

نظر به اهمیت استفاده از همه ظرفیت های پروتکل HTTP در WEB API ، موضوع توجه و تمایز بین Verb های مستند شده در HTTP 1.0 بسیار اهمیت دارد . حتی در ASP .NET MVC نیز در مقایسه با ASP .NET Web Form موضوع توجه به ویژگیها و موارد استفاده از Verb ها بسیار پر رنگ تر از گذشته مورد توجه برنامه نویسان می باشد . اما در WEB API درک دقیق Verb ها و چنانچه اشاره شد استفاده کامل از حداکثر ظرفیتهای HTTP از اولویت بسیار بالایی برخوردار است . به عبارت دیگر معماری REST حساسیت بسیار ویژه ای نسبت به Verb های متنوع پروتکل HTTP مخصوصا Get ، Post ، Put و Delete داشته و حتی یک مراجعه سطحی به مستندات Web API بوضوح نشان می دهد که اساسا سرویسهای RESTFull بر همین مبنا پایه گذاری شده اند . به طور دقیق Verb های HTML تر در WEB API از یک دیدگاه بسیار خاص )نسبت به نوع عملکرد آنها) طبقه بندی شده اند و در این میان، عامل اصلی تعیین کننده نوع Verb، ساختار ظاهری URL می باشد که بر اساس ساختار اطلاعاتی هدف (اینکه یک آیتم یا یک لیست یا مجموعه باشد) مشخص می گردد. با این توضیحات و با در نظر گرفتن چهار Verb ذکر شده ، می توان به سادگی دریافت که هشت عملیات مختلف و متنوع ، توسط کنترلر های Web API قابل انجام است . مجددا تکرار می کنم که این موضوع کاملا وابسته به ساختار URL می باشد . تقسیم بندی خاصی که پیشتر به آن اشاره شد مفهوم ویژه ای به نام Idempotency را مطرح می سازد که اشاره به این واقعیت مهم است که تکرار عملیات (به عنوان مثال عملیات ناشی از صدور فرمان Refresh یا کلید F5) در Verb های Get و Put و Delete منجر به انجام عملیات یکسانی می گردد و تکرار آن به هیچ وجه مضر یا مخرب نیست . در یک مثال ساده با هربار تکرار URL و آدرس فرضی

http://Nowhere.com/Customers /12345

زیر (که بوضوح می تواند به عنوان یک Get Request به منظور دریافت جزییات اطلاعات مربوط به مشتری (Customer) خاصی با ID و شناسه 12345 تلقی شود) ، آنچه هر بار تکرار خواهد شد تکرار ارائه جزییات اطلاعات یک مشتری با مشخصه CustomerID=12345 خواهد بود . از این جهت این Verb (ها) اصطلاحا Idempotent نامیده می شوند . 
در یک مورد مشابه دیگر اگر URL مثال قبلی را این بار از نوع Put Request در نظر بگیریم (که می تواند به صورت ایجاد یک Instance یا نمونه جدید از یک مشتری با مشخصه CustomerID=12345 تلقی شود) مجددا تکرار این عملیات در نهایت منجر به ایجاد یک نمونه از اطلاعات مشتری خواهد شد که مجددا از همین رو Put یک Verb از نوع Idempotent در نظر گرفته می شود .در مورد Delete هم دقیقا همین وضعیت وجود دارد و از ذکر مثال خودداری شده است. در مجموع این اصطلاح به تعبیری اشاره به Safe بودن یا ایمن بودن ذاتی نوع عملیاتی است که توسط Get و Put و Delete انجام می شود . در مقابل POST هیچگاه به عنوان یک Verb از نوع Idempotent در نظر گرفته نمی شود . چنانچه مطلع هستید استفاده از Post به صورت رایجی در مواقعی است که نیاز به ایجاد یک نمونه جدید از یک Object خاص وجود دارد که بر خلاف وضعیت تشریح شده در Put انتظار داریم سیستم خود یک ID معتبر تولید کرده و (بر اساس سایر اطلاعات تکمیلی که Post شده است) اقدام به ایجاد نمونه جدید بنماید . بدیهی است که تکرار این عملیات مخرب و با هر بار اجرا یک نمونه جدید (بر خلاف مثال های قبل) ایجاد خواهد شد . 
 

ذکر این جزییات فقط تاکید بر این نکته بسیار مهم است که به نظر می رسد باید یک تغییر یا تجدید نظر کلی در نگرش به Verb ها و نوع استفاده از آنها برای برنامه نویسانی که قصد استفاده موثر از Asp .NET MVC و WEB API را دارند ، ایجاد شود . 
در مورد جزییات تمایز بین Verb ها در MVC در ادامه مثالهایی ارائه خوهد شد و ملاحظه خواهیم کرد که بر خلاف ASP .NET Web Form که اجبار به استفاده از یک Form و تشریک مساعی مکانیسم Page Rendering/Server Controls از سوی سیستم تحمیل میشد، در MVC امکان استفاده از چندین Form با Verb های متنوع و حتی استفاده از Asynchronous Request بواسطه استفاده از تکنولوژی AJAX ، شاهد افزایش چشمیگری در کیفیت خواهیم بود.
 

ملاحظاتی در باره Get و Post

در ساده ترین شکل می توان چنین گفت که استفاده از Get Request در مجموع باید صرفا به منظور دریافت (get) اطلاعات (در فرمت های متنوع HTML ، XML ، JSON و ...) از web Server تدارک دیده شود . در مقابل یک Post Request به طور معمول انحصارا برای تغییر (Modify) در اطلاعات (اشاره به Insert و Update و Delete) مورد استفاده قرار می گیرد .
تنها و تنها برنامه نویس مسئول انتخاب استراتژی و انتخاب Verb مناسب ، بعد از تشخیص کامل Idempotent بودن یا Safe بودن یا غیر مخرب بودن عملیات است . عملیاتی نظیر جسجتو در Database یا دریافت گزارش از واضح ترین مصادیق استفاده صحیح از Get Request می باشند . در هنگام انتخاب Get Request موارد زیر باید همیشه مورد توجه باشند :

1- امکان Cache شدن نوع درخواست Get (بر خلاف Post) وجود دارد.
2- در شرایط طبیعی، همواره سابقه درخواست های Get در Browser History ثبت می شوند .
3- امکان نشانه گذاری و Bookmark درخواست های Get وجود دارد .
4- در صورت تمایل به سادگی امکان به اشتراک گذاری (Sharing) در خواست های نوع Get وجود دارند .
5 درخواستهای نوع Get به سادگی قابل دستکاری ، سو استفاده و واضح تر عرض کنم Hack شدن می باشند . بنابراین در هنگام طراحی سیستم پردازش درخواست های Get باید از مکانیسم های مناسب جهت کنترل این ویژگی استفاده کنید که متاسفانه اینجا مجال پرداختن به آنها نیست .
6- مکانیسم درخواست های Get به ترتیبی است که اطلاعات تکمیلی مورد نیاز برای پردازش (در صورت نیاز) در خود URL و توسط مجموعه QueryString به سمت Server هدایت می شود . بدیهیست که معنای دقیقتر آن این است که این مکانیسم به هیچ وجه نباید در ارسال اطلاعات حساسی مثل کلمه عبور ، مشخصات کارتهای اعتباری و ... مورد استفاده قرار بگیرد .

نکته:

بر خلاف یک نظریه غلط که Post Request را روش ایمنی برای موارد مذکور تلقی می کنند ، باید توجه داشت که اصولا موضوع امنیت اساسا هیچ ارتباطی با انتخاب Verb نداشته و باید در نظر گرفت که در Post Request اطلاعات صرفا در بدنه Request قرار می گیرند که تقریبا به همان سهولت روش Get می تواند توسط افراد سوجو مورد سواستفاده قرار بگیرد . 

7- با عنایت به مطلب اشاره شده در آیتم ششم، هر چند هیچ محدودیتی در پروتکل Http جهت تعیین حداکثر اندازه یا تعداد کاراکترهای Query String تعیین نشده اما محدودیت ویژه ای از طرف خود مرورگرها برای این ویژگی وجود دارد . در IE این مقدار حداکثر 2048 (با احتساب سایر مولفه ای موجود در URL) کاراکتر می باشد .
8- در صورت استفاده از Javascript یا ترجیحا JQuery امکان ارسال Asynchronous Get Request با استفاده از تکنولوژی AJAX وجود دارد که مثالهایی از آن در ادامه ارائه خواهد شد . در JQuery متدهای get و getJSON و getScript و load به همین منظور تدارک دیده شده اند .

خلاصه ای از مواردی که در Post Request باید به آن توجه شود به قرار زیر است :

1- در صورتیکه حجم اطلاعاتی نیاز دارید به Server ارسال کنید زیاد باشد بهتر است که روش Post را انتخاب کنید .
2- در صورت نیاز به ارسال اطلاعات حساسی مثل Password و مشخصات کارت های اعتباری و اطلاعات حسابهای بانکی از روش Post (به همراه اطمنیان از سایر مولفه های امنیتی مثل SSL و پروتکل Https ) استفاده نمایید .
3- در شرایط معمولی یک Post Request معمولا با استفاده از ساختار و تگ Form با ذکر Method=Post در HTML میسر می باشد. اما این لزوما به این معنی نیست که تگ Form صرفا برای آغاز یک Post Request کاربرد دارد . بدیهی است که با تغییر در Method امکان تغییر به Get نیز وجود خواهد داشت . چنانچه در ادامه شاهد خواهیم بود با استفاده از AJAX تقریبا امکان استفاده از همه انواع Verb ها وجود دارد .
4- در JQuery متد post برای ایجاد یک Asynchronous Post Request با استفاده از AJAX تدارک دیده شده است .