طبق روال پست های پیشین یک یادآوری از آنچه تا کنون گفتیم.
گفتیم پروتکل HTTP، به عنوان پل ارتباطی بین کلاینت و سروره که پیچیدگی های سخت افزاری و شبکه ای رو از این دو پنهان میکنه و کارشون رو راحت تر. کلاینت با مرورگرش با این پروتکل در تماس هست و زبانی که این دو، یعنی کلاینت و HTTP باهم صحبت میکنند، Request است! و سرور هم با نرم افزار IIS ای که روش نصبه یا هر نرم افزار وب سروری دیگه ای که غیر از IIS داره اینکارو براش انجام میده، با HTTP در ارتباطه و زبانی هم که این دو میفهمند و میتونند باهم صحبت کنند، Response ئه.
در قسمت سوم راجع به URL صحبت کردیم و اینکه چطوری کلاینت به HTTP میفهمونه که درخواستی داره، تا HTTP هم براش ریسپانس بیاره، گفتیم از طریق URL این اتفاق می افته.
ولی آیا URL همون درخواسته؟
خیر!... URL شرط "ضروری" ولی "ناکافی" برای یک درخواست HTTP است.
یعنی خودش به تنهایی یک Request نیست، ولی برای ایجاد Request، لازمه که یک URL ای بالاخره وجود داشته باشه، وگرنه HTTP علم ماورا طبیعی نداره و نمیفهمه که باید به کدوم سرور یا هاست بره که اصلا پاسخی از اونجا بیاره. پس خیلی ساده نقش URL رو مثل کد پستی برای اداره پست یا همون HTTP تصور کنید. اداره ی پست خودش بر اساس اون اطلاعات کد پستی، محموله رو تنظیم میکنه.
پروتکل HTTP یک فرمت کلی برای پیام هاش داره که استانداردشه. پیام هاش چه Request باشه و چه Response با همین فرمت خاص میره. منتها اگر محتویات داخل پیام رو نگاه کنیم، از روی جزئیات سطر آغازین و پارامتر های هدر، میشه فهمید این پیام نوعش درخواسته، یا پاسخ.
آموزش های بسیار زیادی خوشبختانه در دسترس هست، حتی به زبان فارسی، که میشه رفت خوند و منم الان قصد ندارم یک آناتومی جامعی از این موضوع شرح بدم و تکرار مکررات از استاندارد و تئوری پارامترهاش بکنم. فقط قراره راجع به چیزهای مهمی که باید برای کارمون، یعنی کد نویسی بک اند یا حتی فرانت اند، بدونیم و دونستنش واجبه صحبت کنیم. برای من هیچ اهمیت نداره که HTTP بین Header و Body فاصله میندازه!
به قول خارجی ها، It's none of your business.
این پروتکل سالهاست وجود داره و کارشم خوب بلده!
پس بیایم وقتمون رو روی چیزهای مرتبط با کاره خودمون بزاریم. ما برنامه نویسیم و داریم کد مینویسیم. کدمون رو در نهایت روی هاست، یا سروری پابلیش میکنیم. اگر بخواهیم در چنین فضایی، یعنی وب، کد خوبی بنویسیم باید از دو بُعد به این کد نویسی خوب نگاه کنیم :
1- خوده کُد، که بالاخره قاعده مند و شکیل و منطبق بر شی گرایی و هزار شرط دیگه که همه به بهتر بودنش و درجه ی اعتبار شما به عنوان برنامه نویس، کمک میکنه.
2- فضایی که داره کُد ما اجرا میشه، که هرچی بیشتر شما این فضا رو درک کنین، عملکرد مطلوب تر و تضمین شده تری رو از کدتون میتونین ارائه بدین و وقتی هم میرین مصاحبه، تبحر خودتون رو بهتر نشون میدید.
بنابراین بیایم از HTTP اون چیزهایی رو یاد بگیریم که ما رو بیشتر به بند دوم مسلط میکنه.
به این سوال پاسخ بدیم که چی مهمه من برنامه نویس از HTTP بدونم که بتونم کد بهتری، حالا در هر فریم ورک تحت وب، بنویسم؟
بیایم یک کمی با فضا آشنا بشیم.
سرور یک پیرمرده ساکت، نسبتا بداخلاق و بی نهایت منضبطه. که سالهاست در یک اداره و با یک روتین کارمندی، کار میکنه. هیچ وقت بازنشسته نمیشه، مگر اینکه بمیره! ولی از وضعی هم که داره راضیه و به اهمیت کارشم واقفه. اتاقی که بهش دادند پره از قفسه های تا سقف، مملو از پرونده که هر کدوم از اون پرونده ها رو یک برنامه نویسی نوشته و گذاشته اونجا. کلا هم در تمام زندگی کاریش، با دو همکار در ارتباط بوده که با یکیشون بابت کارش، بیشتر در تماسه، یک نرم افزار وب سروری که ما دات نت کارها معمولا به اسم IIS میشناسیمش. یکیش سیستم عامله که خیلی نمیبینتش ولی خب بالاخره میشناستش.
شما برنامه نویس هم با این پیرمرد دارین کار میکنین، چون پرونده تون اونجاست.
نرم افزار IIS و اون مامور HTTP که داره از شبکه رد میشه و درخواستها رو میده به IIS هم با این پیرمرد دارن کار میکنند.
پس همه باید جوری کار کنین که منطبق با خلق و خوی سرور باشه.وگرنه سرور آدم بی حوصله و علافی! نیست که بخواد چیزی به کاره شما اضافه کنه.
پروتکل HTTP کارشو خوب بلده.چون سالهاست که داره با این سبک پیرمردها کار میکنه. برای همین همیشه مهمترین چیزها رو در همون سطر اول درخواستش، مینویسه که زودتر سرور، بفهمه این پرونده یا درخواست زیره دستش چیه. اسم این داده ی اطلاعاتی مهم در درخواست،HTTP method یا در بعضی از منابع Verb یا فعل هست.
حالا HTTP متد چیه؟ پیامی واضح و شفاف و بدون هیچ حاشیه چینی که به سرور بفهمونه این درخواست چیه؟ این بابا کلاینته چی میخواد؟ میخواد یک چیزی رو ذخیره کنه توی یکی از پرونده های قفسه ها، که اگر اینطوریه سرور بره برگه Body این درخواست رو بکنه و ببره توی پرونده قفسه مرتبطش بزاره.
یا نه میخواد یک چیزی از توی قفسه ها براش بیارن و با پاسخ براش بفرستن.
یا نه یک چیزی رو قبلا فرستاده، سرور براش ذخیره کرده، الان یک اصلاحیه میخواد روی اون بزنه.
یا نه اصلا میخواد اون چیزی که قبلا فرستاده رو به کل باطلش کنه.
شما هم از HTTP همین نکته رو به عنوان برنامه نویس یاد بگیرین. استفاده از HTTP متد های درست و به موقع در کدهاتون که بهتر بتونین، الان هیچ حضوری در اون اتاق ندارین و فقط پرونده تون اونجاست، به سرور بی حوصله و دقیق ما کمک کنین. پرونده تون براش یک پرونده خوانا باشه.
سرور هم همیشه مهمترین مطلبی که لازمه به شفاف ترین و گویاترین حالت، چون حوصله توضیح به هیچ کس رو نداره توی همون سطر اول پاسخش مینویسه. ما بهش میگیم Status Code.
حالا بیایم یک کمی از تصورات بیایم بیرون و علمی تر صحبت کنیم.
پرکاربرد ترین متد های HTTP عبارتند از :
GET / POST / PUT / DELETE / PATCH
متد GET برای خواندن داده استفاده میشه. درخواستی که IIS به سرور بده با سربرگ متد GET به این پیرمرد میفهمونه که این پرونده یا Request صفحه ی Body نداره.برای همین این درخواست ها بررسیشون برای سرور واضح و ساده است.
در مقابل هر درخواست GET، سرور دو مدل پاسخ داره.
یا مهر موفقیت آمیز میزنه که یعنی من پرونده رو پیدا کردم و گذاشتم توی صفحه ی Body ریسپانسم.مرورگر محترم از اونجا برش دار لطفا.یا مهر ناموفق میزنه که دیگه حساب کار دسته مرورگر میاد.
این مهر برای موفقیت میخوره 200 ok.
برای ناموفق باز سرور بسته به اتفاقی که توی اتاق افتاده چند مهر مختلف داره.
یا میزنه 401 که بهش میگند Un authorization که به زبون به زبونی به مرورگر یا همون کلاینتی که این درخواست رو داده میفهمونه که تو دسترسی نداری به این پرونده چون هویتت برای من مشخص نبود. بهتره یک بار به سایت لاگین کنی و بعد درخواستت رو با یک توکن احراز هویت برای من بفرستی.
یا مهر 403 یا Forbidden میزنه که آب پاکی رو روی دست کلاینت میریزه که تو اصلا سطح دسترسی به این محتوا نداری.برو پی کارت.
یا مهر 404 میزنه که برای اکثر ماها آشناست. یعنی Not found که به کلاینت میگه یک وقت فکر نکنی، من از اون کارمندهای بی مسئولیتم که پرونده ارباب رجوع رو بررسی نکرده پس میفرسته!. خیر، من سرور پاشدم گشتم ولی پیدا نکردم.ببین چی رو اشتباه برای من فرستادی. یا شایدم اون برنامه نویس احمقی که این پرونده رو اینجا گذاشته یک اشتباهی کرده. من توی کاره سروریم زیاد دیدم!.
یا گاهی هم مهر 405 میزنه که میگه من پرونده هه رو پیدا کردم، تو هم سطح دسترسی داشتی، احراز هویت هم شده بودی.ولی درخواستت رو اشتباه فرستادی. چون برنامه نویس بالای پرونده نوشته این پرونده فقط قابل ویرایشه.قابل ارسال شدن نیست. از سمت برنامه نویس بالاش صراحتا نوشته شده POST. این یعنی کلاینت نمیتونه به این اکشن یا متد با GET دسترسی داشته باشه.
این از HTTP متده GET.
برای اینکه مطلب طولانی تر نشه. متد های دیگه رو سریعتر بگیم.
ما سه متد ذخیره سازی داریم:
POST PUT PATCH
متد POST برای ذخیره داده ی جدید به کار میره. مثل GET هم دو حالت برای پاسخ براش پیش نمیاد. یا موفق ذخیره میشه یا ناموفق.
اگر موفق بود که کد 201 یا Create به ازاش سرور میده.
اگر ناموفق بود کد های 401/404/ و 409 برمیگرده که این آخری یعنی 409 میگه که یک Conflict ای رخ داد. که یعنی داده ای که داری ذخیره میکنی همچینم جدید نیست جناب کلاینت، از قبل درج شده و موجود بوده.ببین چه اشتباهی کردی.
متد PUT فرقش با POST برای سرور اینه که پیرمرد میفهمه این داده جدید نیست.وجود داره و میخواد ویرایش بشه.
در مقابلش سرور یا کد موفقیت یا 200 ok رو میده.
یا ناموفق که برای ناموفق یا مهر 204 یا No content میزنه که یعنی من محتوایی به این شکلی که تو قصد ویرایشش رو داری اصلا پیدا نکردم که بخوام درستش کنم.
یا مهر های 404 و 405 که راجع بهش گفتیم.
متد PATCH مثل PUT.
پس چه کاریه؟...صد درصد باید یک فرقی داشته باشند.
بله.فرقشون در اینه که با PUT کلاینت باید همه اطلاعات اون داده رو برای ویرایش بفرسته و سرور هم همه داده ها رو میگیره از درخواست و ویرایش میکنه. ولی PATCH نه. توی درخواست یک قسمتی از داده ارسال میشه و سرور هم فقط همون تیکه رو درست میکنه.
یا مهر 200 ok میزنه که یعنی تونستم.
یا کد های ناموفق 401/403/404 و 405.
یک متد دیگه هم میمونه که مشخصه. DELETE.
متد DELETE شبیه به GET ئه. Status کد هاشم شبیه به GET ئه.فقط 409 یا Conflict هم در زمره Status کدهاشه.
و کلام آخر...به عنوان یک برنامه نویس.چیزی که از HTTP درخواست و ریسپانس باید درک بهش داشته باشین و روش فوکوس کنین و ازش استفاده کنین در کدهاتون، همین متد ها و استاتوس کد هاست. چون شما قادر هستید که با اینها کار کنید در کدتون و مثلا کاربرتون رو به جای مواجه شدن با پیغام های ناخوانا که قراره مرورگر یهو بندازه روی صفحه اش مثل 404! که همون پاسخ سروره، و کاربر شما هیچی نمیفهمه چی شد؟ چی کار شد؟ چرا اینطوری شد؟ با یک پیام فارسی و صفحه ی خوانا هدایت اش کنین. و از طرفی میتونین به عملکرد سرور در پیدا کردن و پاسخ دادن کمک کنید و از خطاها و تخلف های کلاینت ها برای دسترسی های غیرقانونی و ... جلوگیری کنید.
راجع به این مباحث بیشتر صحبت خواهیم کرد.
