هدف از این راهنما ، ارائه درک کاملی از روند رسیدگی به Node. js HTTP است. ما فرض خواهیم کرد که شما می دانید ، به معنای کلی ، چگونه HTTP درخواست می کند ، صرف نظر از زبان یا محیط برنامه نویسی. ما همچنین کمی آشنایی با Node. js EventEmitters و جریان ها را فرض خواهیم کرد. اگر با آنها کاملاً آشنا نیستید ، ارزش خواندن سریع اسناد API را برای هر یک از این موارد دارید.

سرور را ایجاد کنید

هر برنامه وب سرور گره در بعضی مواقع باید یک شیء سرور وب ایجاد کند. این کار با استفاده از CreateServer انجام می شود.

عملکردی که به CreateServer منتقل شده است ، یک بار برای هر درخواست HTTP که در برابر آن سرور ساخته شده است ، خوانده می شود ، بنابراین آن را کنترل کننده درخواست می نامند. در حقیقت ، شیء سرور که توسط CreateServer بازگردانده شده است ، یک EventEmitter است ، و آنچه ما در اینجا داریم فقط برای ایجاد یک شیء سرور و سپس اضافه کردن شنونده بعداً است.

هنگامی که یک درخواست HTTP به سرور برخورد می کند ، گره برای برخورد با معامله ، درخواست و پاسخ ، عملکرد کنترل کننده درخواست را با چند شیء مفید فراخوانی می کند. به زودی به آنها خواهیم رسید.

برای اینکه واقعاً درخواست ها را ارائه دهد ، باید روش گوش دادن به شیء سرور فراخوانی شود. در بیشتر موارد ، تنها چیزی که برای گوش دادن به آن باید منتقل کنید شماره پورت ای است که می خواهید سرور به آن گوش کند. گزینه های دیگری نیز وجود دارد ، بنابراین با مرجع API مشورت کنید.

روش ، URL و هدرها

هنگام رسیدگی به یک درخواست ، اولین کاری که احتمالاً می خواهید انجام دهید این است که به روش و URL نگاه کنید ، به طوری که می توان از اقدامات مناسب استفاده کرد. Node. js با قرار دادن خصوصیات مفید بر روی شی درخواست ، این مسئله را نسبتاً بدون درد ایجاد می کند.

روش در اینجا همیشه یک روش/فعل HTTP معمولی خواهد بود. URL URL کامل بدون سرور ، پروتکل یا درگاه است. برای یک URL معمولی ، این به معنای همه چیز پس از و از جمله سوتین سومین رو به جلو است.

هدرها نیز دور نیستند. آنها به درخواست خود به نام Headers در شیء خودشان هستند.

توجه به این نکته حائز اهمیت است که همه هدرها صرف نظر از نحوه ارسال مشتری در واقع ، فقط در موارد پایین نشان داده می شوند. این کار تجزیه و تحلیل هدرها را برای هر منظور ساده می کند.

اگر برخی از هدرها تکرار شوند ، بسته به هدر ، ارزشهای آنها رونویسی می شوند یا به عنوان رشته های جدا از کاما به هم می پیوندند. در بعضی موارد ، این می تواند مشکل ساز باشد ، بنابراین Rawheaders نیز در دسترس است.

بدنه درخواست کردن

هنگام دریافت پست یا درخواست ، بدن درخواست ممکن است برای درخواست شما مهم باشد. ورود به داده های بدن کمی بیشتر از دسترسی به هدرهای درخواست است. شیء درخواست که به یک کنترل کننده منتقل شده است ، رابط Readablestream را پیاده سازی می کند. این جریان را می توان دقیقاً مانند هر جریان دیگر به جای دیگر گوش داد یا لوله کشی کرد. ما می توانیم با گوش دادن به رویدادهای "داده" و "پایان" جریان ، داده ها را از جریان خارج کنیم.

قطعه ساطع شده در هر رویداد "داده" یک بافر است. اگر می دانید که این داده های رشته ای خواهد بود ، بهترین کار برای انجام جمع آوری داده ها در یک آرایه ، سپس در "پایان" ، آن را جمع کنید و آن را تنظیم کنید.

این ممکن است یک خسته کننده به نظر برسد ، و در بسیاری موارد ، اینگونه است. خوشبختانه ، ماژول هایی مانند Concat-Stream و Body در NPM وجود دارد که می تواند به پنهان کردن برخی از این منطق کمک کند. مهم است که قبل از پایین آمدن از آن جاده ، درک خوبی از آنچه اتفاق می افتد داشته باشید ، و به همین دلیل اینجا هستید!

یک چیز سریع در مورد خطاها

از آنجا که شیء درخواست Readablestream است ، همچنین یک رویداد EventEmiter است و در صورت بروز خطا مانند یک رفتار می کند.

خطایی در جریان درخواست با انتشار یک رویداد "خطا" در جریان ، خود را ارائه می دهد. اگر شنونده ای برای آن رویداد ندارید ، خطایی پرتاب می شود که می تواند برنامه Node. js شما را خراب کند. بنابراین شما باید یک شنونده "خطا" را در جریان درخواست خود اضافه کنید ، حتی اگر فقط آن را وارد کنید و در راه خود ادامه دهید.(اگرچه احتمالاً بهتر است نوعی پاسخ خطای HTTP ارسال کنید. بعداً بیشتر در مورد آن.)

روش های دیگری برای رسیدگی به این خطاها مانند سایر انتزاع ها و ابزارها وجود دارد ، اما همیشه آگاه باشید که خطاها می توانند و اتفاق بیفتند ، و شما باید با آنها مقابله کنید.

آنچه ما تاکنون بدست آورده ایم

در این مرحله ، ما ایجاد یک سرور را پوشش داده ایم و روش ، URL ، هدرها و بدن را از درخواست ها می گیریم. وقتی همه اینها را کنار هم قرار دادیم ، ممکن است چیزی شبیه به این باشد:

اگر این مثال را اجرا کنیم ، می توانیم درخواست دریافت کنیم ، اما به آنها پاسخ نمی دهیم. در حقیقت ، اگر این مثال را در یک مرورگر وب قرار دهید ، درخواست شما به پایان می رسد ، زیرا هیچ چیز به مشتری ارسال نمی شود.

تاکنون ما به هیچ وجه به شیء پاسخ نرسیده ایم ، که نمونه ای از ServerResponse است که یک Writablestream است. این شامل بسیاری از روش های مفید برای ارسال داده ها به مشتری است. ما بعدی را پوشش خواهیم داد.

کد وضعیت HTTP

اگر زحمت تنظیم آن را ندارید ، کد وضعیت HTTP در پاسخ همیشه 200 خواهد بود. البته ، هر پاسخ HTTP این را ضمانت نمی کند ، و در بعضی از مواقع قطعاً می خواهید کد وضعیت دیگری را ارسال کنید. برای انجام این کار ، می توانید ویژگی کد را تنظیم کنید.

میانبرهای دیگری نیز وجود دارد ، همانطور که به زودی خواهیم دید.

تنظیم هدرهای پاسخ

هدرها از طریق روشی مناسب به نام Setheader تنظیم می شوند.

هنگام تنظیم هدر ها ، پرونده در مورد نام آنها بی حس است. اگر به طور مکرر یک هدر را تنظیم کنید ، آخرین مقدار که شما تنظیم کرده اید ، مقدار ارسال می شود.

به صراحت ارسال داده های هدر

روش های تنظیم هدرها و کد وضعیتی که قبلاً در مورد آنها بحث کرده ایم فرض می کنند که شما از "هدرهای ضمنی" استفاده می کنید. این بدان معناست که قبل از شروع ارسال داده های بدن ، روی گره حساب می کنید تا در زمان صحیح ، هدرها را برای شما ارسال کند.

اگر می خواهید ، می توانید به صراحت عنوان ها را به جریان پاسخ بنویسید. برای انجام این کار ، روشی به نام WritEheD وجود دارد که کد وضعیت و هدرها را به جریان می نویسد.

هنگامی که هدرها را تنظیم کردید (به طور ضمنی یا صریح) ، آماده شروع به ارسال داده های پاسخ هستید.

ارسال بدنه پاسخ

از آنجایی که شیء پاسخ یک Writablestream است ، نوشتن یک بدن پاسخ به مشتری فقط استفاده از روش های جریان معمول است.

عملکرد پایان در جریان ها همچنین می تواند برخی از داده های اختیاری را به عنوان آخرین بیت داده در جریان ارسال کند ، بنابراین می توانیم مثال فوق را به شرح زیر ساده کنیم.

تعیین وضعیت و هدرها قبل از شروع نوشتن تکه های داده به بدن مهم است. این امر منطقی است ، زیرا هدرها در پاسخ های HTTP پیش از بدن می آیند.

یک چیز سریع دیگر در مورد خطاها

جریان پاسخ همچنین می تواند وقایع "خطا" را منتشر کند ، و در بعضی از مواقع نیز باید با آن مقابله کنید. تمام توصیه های خطاهای جریان درخواست هنوز در اینجا اعمال می شود.

همه را کنار هم قرار دهید

اکنون که ما در مورد ایجاد پاسخ HTTP آموخته ایم ، بیایید همه اینها را کنار هم قرار دهیم. با استفاده از مثال قبلی ، ما قصد داریم سرور را بسازیم که تمام داده هایی را که توسط کاربر برای ما ارسال شده است ، ارسال می کند. ما این داده ها را به عنوان JSON با استفاده از json. stringify قالب بندی خواهیم کرد.

مثال سرور اکو

بیایید مثال قبلی را برای ساختن یک سرور ساده اکو ساده کنیم ، که فقط هر آنچه را که داده در درخواست دریافت می شود ، در پاسخ ارسال می کند. تمام کاری که ما باید انجام دهیم این است که داده ها را از جریان درخواست بگیریم و آن داده ها را در جریان پاسخ بنویسیم ، مشابه آنچه قبلاً انجام دادیم.

حالا بیایید این را تغییر دهیم. ما می خواهیم فقط تحت شرایط زیر یک اکو ارسال کنیم:

• روش درخواست پست است.
• URL /echo است.

در هر صورت ، ما می خواهیم به سادگی با 404 پاسخ دهیم.

با بررسی URL از این طریق ، ما نوعی "مسیریابی" را انجام می دهیم. اشکال دیگر مسیریابی می تواند به سادگی بیانیه های سوئیچ یا به اندازه چارچوب های کل مانند اکسپرس باشد. اگر به دنبال چیزی هستید که مسیریابی را انجام دهد و هیچ چیز دیگری ، روتر را امتحان کنید.

عالی! حال بیایید در ساده کردن این کار چاقو بزنیم. به یاد داشته باشید ، شیء درخواست یک خواندن است و شیء پاسخ یک writablestream است. این بدان معناست که ما می توانیم از لوله برای هدایت داده ها از یک به دیگری استفاده کنیم. این دقیقاً همان چیزی است که ما برای یک سرور اکو می خواهیم!

ما هنوز کاملاً تمام نشده ایم. همانطور که در این راهنما چندین بار ذکر شد ، خطاها می توانند و اتفاق بیفتند ، و ما باید با آنها مقابله کنیم.

برای رسیدگی به خطاهای موجود در جریان درخواست ، ما خطا را به STDERR وارد می کنیم و یک کد وضعیت 400 ارسال می کنیم تا یک درخواست بد را نشان دهد. با این حال ، در یک برنامه دنیای واقعی ، ما می خواهیم خطای را بازرسی کنیم تا بفهمیم کد و پیام صحیح وضعیت چیست. طبق معمول با خطاها ، باید با مستندات خطا مشورت کنید.

در پاسخ ، ما فقط خطا را به STDERR وارد خواهیم کرد.

ما اکنون بیشتر اصول اولیه رسیدگی به درخواست های HTTP را پوشش داده ایم. در این مرحله ، شما باید بتوانید:

• یک سرور HTTP را با یک عملکرد کنترل کننده درخواست کنید و آن را در پورت گوش دهید.
• هدر ، URL ، روش و داده های بدن را از اشیاء درخواست دریافت کنید.
• تصمیمات مسیریابی را بر اساس URL و/یا سایر داده ها در اشیاء درخواست اتخاذ کنید.
• ارسال هدر ، کدهای وضعیت HTTP و داده های بدن از طریق اشیاء پاسخ.
• داده های لوله از اشیاء درخواست و اشیاء پاسخ.
• خطاهای جریان را در هر دو جریان درخواست و پاسخ انجام دهید.

از این اصول ، سرورهای HTTP Node. js برای بسیاری از موارد استفاده معمولی می توانند ساخته شوند. موارد دیگری وجود دارد که این API ها ارائه می دهند ، بنابراین حتماً از طریق اسناد API برای EventEmitters ، جریان ها و HTTP بخوانید.

بنیاد کپی رایت OpenJS و مشارکت کنندگان Node. js. کلیه حقوق محفوظ است. بنیاد OpenJS علائم تجاری را ثبت کرده و از علائم تجاری استفاده می کند. برای لیستی از علائم تجاری بنیاد OpenJS ، لطفاً به لیست مارک تجاری و لیست علائم تجاری ما مراجعه کنید. علائم تجاری و آرم هایی که در لیست علائم تجاری بنیاد OpenJS نشان داده نشده اند ، علائم تجاری ™ یا علائم تجاری ثبت شده دارندگان مربوطه هستند. استفاده از آنها به معنای وابستگی به آنها یا تأیید توسط آنها نیست.