قسمت ۱۹ دوره DRF منتشر شد 🥳

برای مشاهده کلیک کنید

شرمنده برای تاخیری که پیش اومد تواین مدت خیلی سرمون شلوغ بودش 🙏

#fun

خدا بود😂😂😂

@ninja_learn_ir

🌿 استفاده از پکیج dotenv در Node.js 🌿

امروز می‌خوایم در مورد پکیج dotenv توی Node.js صحبت کنیم. شاید برات سوال شده باشه که چطوری میشه اطلاعات حساس مثل API key‌ها، پسوردها و تنظیمات مهم رو به‌صورت امن توی پروژه نگه داشت. اینجاست که dotenv میاد وسط و کار رو خیلی راحت می‌کنه! 😎

❓حالا dotenv چیه؟ 🤔
خب dotenv یه پکیجه که بهت اجازه می‌ده اطلاعات حساس رو توی یه فایل به اسم .env ذخیره کنی. به‌جای اینکه این اطلاعات رو مستقیم توی کدت بنویسی (که خیلی خطرناکه 😱)، می‌تونی توی فایل .env نگه‌شون داری و وقتی اپلیکیشن اجرا میشه، dotenv این مقادیر رو لود می‌کنه ومتغیرهای محیطی  اضافه می‌کنه.

❓چرا باید از dotenv استفاده کنیم؟ 🔐

1⃣ امنیت بیشتر:
اطلاعات حساس رو مستقیم توی کدت نمی‌نویسی

2⃣ سادگی در مدیریت تنظیماتات:
برای هر محیطی (مثل توسعه، تولید و تست) می‌تونی فایل‌های .env جداگانه داشته باشی

3⃣ خوانایی بهتر کد:
وقتی اطلاعات حساس بیرون از کد اصلی باشه، کد تمیزتر و قابل نگهداری‌تر میشه.

❓ چطوری نصبش کنیم؟ 🛠️
نصب و استفاده از dotenv خیلی ساده‌ست. اول با دستور زیر نصبش کن:

npm install dotenv

نحوه استفاده از dotenv 🚀
بعد از نصب، یه فایل .env توی پروژه‌ات بساز و اطلاعات حساسی مثل API key، پسورد دیتابیس و بقیه تنظیمات رو توش ذخیره کن. مثلا:

DB_HOST=localhost
DB_USER=root
DB_PASS=supersecret

حالا توی app.js (یا هر فایل اصلی پروژه‌ات) باید dotenv رو لود کنی:

require('dotenv').config();

با این کار، dotenv تمام اطلاعات توی فایل .env رو لود می‌کنه و می‌تونی با استفاده از process.env بهشون دسترسی داشته باشی:

const dbHost = process.env.DB_HOST;
const dbUser = process.env.DB_USER;
const dbPass = process.env.DB_PASS;

console.log(`Database: ${dbHost}, User: ${dbUser}`);

نکته مهم 🛑
هیچ‌وقت فایل .env رو توی مخزن گیت (git) قرار نده! چون ممکنه اطلاعات حساسی مثل API key‌هات لو بره. برای جلوگیری از این کار، فایل .env رو به .gitignore اضافه کن:

.env

✅ جمع‌بندی:
پکیج dotenv خیلی به دردبخوره چون هم بهت کمک می‌کنه اطلاعات حساس رو به صورت امن مدیریت کنی و هم کدت تمیزتر و سازمان‌یافته‌تر بشه. پس حتماً توی پروژه‌هات ازش استفاده کن تا هم امنیت بالا بره هم تنظیمات محیطیت راحت‌تر مدیریت بشه. 😁

امید وارم مفید بوده باشه :)

#nodejs #js #dotenv

@ninja_learn_ir

اونایی که هنوز سربازی نرفتن یه سر به پست آخرمون بزنن 😉

https://www.instagram.com/p/DADR31eIFbk/?igsh=ajNrbHltYzMxMHVu

رفقا شرمنده چند روزی میشه که پست از ادامه کتاب نذاشتیم

هم سرمون شلوغ بود با کار و زندگی
هم من کسالت داشتم

از امشب ادامه کتابو استارت میزنیم ✌️

📕 کتاب REST API Design Rulebook

📌 فصل سوم: Interaction Design with HTTP

📍پارت: اول

#کتاب

‏💎 HTTP/1.1 💎
‏APIهای REST همه جنبه‌های پروتکل HTTP نسخه ۱.۱ رو شامل می‌شن، مثل متد های درخواست، کدهای ریسپانس و هدرها. این کتاب HTTP رو به دو فصل تقسیم کرده؛ این فصل درباره متد های درخواست و استاتوس کدهای ریسپانس صحبت می‌کنه.

فصل ۴ هم درباره گنجاندن متا داده‌ها در طراحی API REST و هدرهای درخواست و پاسخ HTTP صحبت می‌کنه.

‏💎 Request Methods 💎‏
کلاینت‌ها متد تعامل مورد نظر رو در قسمت Request-Line یک درخواست HTTP مشخص می‌کنن. استاندارد RFC 2616 نحوه نوشتن Request-Line رو این‌طوری تعریف کرده:

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

هر متد HTTP معنای مشخص و خاصی در زمینه منابع REST API داره. هدف GET اینه که نمایی از وضعیت یک منبع رو بگیره. HEAD برای دریافت متا داده‌های مربوط به وضعیت منبع استفاده می‌شه. PUT باید برای به‌روزرسانی یک منبع استفاده بشه. DELETE هم برای حذف یک منبع از والدش به کار می‌ره. POST هم برای ایجاد یک منبع جدید در یک مجموعه و اجرای کنترلرها استفاده می‌شه.

‏⭕️ GET و POST نباید برای تونل‌کردن سایر متد های درخواست استفاده بشن.
تونلینگ به هر نوع سوءاستفاده از HTTP گفته می‌شه که هدف یک پیام رو پنهان یا به اشتباه نمایش می‌ده و شفافیت پروتکل رو تضعیف می‌کنه.
یک API REST نباید طراحی خودشو با سوءاستفاده از متد های درخواست HTTP برای سازگاری با کلاینت‌هایی که دانش محدودی از HTTP دارن، به خطر بندازه. همیشه باید از متد های HTTP به‌طور صحیح و طبق قواعد این بخش استفاده کنی.


‏⭕️ GET باید برای دریافت نمایی از وضعیت یک منبع استفاده بشه.
یک کلاینت REST API از متد GET در درخواستش استفاده می‌کنه تا وضعیت یک منبع رو در یک فرم نمایشی دریافت کنه. پیام درخواست GET می‌تونه شامل هدرها باشه ولی body نداره.

معماری وب به شدت به ماهیت متد GET وابسته‌است. کلاینت‌ها باید بتونن درخواست‌های GET رو تکرار کنن بدون اینکه عوارض جانبی ایجاد بشه. کش‌ها هم به این قابلیت اتکا دارن که بتونن نمایه‌های کش‌شده رو بدون تماس با سرور اصلی ارائه بدن.

در مثال زیر، می‌بینیم که چطور یک توسعه‌دهنده کلاینت ممکنه از curl در یک ترمینال برای دریافت نمایی از وضعیت فعلی یک منبع "greeting" استفاده کنه:

1️⃣ curl -v https://api.example.restapi.org/greeting

2️⃣ > GET /greeting HTTP/1.1
3️⃣ > User-Agent: curl/7.20.1
> Host: api.example.restapi.org
> Accept: */*
4️⃣ < HTTP/1.1 200 OK
5️⃣ < Date: Sat, 20 Aug 2011 16:02:40 GMT
< Server: Apache
< Expires: Sat, 20 Aug 2011 16:03:40 GMT
< Cache-Control: max-age=60, must-revalidate
< ETag: text/html:hello world
< Content-Length: 130
< Last-Modified: Sat, 20 Aug 2011 16:02:17 GMT
< Vary: Accept-Encoding
< Content-Type: text/html

6️⃣ <!doctype html><head><meta charset="utf-8"><title>Greeting</title></head>
<body><div id="greeting">Hello World!</div></body></html>

1️⃣ در اینجا، GET متد پیش‌فرض curl هست، بنابراین نیاز نیست به‌طور صریح مشخص بشه. گزینه -v هم باعث می‌شه خروجی curl جزئیات بیشتری داشته باشه.

2️⃣ خط Request-Line در درخواست نشون می‌ده که از متد GET برای منبع greeting استفاده شده.

3️⃣ لیست هدرهای پیام درخواست هم از اینجا شروع می‌شه. هدرهای درخواست و پاسخ HTTP در فصل ۴ توضیح داده شدن.

4️⃣ پیام پاسخ هم از اینجا شروع می‌شه، با خط وضعیت که در بخش "کدهای وضعیت پاسخ" در صفحه ۲۸ بحث شده. کد وضعیت ۲۰۰ OK به curl می‌گه که درخواستش موفقیت‌آمیز بوده.

5️⃣ لیست هدرهای پیام پاسخ هم از اینجا شروع می‌شه.

6️⃣ بدنه پیام ریسپانس هم از اینجا آغاز می‌شه. در این مثال، بدنه شامل یک نمای HTML از پیام خوشامدگویی هست.


⭕️ برای اینکه فقط هدرهای ریسپانس رو بگیریم بدون اینکه body دریافت کنیم، می‌تونیم از متد HEAD استفاده کنیم.
یعنی HEAD همون جواب GET رو میده، ولی بدون بدنه. از این روش میشه برای این استفاده کرد که ببینیم یه منبع وجود داره یا اینکه اطلاعات متادیتاش رو بخونیم.

مثال زیر یه دستور curl رو نشون میده که با استفاده از متد HEAD فقط هدرهای پاسخ رو می‌گیره:

curl -I https://example.com/resource

توضیح:
- -I یا --head: این گزینه به curl میگه که به جای درخواست معمولی GET`، یه درخواست `HEAD بفرسته.
- https://example.com/resource: آدرس منبعی که می‌خوایم چک کنیم رو باید اینجا بذاریم.

نتیجه مورد انتظار:
این دستور فقط هدرهای HTTP رو برمی‌گردونه و body در کار نیست. از این طریق می‌تونیم اطلاعاتی مثل کد وضعیت، نوع محتوا، جزئیات سرور و... رو ببینیم. مثلا خروجی می‌تونه این شکلی باشه:

@ninja_learn_ir

HTTP/1.1 200 OK
Date: Wed, 18 Sep 2024 10:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Connection: keep-alive
Server: Apache/2.4.29 (Ubuntu)

این متد برای وقتی خوبه که بخوایم چک کنیم یه منبع هست یا نه، یا اینکه اطلاعات کلی مثل حجم محتوا و نوع سرور رو ببینیم.



⭕️ متد PUT باید هم برای اضافه کردن و هم برای به‌روزرسانی یک منبع ذخیره شده استفاده بشه. این یعنی:
- اضافه کردن یک منبع جدید: وقتی می‌خواهیم یک منبع جدید اضافه کنیم، URL یا URI (آدرس منبع) توسط کلاینت مشخص میشه.
- به‌روزرسانی یا جایگزینی منبع موجود: برای به‌روزرسانی یا جایگزینی یک منبعی که از قبل ذخیره شده هم از PUT استفاده می‌کنیم.

مثال:
فرض کنید یه API داریم که یه فروشگاه منابع رو برای کلاینت‌هاش فراهم می‌کنه تا داده‌هاشون رو به‌صورت آبجکت ذخیره کنن. درخواست PUT به این صورت می‌تونه باشه:

PUT /accounts/4ef2d5d0-cb7e-11e0-9572-0800200c9a66/buckets/objects/4321

درخواست PUT:
در پیام درخواست PUT، باید نمایشی از منبعی که کلاینت می‌خواد ذخیره کنه وجود داشته باشه. ولی محتوای درخواست ممکنه دقیقاً همونی نباشه که بعداً از طریق `GET دریافت میشه. برای مثال، ممکنه API اجازه بده که کلاینت فقط بخش‌های قابل تغییر (mutable) منبع رو بفرسته.

پشتیبانی از درخواست‌های شرطی (Conditional PUT):
در بخش بعدی ("قانون: فروشگاه‌ها باید از درخواست‌های شرطی PUT پشتیبانی کنند") توضیح داده شده که چطور یه API باید از هدرهای HTTP استفاده کنه تا PUT رو برای هم اضافه کردن و هم به‌روزرسانی منابع استفاده کنه.


⭕️ متد PUT باید برای به‌روزرسانی منابع قابل تغییر استفاده بشه. یعنی وقتی یک کلاینت می‌خواد تغییراتی روی یک منبع اعمال کنه، باید از PUT استفاده کنه.
درخواست PUT باید شامل یک بدنه (body) باشه که تغییرات مورد نظر رو نشون میده. این بدنه، وضعیت جدید منبع رو مشخص می‌کنه و وقتی که درخواست پردازش بشه، منبع با این داده‌های جدید جایگزین میشه.


⭕️ از متد POST باید برای ایجاد یک منبع جدید در یک مجموعه (collection) استفاده بشه. یعنی وقتی کلاینت می‌خواد یک منبع جدید به یک مجموعه اضافه کنه، از POST استفاده می‌کنه.
بدنه (body) درخواست POST شامل یک نمایش از وضعیت پیشنهادی منبع جدیدیه که قراره به مجموعه‌ای که توسط سرور مدیریت میشه، اضافه بشه.

مثال:
فرض کنید کلاینت می‌خواد یک بازیکن جدید به یک تیم اضافه کنه:

POST /leagues/seattle/teams/trebuchet/players

توضیح:
- در اینجا درخواست POST برای اضافه کردن یک بازیکن جدید به مجموعه بازیکنان تیم "trebuchet" در لیگ "seattle" است.
- بدنه درخواست ممکنه شامل اطلاعاتی باشه که حالت اولیه بازیکن جدید رو نشون میده، مثلاً نام، سن و مشخصات دیگه.
این استفاده از POST شبیه اینه که یک پیام جدید روی یک تابلوی اعلانات قرار بدیم، یعنی یک آیتم جدید به یک مجموعه اضافه می‌کنیم.


⭕️ از متد POST برای اجرای کنترلرهای تابع‌محور (function-oriented controller resources) استفاده می‌شه. یعنی کلاینت‌ها زمانی از POST استفاده می‌کنند که بخواهند یک عملکرد یا عملیاتی رو فراخوانی کنند. پیام درخواست POST می‌تونه شامل هم هدر و هم بدنه (body) باشه که ورودی‌های لازم برای عملکرد کنترلر رو ارائه می‌ده.

نکات مهم:
- POST به صورت مفهومی "نامحدود" در نظر گرفته شده، به این معنی که این متد می‌تونه هر کاری انجام بده، صرف‌نظر از تکرارپذیری (idempotency) یا عواقب آن. به همین دلیل، POST انتخاب مناسبی برای کنترلرهای تابع‌محور هست که کارکرد مشخصی ندارند.
- از POST نباید برای گرفتن، ذخیره‌سازی یا حذف منابع استفاده بشه، چون HTTP برای هر کدام از این عملیات متدهای خاص خودش رو داره (مثل GET`، `PUT و DELETE).
‏- POST یک متد "unsafe" (ناامن) و "non-idempotent" (غیرتکرارپذیر) در نظر گرفته می‌شه. به این معنا که نتایجش غیرقابل پیش‌بینی و ممکنه تکرارش عواقب ناخواسته‌ای داشته باشه. مثلاً اگر یک فرم وب که از POST استفاده می‌کنه دوباره ارسال بشه، ممکنه باعث شارژ مضاعف کارت اعتباری کاربر بشه.

مثال:
فرض کنید کلاینت می‌خواد یک هشدار را مجدداً ارسال کنه:

POST /alerts/245743/resend

توضیح:
- در اینجا درخواست POST به کنترلر resend مربوط به هشدار مشخص شده (با آی‌دی 245743) ارسال شده تا عملیات ارسال مجدد انجام بشه.

این نوع استفاده از POST شبیه به مکانیزم "PostMessage" در سیستم‌های اجرایی (runtime) هست که به کلاینت اجازه می‌ده عملکردهایی رو از طریق یک مرز (مثل شبکه یا یک سرویس) فراخوانی کنه.


⭕️ متد DELETE باید برای حذف کامل یک منبع از والد خودش (که معمولاً یک مجموعه یا فروشگاه است) استفاده بشه. وقتی یک کلاینت درخواست DELETE می‌فرسته، هدف اینه که منبع مورد نظر به‌طور کامل حذف بشه.

@ninja_learn_ir

نکات کلیدی:
- بعد از پردازش موفقیت‌آمیز درخواست DELETE`، منبع دیگه توسط کلاینت‌ها قابل دسترسی نخواهد بود. یعنی اگر بعداً کلاینت‌ها با استفاده از متدهای `GET یا HEAD سعی کنند وضعیت اون منبع رو بگیرند، باید پاسخ 404 (Not Found) برگرده.
- DELETE در HTTP معنای خاصی داره و نباید توسط طراحی API تغییر داده یا بیش از حد بسط داده بشه. اگر API نیاز به یک حذف "نرم" (soft delete) یا یک تعامل دیگه داره که فقط حالت منبع رو تغییر می‌ده ولی اون رو کاملاً حذف نمی‌کنه، بهتره از یک کنترلر ویژه با متد POST استفاده کنه، نه DELETE.

مثال:
فرض کنید یک کلاینت می‌خواد یک سند رو از یک فروشگاه حذف کنه:

DELETE /accounts/4ef2d5d0-cb7e-11e0-9572-0800200c9a66/buckets/objects/4321

توضیح:
- در اینجا درخواست DELETE برای حذف کامل شیء (document) با شناسه 4321 از داخل یک سطل (bucket) مشخص در حساب کاربری ارسال شده.

پس از موفقیت‌آمیز بودن درخواست، منبع کاملاً حذف می‌شه و هر تلاشی برای دسترسی به اون منبع با پاسخ "Not Found" مواجه می‌شه.

⭕️ متد OPTIONS باید برای دریافت متادیتایی استفاده بشه که تعاملات قابل دسترسی یک منبع رو توضیح می‌ده. کلاینت‌ها می‌تونن از درخواست OPTIONS استفاده کنن تا بفهمند چه متدهایی برای یک منبع در دسترس هستند.

نکات کلیدی:
- پاسخ به درخواست OPTIONS معمولاً شامل هدر Allow است که لیستی از متدهای HTTP قابل اجرا روی منبع رو نشان می‌ده. برای مثال:

    Allow: GET, PUT, DELETE
    

- علاوه بر این، یک API ممکنه در بدنه پاسخ (response body) جزئیات بیشتری درباره هر گزینه تعامل فراهم کنه. این جزئیات می‌تونن شامل فهرستی از فرم‌های ارتباط (link relation forms) باشند که نحوه تعامل با منبع رو نشان می‌دهند.

مثال:
فرض کنید یک کلاینت می‌خواد بفهمه که چه متدهایی روی یک منبع خاص در دسترس هستند:

OPTIONS /accounts/4ef2d5d0-cb7e-11e0-9572-0800200c9a66/buckets/objects/4321

پاسخ:
API ممکنه هدر Allow رو برگردونه که نشون می‌ده کدوم متدها روی منبع مورد نظر قابل استفاده هستند. برای مثال:

Allow: GET, PUT, DELETE

این متد به کلاینت اجازه می‌ده قبل از انجام عملیات، درباره تعاملات ممکن با یک منبع اطلاعات بیشتری کسب کنه.

@ninja_learn_ir

دوستانی که کتاب دیگه مد نظرشون هست کامنت بذارن بعد اینکه این کتابو تموم کردیم کتابی که بیشترین رای رو آورد میذاریم 🌹

#fun

خیلی مخلصیم 🤣

@ninja_learn_ir

📕 کتاب REST API Design Rulebook

📌 فصل سوم: Interaction Design with HTTP

📍پارت: دوم

#کتاب

💎 استاتوس کدهای ریسپانس (Response Status Codes) 💎

‏REST API‌ ها از قسمت Status-Line توی ریسپانس HTTP استفاده می‌کنن تا به کلاینت‌ها نتیجه درخواستشون رو اعلام کنن. استاندارد RFC 2616، ساختار Status-Line رو به این شکل تعریف کرده:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

‏HTTP حدود ۴۰ تا کد وضعیت استاندارد داره که برای بیان نتیجه درخواست‌های کلاینت استفاده میشه. این کدها به ۵ دسته اصلی تقسیم می‌شن که توی جدول زیر توضیح دادم:

⭕️ دسته‌بندی کدهای وضعیت:

1. 1xx: اطلاعاتی – اطلاعاتی در مورد سطح پروتکل انتقال میده.
2. 2xx: موفقیت‌آمیز – درخواست کلاینت با موفقیت قبول شده.
3. 3xx: تغییر مسیر – کلاینت باید یه کار اضافی انجام بده تا درخواست کامل بشه.
4. 4xx: خطای کلاینت – خطاهای این دسته مربوط به اشتباهات کلاینت هست.
5. 5xx: خطای سرور – سرور مسئولیت این خطاها رو قبول می‌کنه.

⭕️ قوانین استفاده از کدهای وضعیت:

⭕️ کد 200 (OK): برای موفقیت کلی
این کد معمولاً همون چیزیه که کلاینت انتظار داره ببینه. یعنی درخواست با موفقیت انجام شده و نیازی به استفاده از کد خاص دیگه‌ای از سری ۲xx نیست. برعکس کد 204، وقتی 200 برگرده، باید یه بدنه پاسخ (response body) هم داشته باشه.

⭕️ کد 200 (OK) نباید برای اعلام خطا استفاده بشه
همیشه باید از کدهای وضعیت HTTP درست استفاده کنید. به‌خصوص، نباید برای سازگار شدن با کلاینت‌های ساده‌تر از قواعد استاندارد API صرف‌نظر کرد.

⭕️ کد 201 (Created): برای ایجاد موفقیت‌آمیز منابع جدید
هر وقت که یه API یه منبع جدید برای درخواست کلاینت ایجاد می‌کنه (مثلاً توی یه کالکشن یا فروشگاه)، باید از کد 201 استفاده کنه. حتی اگر منبع جدید از طریق یه عمل کنترلر ایجاد بشه، باز هم 201 کد درستی برای پاسخ هست.

⭕️ کد 202 ("Accepted") باید برای شروع موفقیت‌آمیز یک عملیات غیرهمزمان استفاده بشه
کد 202 یعنی درخواست کلاینت قراره به صورت غیرهمزمان (آسنکرون) پردازش بشه. این کد به کلاینت میگه که درخواستش معتبر به نظر می‌رسه، اما ممکنه بعداً موقع پردازش به مشکل بخوره. این کد معمولاً برای عملیات‌هایی که زمان زیادی می‌برن استفاده می‌شه.
کنترلرها می‌تونن 202 رو برگردونن، اما منابع دیگه نباید این کار رو بکنن.

⭕️ کد 204 ("No Content") باید زمانی استفاده بشه که بدنه پاسخ (response body) خالیه
کد 204 معمولاً وقتی استفاده میشه که API به درخواست‌های PUT، POST یا DELETE پاسخ میده ولی قصد نداره که توی پاسخ، پیام یا داده‌ای برگردونه.
حتی در پاسخ به درخواست GET هم میشه از 204 استفاده کرد تا بگه منبع درخواست‌شده وجود داره، ولی چیزی برای نمایش نداره.

⭕️ کد 301 ("Moved Permanently") برای تغییر مکان دائمی منابع استفاده بشه
- کد 301 وقتی استفاده میشه که مدل منابع توی API تغییر بزرگی کرده و یه آدرس جدید برای منبع به کلاینت اختصاص داده شده. توی این حالت، آدرس جدید باید توی هدر "Location" به کلاینت اعلام بشه.

⭕️ از کد 302 ("Found") نباید استفاده بشه
کد 302 همیشه اشتباه فهمیده شده و برنامه‌نویسا توی پیاده‌سازیش اشتباه کردن. مشکل اصلی اینجاست که کلاینت‌ها به‌طور خودکار برای آدرس جدید یه درخواست GET می‌فرستن، حتی اگر روش اصلی درخواست چیز دیگه‌ای بوده.
برای رفع این مشکل، توی HTTP 1.1 کدهای 303 ("See Other") و 307 ("Temporary Redirect") معرفی شدن که به جای 302 باید استفاده بشن.

⭕️ کد 303 ("See Other") باید برای ارجاع کلاینت به یه URI دیگه استفاده بشه
وقتی یه کنترلر کارش رو تموم کرده، به جای فرستادن پاسخ توی بدنه‌ای که شاید کلاینت نمی‌خواد، می‌تونه با کد 303 یه URI جدید به کلاینت بده. این URI می‌تونه به یه پیام موقت یا یه منبع دائمی‌تر اشاره کنه.
این کد به API اجازه میده که به جای تحمیل دانلود اطلاعات به کلاینت، یه مرجع به منبع بده و کلاینت اگه بخواد می‌تونه با GET به URI جدید دسترسی پیدا کنه.

⭕️ کد 304 ("Not Modified") باید برای صرفه‌جویی در پهنای باند استفاده بشه
این کد شبیه کد 204 ("No Content") هست چون هیچ چیزی توی بدنه پاسخ نیست، اما تفاوت اصلی اینه که 204 وقتی استفاده می‌شه که هیچ داده‌ای برای فرستادن وجود نداره، ولی 304 وقتی استفاده میشه که منبع اطلاعات داره اما کلاینت قبلاً آخرین نسخه‌اش رو گرفته.
این کد بیشتر توی درخواست‌های HTTP شرطی (conditional requests) کاربرد داره.

@ninja_learn_ir

⭕️ کد 307 ("Temporary Redirect") برای تغییر موقتی مکان درخواست کلاینت استفاده بشه
‏- HTTP/1.1 کد 307 رو معرفی کرد تا کاربرد درست کد 302 ("Found") رو مشخص کنه. وقتی کد 307 برگرده، یعنی API قراره درخواست رو پردازش نکنه و کلاینت باید درخواستش رو به یه URI دیگه که توی هدر "Location" داده شده، بفرسته.
- این کد معمولاً برای اختصاص یه آدرس موقت به درخواست منبع استفاده میشه. مثلاً میشه درخواست رو به یه سرور دیگه انتقال داد.

⭕️ کد 400 ("Bad Request") برای اعلام شکست عمومی درخواست کلاینت استفاده بشه
کد 400 یه خطای کلی سمت کلاینت هست و زمانی استفاده میشه که هیچ کد دیگه‌ای از سری 4xx مناسب نباشه.

⭕️ کد 401 ("Unauthorized") باید زمانی استفاده بشه که مشکلی با اعتبارسنجی کلاینت وجود داره
این کد یعنی کلاینت سعی کرده به یه منبع محافظت‌شده دسترسی پیدا کنه ولی اعتبارنامه مناسب ارائه نداده. ممکنه اعتبارنامه‌ها اشتباه باشن یا اصلاً وجود نداشته باشن.

⭕️ کد 403 ("Forbidden") باید زمانی استفاده بشه که دسترسی به منبع غیرممکنه، فارغ از وضعیت اعتبارسنجی
- این کد یعنی درخواست کلاینت درسته ولی API اجازه انجامش رو نمیده. این موضوع ربطی به مشکل اعتبارنامه‌ها نداره (اون مورد 401 هست).
‏- APIهای REST از 403 برای مدیریت سطح دسترسی‌ها استفاده می‌کنن. مثلاً ممکنه یه کلاینت اجازه دسترسی به بعضی منابع رو داشته باشه ولی نه به همه. اگه کلاینت سعی کنه خارج از محدوده مجازش به منبعی دسترسی پیدا کنه، API باید با 403 پاسخ بده.

⭕️ کد 404 ("Not Found") باید زمانی استفاده بشه که URI کلاینت به منبعی مرتبط نمیشه
کد 404 یعنی API نمی‌تونه URI درخواست‌شده رو به منبعی متصل کنه.

⭕️ کد 405 ("Method Not Allowed") باید زمانی استفاده بشه که روش HTTP پشتیبانی نمیشه
‏- API با کد 405 پاسخ میده تا به کلاینت بگه که از روشی استفاده کرده که برای اون منبع مجاز نیست. مثلاً یه منبع فقط قابل خواندن ممکنه فقط GET و HEAD رو پشتیبانی کنه، ولی یه کنترلر ممکنه GET و POST رو مجاز بدونه اما PUT یا DELETE رو نه.
- پاسخ 405 باید شامل هدر "Allow" باشه که روش‌های مجاز برای اون منبع رو لیست کنه. مثلاً:

Allow: GET, POST

⭕️ کد 406 ("Not Acceptable") باید زمانی استفاده بشه که نوع داده‌ای که کلاینت درخواست داده قابل سرویس‌دهی نیست
- کد 406 یعنی API نمی‌تونه نوع مدیا (media type) درخواستی کلاینت رو ایجاد کنه. مثلاً اگه کلاینت درخواست داده به فرمت application/xml بده و API فقط با application/json کار کنه، کد 406 برمی‌گرده.

⭕️ کد 409 ("Conflict") باید زمانی استفاده بشه که درخواست کلاینت باعث نقض وضعیت منبع بشه
- کد 409 به کلاینت میگه که درخواستش باعث شده منبع API توی حالت ناسازگار یا غیرممکن قرار بگیره. مثلاً اگه کلاینت بخواد یه منبع پرشده رو حذف کنه و اون منبع هنوز داده داره، ممکنه API با 409 پاسخ بده.

⭕️ کد 412 ("Precondition Failed") باید برای پشتیبانی از عملیات‌های شرطی استفاده بشه
- این کد یعنی کلاینت یه سری شرایط رو توی هدر درخواستش مشخص کرده و به API گفته که فقط اگه اون شرایط برقرار باشه درخواستش رو انجام بده. اگه شرایط محقق نشه، API با کد 412 پاسخ میده.

⭕️ کد 415 ("Unsupported Media Type") باید زمانی استفاده بشه که نوع مدیا در payload درخواست قابل پردازش نباشه
- این کد یعنی API نمی‌تونه نوع مدیایی که کلاینت فرستاده رو پردازش کنه. مثلاً اگه کلاینت داده‌ها رو به فرمت application/xml بفرسته ولی API فقط با application/json کار کنه، کد 415 برگردونده می‌شه.

⭕️ کد 500 ("Internal Server Error") باید برای اعلام مشکل داخلی API استفاده بشه
- کد 500 یه خطای عمومی API هست که بیشتر فریم‌ورک‌های وب خودکار این کد رو برمی‌گردونن وقتی که درخواست کلاینت باعث ایجاد یه استثنا توی کد بشه.
- این خطا تقصیر کلاینت نیست، پس کلاینت می‌تونه همون درخواست رو دوباره امتحان کنه و امید داشته باشه که نتیجه متفاوتی بگیره.

@ninja_learn_ir

خب بچه ها فصل 3 هم تموم شد 🎉

از شنبه فصل 4 رو استارت میزنیم ❤️

اگه میخواید برای برنامه نویسی سیستم بگیرید، پست جدیدمون رو از دست ندید 🌹

https://www.instagram.com/p/DAGqMNOM0Np/?igsh=MXgwY3Nwc3V0M2c5dg==

🐇 استفاده از RabbitMQ برای Celery توی جنگو 🥦

امروز می‌خوایم در مورد Celery و RabbitMQ حرف بزنیم و ببینیم چطوری می‌تونیم از این دو تا ابزار خفن برای مدیریت کارهای پس‌زمینه توی Django استفاده کنیم 😎.

حالا Celery چیه؟ 🍃

اگه نمیدونید سلری چیه و چیکار میکنه میتونید به این پست سر بزنید 😉


حالا RabbitMQ چیه؟ 🐇

اگه نمیدونید ربیت ام کیو چیه و چیکار میکنه میتونید به این پست سر بزنید 😉

چرا باید از RabbitMQ برای Celery استفاده کنیم؟ 🧐

1⃣ پایداری و سرعت: RabbitMQ خیلی سریع و پایدار کار می‌کنه و می‌تونه حجم زیادی از پیام‌ها رو مدیریت کنه.

2⃣ مقیاس‌پذیری (Scalability):
اگه پروژه‌ات بزرگ شد، RabbitMQ می‌تونه بدون مشکل تسک‌های بیشتری رو هندل کنه.

3⃣ پشتیبانی از Celery: Celery به خوبی با RabbitMQ سازگاره و به راحتی می‌تونن با هم کار کنن.

چجوری RabbitMQ رو برای Celery توی جنگو تنظیم کنیم؟ 🛠️

خب، بیایید بریم سراغ بخش فنی و ببینیم چطور می‌تونیم از RabbitMQ و Celery توی جنگو استفاده کنیم.

1⃣ نصب RabbitMQ و Celery

اول از همه باید RabbitMQ رو نصب کنی. اگه از اوبونتو استفاده می‌کنی، این دستور رو بزن:

sudo apt-get install rabbitmq-server

حالا Celery رو نصب کن:

pip install celery

2⃣ تنظیمات Celery توی پروژه جنگو

توی پروژه جنگوت، یه فایل جدید به اسم celery.py بساز و تنظیمات Celery رو توش بنویس. این فایل معمولاً توی کنار settings.py قرار می‌گیره.

from __future__ import absolute_import
import os
from celery import Celery

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'your_project.settings')

app = Celery('your_project')

app.config_from_object('django.conf:settings', namespace='CELERY')

app.autodiscover_tasks()

بعد توی فایل init.py پروژه‌ات این خط رو اضافه کن تا Celery لود بشه:

from .celery import app as celery_app

3⃣ تنظیمات RabbitMQ توی settings.py:
توی settings.py، تنظیمات مربوط به RabbitMQ رو به Celery اضافه کن:

CELERY_BROKER_URL = 'amqp://localhost'
CELERY_ACCEPT_CONTENT = ['json']
CELERY_TASK_SERIALIZER = 'json'

4⃣ ساختن تسک‌ها (Tasks)

حالا که تنظیمات انجام شد، می‌تونیم تسک‌های پس‌زمینه رو بسازیم. توی هر اپلیکیشنی که تسک‌ها رو می‌خوای ایجاد کنی، یه فایل tasks.py بساز و تسک‌هات رو توش تعریف کن:

from celery import shared_task

@shared_task
def send_email_task(email_address):
    # کد ارسال ایمیل
    print(f"ایمیل به {email_address} ارسال شد.")

5⃣ اجرای Celery Worker

برای اینکه Celery تسک‌ها رو هندل کنه، Worker راه بندازی. با این دستور می‌تونی Worker رو اجرا کنی:

celery -A your_project worker --loglevel=info

جمع‌بندی 🎯

فهمیدیم RabbitMQ و Celery یه ترکیب عالی برای اجرای تسک‌های پس‌زمینه توی پروژه‌های جنگو هستن. با استفاده از RabbitMQ به‌عنوان message broker و Celery برای مدیریت تسک‌ها، می‌تونی کارهای سنگین و زمان‌بر رو به صورت پس‌زمینه اجرا کنی و تجربه کاربری اپلیکیشن رو بهتر کنی 😎

امید وارم مفید بوده باشه :)

#django #celery #rabbitmq #ambq

@ninja_learn_ir

💎 هدر Authentication چیه و چطوری ازش استفاده کنیم؟ 💎

امروز می‌خوایم درباره هدر Authentication صحبت کنیم، چیزی که اپلیکیشن‌های وب برای احراز هویت (Authentication) استفاده می‌کنن و توی دنیای APIها خیلی کاربرد داره 😎.

هدر Authentication چیه؟ 🤔
هدر Authentication یه هدر HTTP هست که اطلاعات لازم برای احراز هویت کاربر رو توی درخواست‌ها به سرور می‌فرسته. این هدر کمک می‌کنه که سرور بفهمه چه کسی داره درخواست رو می‌فرسته و اینکه اجازه دسترسی به منابع مختلف رو داره یا نه 🔐.

انواع هدر Authentication 🛡️

Basic Authentication 🔑
این ساده‌ترین نوع Authentication هستش. توی این روش، نام کاربری و پسورد به‌صورت base64 رمزگذاری میشن و بعد توی هدر قرار می‌گیرن. نمونه‌ای از هدرش این شکلیه:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

ولی چون اطلاعات رو به‌صورت ساده (حتی با وجود base64) می‌فرسته، خیلی امن نیست و معمولاً توی HTTPS ازش استفاده می‌کنن.


Bearer Token 🏷️
توی این روش، از یه توکن (Token) به‌جای نام کاربری و پسورد استفاده می‌کنن. این توکن معمولاً وقتی کاربر لاگین می‌کنه، از سرور می‌گیره و بعد توی درخواست‌ها به‌عنوان هدر ارسال میشه. هدرش این شکلیه:

Authorization: Bearer your-token-here 

این روش خیلی امن‌تر و محبوب‌تره، مخصوصاً توی API‌های مدرن و استفاده از JWT (JSON Web Tokens).

OAuth 2.0 🔑
این روش بیشتر برای احراز حویت با استفاده از سرویس‌های بزرگی مثل گوگل و فیسبوک استفاده میشه. توی این مدل، شما یه Access Token از طرف سرویس‌دهنده می‌گیرید و بعد اون رو توی هدر می‌فرستید. خیلی شبیه به Bearer Token:

Authorization: Bearer access-token 

چطوری از هدر Authentication استفاده کنیم؟ 💻
فرض کن یه API داری که برای دسترسی به یه سری اطلاعات حساس نیاز به احراز هویت داره. برای اینکه کاربر بتونه به این اطلاعات دسترسی داشته باشه، باید توی درخواستش هدر Authentication رو به‌درستی تنظیم کنه.

مثلاً برای ارسال یه درخواست به API با استفاده از Bearer Token:

curl -H "Authorization: Bearer your-token-here" https://api.example.com/data 

چرا هدر Authentication مهمه؟ 🛠️

1⃣ امنیت اطلاعات:
این هدر به سرور کمک می‌کنه مطمئن بشه که درخواست از یه کاربر معتبر ارسال شده.

2⃣ مدیریت دسترسی:
با استفاده از این هدر، می‌تونی سطح دسترسی‌های مختلف رو برای کاربرها تنظیم کنی. مثلاً بعضی کاربران فقط به بخش‌هایی از اپلیکیشن دسترسی داشته باشن.

3⃣ یکپارچگی با API:
خیلی از APIها مثل REST و GraphQL نیاز دارن که کاربر با ارسال هدر Authentication خودش رو احراز هویت کنه.

جمع‌بندی 🎯
فهمیدیم هدر Authentication یکی از پرکاربردترین ابزارها برای احراز هویت توی وب و APIهاست. روش‌های مختلفی برای استفاده ازش وجود داره، مثل Basic، Bearer Token و OAuth که بسته به نیازت می‌تونی از هرکدومشون استفاده کنی.

امید وارم مفید بوده باشه :)

#authentication #headers #security

@ninja_learn_ir

اگه به عنوان یه برنامه نویس چالش پروژه گرفتن دارید پست جدیدمون رو از دست ندید 😉

https://www.instagram.com/p/DAL0HKZos8Q/?utm_source=ig_web_copy_link&igsh=MzRlODBiNWFlZA==

📕 کتاب REST API Design Rulebook

📌 فصل چهارم: Metadata Design

📍پارت: اول

#کتاب

‏💎 HTTP Headers 💎
توی درخواست و پاسخ‌های HTTP، یه سری اطلاعات متا (Metadata) از طریق هدرهای مختلف منتقل می‌شن. HTTP یه سری هدر استاندارد داره که بعضیاشون درباره منابع درخواست شده اطلاعات میدن. یه سری دیگه نشون میدن که چه نوع دیتایی توی پیام وجود داره. یه تعداد دیگه هم برای کنترل کش (Cache) استفاده میشن.

توی این متن کوتاه چندتا قانون مهم برای استفاده از هدرهای استاندارد HTTP توی طراحی REST API ها پیشنهاد شده.

⭕️ استفاده از Content-Type اجباریه
هدر Content-Type نوع داده‌ای که توی body درخواست یا پاسخ هست رو مشخص می‌کنه. مقدار این هدر یه رشته متنی با فرمت خاصه که بهش "Media Type" گفته میشه. سرور و کلاینت با استفاده از مقدار این هدر متوجه میشن چطوری باید بایت‌های موجود توی بدنه پیام رو پردازش کنن.

⭕️ استفاده از Content-Length توصیه میشه
هدر Content-Length اندازه بدنه پیام (entity-body) رو بر حسب بایت مشخص می‌کنه. این هدر توی پاسخ‌ها مهمه چون دو تا کار رو راحت می‌کنه:
اول اینکه کلاینت متوجه میشه که آیا تعداد بایت‌های درست رو خونده یا نه. دوم اینکه می‌تونه با یه درخواست HEAD بفهمه که اندازه بدنه پیام چقدره بدون اینکه نیاز باشه کل پیام رو دانلود کنه.

⭕️ استفاده از Last-Modified توی پاسخ‌ها توصیه میشه
هدر Last-Modified فقط توی پیام‌های پاسخ استفاده میشه. مقدار این هدر یه timestamp (زمان دقیق) هست که نشون میده آخرین باری که چیزی توی منابع تغییر کرده کی بوده. کلاینت و کش‌های میانی (Cache Intermediaries) می‌تونن از این هدر استفاده کنن تا بفهمن نسخه محلی‌شون از منبع به‌روز هست یا نه. این هدر باید همیشه توی پاسخ به درخواست‌های GET باشه.

⭕️ استفاده از ETag توی ریسپانس ها توصیه میشه
مقدار ETag یه رشته متنی غیرشفافه (opaque) که یه "نسخه" خاص از منبع (Resource) توی body ریسپانس رو شناسایی می‌کنه. body پیام HTTP شامل هدرها و body اصلی پیام میشه. مقدار ETag می‌تونه هر رشته‌ای باشه، به شرطی که وقتی نمایشی از منبع تغییر می‌کنه، مقدارش هم تغییر کنه. این هدر باید همیشه توی پاسخ به درخواست‌های GET ارسال بشه.

کلاینت‌ها می‌تونن مقدار هدر ETag رو ذخیره کنن تا توی درخواست‌های GET بعدی، ازش استفاده کنن؛ به عنوان مقدار هدر شرطی If-None-Match. اگه API تشخیص بده که ETag تغییر نکرده، می‌تونه از ارسال دوباره‌ی بدنه پیام صرف‌نظر کنه و در نتیجه توی زمان و پهنای باند صرفه‌جویی بشه.


@ninja_learn_ir

‏⭕️ store ها باید از درخواست‌های شرطی PUT پشتیبانی کنن
وقتی برای ذخیره یه منبع از متد PUT استفاده می‌کنه (چه برای ایجاد و چه به‌روزرسانی)، ممکنه برای API مشخص نباشه که درخواست کلاینت برای درج داده جدیده یا به‌روزرسانی. اینجاست که HTTP از طریق هدرها ابزار لازم رو در اختیار API میذاره تا این ابهام رو برطرف کنه. برای این کار، API باید به هدرهای شرطی کلاینت مثل If-Unmodified-Since یا If-Match متکی باشه تا منظور دقیق کلاینت رو بفهمه.

هدر If-Unmodified-Since از API می‌خواد که فقط در صورتی عملیات رو انجام بده که از زمانی که توی این هدر مشخص شده، وضعیت منبع تغییری نکرده باشه.

هدر If-Match یه مقدار ETag رو از کلاینت می‌گیره، که از پاسخ قبلی API ذخیره شده. اگه این مقدار ETag با وضعیت فعلی منبع مطابقت داشته باشه، API درخواست PUT رو انجام میده؛ وگرنه درخواست رو رد می‌کنه.

✅ مثال برای درخواست‌های شرطی PUT

فرض کنیم دو کلاینت (کلاینت#1 و کلاینت#2) از یه منبع ذخیره‌ی API با آدرس /objects برای اشتراک‌گذاری اطلاعات استفاده می‌کنن.

کلاینت#1 یه درخواست PUT می‌فرسته تا یه داده جدید توی مسیر /objects/2113 ذخیره کنه. این مسیر قبلاً توی API وجود نداشته، پس API این درخواست رو به‌عنوان "ایجاد" (Insert) تفسیر می‌کنه، منبع جدید رو می‌سازه و با کد 201 ("Created") پاسخ میده.

چند وقت بعد، کلاینت#2 درخواست PUT برای همون مسیر (/objects/2113) می‌فرسته. حالا API این مسیر رو به یه منبع موجود متصل می‌کنه. اما چون اطلاعات کافی نداره که بفهمه آیا کلاینت#2 می‌خواد داده‌ی قبلی رو به‌روزرسانی کنه یا نه، درخواست رو با کد 409 ("Conflict") رد می‌کنه و باید توی بدنه پاسخ هم یه توضیح از خطا بده.

@ninja_learn_ir

اگه کلاینت#2 تصمیم بگیره داده قبلی رو به‌روزرسانی کنه، می‌تونه دوباره درخواست رو با هدر If-Match بفرسته. ولی اگه مقدار ETag توی هدر با مقدار فعلی منبع مطابقت نداشته باشه، API باید با کد 412 ("Precondition Failed") پاسخ بده. اما اگه شرط هدر مطابقت داشته باشه، API باید وضعیت منبع رو به‌روزرسانی کنه و با کد 200 ("OK") یا 204 ("No Content") پاسخ بده.
اگه API یه نمای جدید از وضعیت منبع رو برگردونه، باید هدرهای Last-Modified و ETag رو با مقادیر به‌روزرسانی شده توی پاسخ بذاره.


⭕️ استفاده از Location برای مشخص کردن URI منبع جدید
مقدار هدر Location یه URI هست که منبع جدیدی رو که ممکنه برای کلاینت مهم باشه، شناسایی می‌کنه. وقتی که API یه منبع جدید رو توی یه مجموعه یا فروشگاه ایجاد می‌کنه، باید هدر Location رو توی پاسخ قرار بده تا URI منبع جدید رو مشخص کنه.
توی پاسخ 202 ("Accepted")، این هدر می‌تونه کلاینت رو به وضعیت عملیاتی یه منبع کنترل غیرهمزمان (asynchronous controller) هدایت کنه.

⭕️ از هدرهای Cache-Control، Expires و Date برای کش کردن استفاده بشه
کش کردن یکی از قابلیت‌های مفید HTTP هست که می‌تونه به کاهش تأخیرهای تجربه‌شده توسط کلاینت، افزایش اطمینان‌پذیری، و کاهش بار روی سرورهای API کمک کنه. کش‌ها می‌تونن هر جایی باشن؛ توی شبکه‌ی سرور API، شبکه‌های تحویل محتوا (CDN)، یا حتی شبکه‌ی کلاینت.
وقتی که یه نمایشی از داده رو ارسال می‌کنی، باید هدر Cache-Control رو با مقدار max-age (به ثانیه) قرار بدی تا طول عمر تازگی داده رو مشخص کنی. به عنوان مثال:

Cache-Control: max-age=60, must-revalidate

برای پشتیبانی از کش‌های قدیمی HTTP 1.0، API باید هدر Expires رو با یه تاریخ و زمان انقضا قرار بده. این مقدار برابر با زمانی هست که API داده رو تولید کرده به اضافه‌ی طول عمر تازگی داده. همچنین API باید هدر Date رو با تاریخ و زمانی که پاسخ رو برگردونده، بذاره. این هدر کمک می‌کنه کلاینت‌ها طول عمر تازگی داده رو به‌عنوان اختلاف بین مقادیر Expires و Date محاسبه کنن. به عنوان مثال:

Date: Tue, 15 Nov 1994 08:12:31 GMT
Expires: Thu, 01 Dec 1994 16:00:00 GMT

⭕️ از هدرهای Cache-Control، Expires و Pragma میشه برای جلوگیری از کش استفاده کرد
اگه پاسخ API نباید کش بشه، باید هدر Cache-Control با مقادیر no-cache و no-store قرار بگیره. برای سازگاری با کش‌های قدیمی HTTP 1.0، هدرهای Pragma: no-cache و Expires: 0 هم باید اضافه بشن.


⭕️ کش کردن باید تشویق بشه
استفاده از no-cache باعث میشه هیچ کشی نتونه پاسخ‌های کش شده رو ارائه بده. APIهای REST نباید از این دستور استفاده کنن، مگر اینکه واقعاً ضروری باشه. به‌جای استفاده از `no-cache`، بهتره مقدار کمی برای max-age تنظیم بشه تا کلاینت‌ها بتونن حداقل برای یه مدت کوتاه از نسخه‌های کش شده استفاده کنن، بدون اینکه تازگی داده‌ها به طور قابل توجهی تحت تاثیر قرار بگیره.


⭕️ هدرهای کش‌کردن باید با پاسخ‌های 200 (“OK”) استفاده بشن
تو پاسخ‌های موفقیت‌آمیز GET و HEAD باید هدرهای کش‌کردن انقضا قرار داده بشن. هرچند روش POST هم قابل کش شدنه، اکثر کش‌ها اون رو به عنوان غیرقابل کش در نظر می‌گیرن. نیازی نیست این هدرها رو برای متدهای دیگه تنظیم کنی.

⭕️ هدرهای کش‌کردن می‌تونن به‌صورت اختیاری با پاسخ‌های 3xx و 4xx استفاده بشن
علاوه بر پاسخ‌های موفقیت‌آمیز 200 (“OK”)، می‌تونی تو پاسخ‌های 3xx و 4xx هم هدرهای کش‌کردن اضافه کنی. این کار که بهش کش‌کردن منفی میگن، کمک می‌کنه تا بار ریدایرکت‌ها و خطاها روی API کاهش پیدا کنه.

⭕️ از هدرهای HTTP سفارشی نباید برای تغییر رفتار متدهای HTTP استفاده بشه
هدرهای سفارشی رو میشه فقط برای اطلاع‌رسانی استفاده کرد. کلاینت‌ها و سرورها باید به شکلی پیاده‌سازی بشن که وقتی هدرهای سفارشی مورد انتظار رو پیدا نمی‌کنن، دچار خطا نشن.
اگه اطلاعاتی که توی هدر سفارشی قرار میدی برای تفسیر درست درخواست یا پاسخ ضروریه، بهتره اون اطلاعات رو توی بدنه درخواست یا پاسخ، یا توی URI استفاده کنی. از هدرهای سفارشی برای این کاربردها اجتناب کن.

@ninja_learn_ir