💎 بررسی Zero-day Exploit و چجوری جلوشو بگیریم؟ 💎

امروز می‌خوایم در مورد یکی از خطرناک‌ترین و مرموزترین حملات امنیتی به نام Zero-day Exploit صحبت کنیم. شاید اسمش رو شنیده باشی ولی دقیق ندونی چی هست و چطوری میشه ازش جلوگیری کرد. بزن بریم که توضیح بدم 😎

حالا این Zero-day Exploit چیه؟ 🤔

خب Zero-day Exploit به سوءاستفاده از یه آسیب‌پذیری ناشناخته توی نرم‌افزار، سیستم‌عامل یا حتی سخت‌افزار گفته میشه که توسط توسعه‌دهنده هنوز شناسایی یا اصلاح نشده. از لحظه‌ای که هکر این آسیب‌پذیری رو کشف می‌کنه و قبل از اینکه یه پچ امنیتی برای رفعش ارائه بشه، فرصت داره ازش بهره‌برداری کنه. 💀

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

مثال از Zero-day Exploit

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

چجوری جلوی Zero-day Exploit رو بگیریم؟ 🛡️

1⃣ آپدیت منظم نرم‌افزارها
   آپدیت کردن همیشه مهمه. خیلی از ما آپدیت‌ها رو پشت گوش می‌ندازیم ولی همین آپدیت‌ها معمولاً پچ‌های امنیتی مهمی دارن که می‌تونن جلوی حملات zero-day رو بگیرن. پس همیشه نرم افزار ، سخت افزار یا مروگر رو آپدیت نگه دار. 🔄

2⃣ استفاده از فایروال و آنتی‌ویروس قوی
   یه فایروال و آنتی‌ویروس خوب می‌تونن جلوی حملات مشکوک رو بگیرن یا حداقل هشدار بدن. مثلاً اگه یه برنامه یا فایل مشکوک بخواد از باگی استفاده کنه، آنتی‌ویروس می‌تونه اون رو قرنطینه کنه. 🛡️

3⃣ محدود کردن دسترسی‌ها
   یکی از راه‌های مهم برای کاهش آسیب اینه که همیشه سطوح دسترسی رو محدود کنی. یعنی نرم‌افزارها و کاربران فقط به چیزهایی که واقعاً نیاز دارن دسترسی داشته باشن. اگه هکرها وارد سیستم بشن، محدودیت دسترسی می‌تونه آسیب رو کم کنه. 🚪

4⃣ نظارت و لاگ‌گیری دقیق  
   همیشه باید روی ترافیک شبکه و سیستم‌های خودت نظارت داشته باشی. لاگ‌ها می‌تونن نشون بدن که آیا فعالیت مشکوکی اتفاق افتاده یا نه. اگه چیز غیرعادی دیدی، باید سریع اقدام کنی تا از گسترش حمله جلوگیری کنی. 👁️‍🗨️

5⃣ آموزش به کاربرها
   بیشتر حملات zero-day از طریق ایمیل‌های فیشینگ یا لینک‌های مخرب شروع میشن. آموزش به کاربرها و تیم‌ت در مورد امنیت و خطرات فیشینگ می‌تونه تا حد زیادی جلوی این حملات رو بگیره. کاربران باید بدونن روی هر لینکی کلیک نکنن! 🎣

جمع‌بندی 🎯

فهمیدیم Zero-day Exploit حمله‌ایه که خیلی خطرناکه چون قبل از اینکه فرصتی برای اصلاحش داشته باشیم، هکرها ازش استفاده می‌کنن. اما با آپدیت منظم نرم‌افزارها، استفاده از ابزارهای امنیتی مناسب و محدود کردن دسترسی‌ها می‌تونیم تا حد زیادی از خطراتش جلوگیری کنیم. 🔐

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

#امنیت #ZDE

@ninja_learn_ir

مرسی از دوستانی که تو نظر سنجی شرکت کردن
این گل تقیدم شوما 🌹

💎 پکیج Django Cleanup مدیریت خودکار فایل‌های اضافی 💎

امروز می‌خوام در مورد یه کتابخونه خیلی کاربردی به اسم Django Cleanup صحبت کنم که کلی از مشکلات مربوط به مدیریت فایل‌ها رو توی پروژه‌های جنگو حل می‌کنه. 😎 اگه تا حالا با فایل‌های اضافی و بی‌استفاده دست‌وپنجه نرم کردی، این کتابخونه می‌تونه حسابی به کارت بیاد.

حالا Django Cleanup چیه؟ 🤔
به طور خلاصه، Django Cleanup به صورت خودکار فایل‌ها و تصویرهای ذخیره‌شده توی پروژه رو مدیریت می‌کنه. فرض کن یه فایل یا عکس توی پروژه آپلود کردی و بعد اون رکورد یا مدل رو حذف کردی. معمولاً فایل مرتبط توی سرور باقی می‌مونه و فضای سرور رو اشغال می‌کنه. 😒 Django Cleanup این فایل‌های اضافی رو به صورت خودکار حذف می‌کنه تا دیگه نیاز نباشه خودت دستی این کارو انجام بدی.

چرا Django Cleanup کاربردیه؟ 🤔

1⃣ مدیریت خودکار فایل‌های اضافه 🗑️:

بعد از حذف رکوردهای مدل، فایل‌های مرتبط بهش هم خود به خود حذف میشن.

2⃣ جلوگیری از انباشت فایل‌های اضافی 🚮:

نیازی نیست که خودت دنبال فایل‌های قدیمی بگردی و پاکشون کنی. این کتابخونه همه چیز رو برات مرتب می‌کنه.

3⃣ ساده و راحت در استفاده 🛠️:

فقط با نصب و یه سری تنظیمات ساده، همه چی رو هندل می‌کنه.

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

pip install django-cleanup

بعد از نصب، باید این کتابخونه رو به تنظیمات جنگو اضافه کنی:

INSTALLED_APPS = [
    # بقیه اپ‌ها...
    'django_cleanup.apps.CleanupConfig',
]

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

مثال از استفاده 📂
فرض کن یه مدل ساده برای کاربر داری که یه عکس آپلود می‌کنه:

class UserProfile(models.Model):
    avatar = models.ImageField(upload_to='avatars/')

وقتی یه پروفایل کاربر رو حذف می‌کنی، فایل avatar مربوط به اون کاربر هم به صورت خودکار از پوشه avatars/ پاک میشه و دیگه فضای اضافی نمی‌گیره.

جمع‌بندی
فهمیدیم Django Cleanup یه ابزار خیلی ساده ولی قدرتمنده که کمک می‌کنه پروژه‌هات تمیز و منظم بمونه و از انباشت فایل‌های بی‌استفاده جلوگیری کنی. اگه توی پروژه‌هات با فایل‌های زیادی سروکار داری، حتماً از این کتابخونه استفاده کن تا کارت راحت‌تر بشه 🔥

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

#django #django_clean_up #trick

@ninja_learn_ir

💎 ردیس (Redis) چیه و چرا اینقدر محبوبه؟ 💎

امروز می‌خوام در مورد Redis صحبت کنم. شاید اسمشو شنیده باشی ولی ندونی دقیقاً چیه و چه کاربردی داره. بیاید یه نگاه دقیق‌تر بندازیم به این دیتابیس پرسرعت و جذاب 😎

حالا Redis چیه؟ 🤔

خب Redis یه دیتابیس NoSQL از نوع In-memory هستش. یعنی داده‌ها رو به‌جای اینکه روی دیسک ذخیره کنه، توی RAM نگه می‌داره و این باعث میشه که فوق‌العاده سریع باشه ⚡. به خاطر همین، معمولاً از Redis برای کشینگ (Caching)، مدیریت صف‌ها و ذخیره‌سازی موقت داده‌ها استفاده می‌کنن.

باید بدونید که Redis یه سری ساختار داده‌های پیچیده مثل لیست‌ها، مجموعه‌ها (Sets)، هش‌ها و حتی پایگاه‌داده‌های جفت‌کلید/مقدار رو به شکلی خیلی بهینه پشتیبانی می‌کنه. یعنی هر چی داده لازم داری باهاش کار کنی، Redis از پسش برمیاد 😁

حالا Redis چه کاربردهایی داره؟ 🔥

1⃣ کشینگ (Caching) داده‌ها:
خب Redis برای ذخیره موقت داده‌ها توی کش عالیه. مثلاً می‌تونی نتیجه درخواست‌های API یا کوئری‌های سنگین دیتابیس رو توی Redis ذخیره کنی تا دفعات بعد با سرعت بیشتری بهشون دسترسی داشته باشی 🚀
 
2⃣ مدیریت Sessionها:
توی اپلیکیشن‌های تحت وب، می‌تونی Sessionها رو توی Redis ذخیره کنی. اینجوری سریع و با امنیت بیشتری میشه اطلاعات کاربر رو نگه داشت 🔐

3⃣ مدیریت صف‌ها (Queues):
اگه با صف‌های پردازشی سروکار داری (مثل صف ایمیل‌ها یا پیام‌ها)، Redis به راحتی می‌تونه این صف‌ها رو مدیریت کنه. سرعت و پایداری Redis توی این زمینه بی‌نظیره 📩

4⃣ ذخیره داده‌های Real-time:
مثلا اگه یه اپ چت یا اپلیکیشنی که نیاز به پردازش ریل تایم داره، Redis بهترین انتخابه چون داده‌ها رو خیلی سریع مدیریت می‌کنه 🕒

چرا Redis اینقدر سریع و محبوبه؟ ⚡

1⃣ اول In-memory بودنش:
چون داده‌ها رو توی RAM نگه می‌داره، دسترسی بهشون خیلی سریعه.

2⃣ دوم پشتیبانی از ساختار داده‌های متنوع: برخلاف دیتابیس‌های سنتی، Redis ساختارهای پیشرفته‌ای مثل لیست‌ها، هش‌ها و مجموعه‌ها رو پشتیبانی می‌کنه.

3⃣ سوم سادگی در استفاده:
نصب و راه‌اندازیش خیلی راحته و استفاده از دستوراتش هم سرراست و ساده‌ست.

4⃣ چهارم پشتیبانی از Replication و Persistence:
یعنی می‌تونی داده‌ها رو بین چندین سرور کپی کنی یا اگه خواستی داده‌ها رو به دیسک هم بنویسی تا در صورت قطعی سیستم از بین نرن.

حالا چطوری Redis رو نصب و راه‌اندازی کنیم؟ 🛠️

برای نصب Redis، فقط کافیه که از دستورات زیر استفاده کنی:

روی اوبونتو:

sudo apt update
sudo apt install redis-server

بعد از نصب، Redis به طور پیش‌فرض روی پورت 6379 در حال اجراست. می‌تونی با دستور زیر مطمئن بشی که Redis درسته اجرا شده:

redis-cli ping

اگه جواب PONG رو گرفتی، یعنی Redis داره به درستی کار می‌کنه 👌

جمع‌بندی ✅

فهمیدیم Redis یه دیتابیس خیلی قدرتمند و پرسرعته که بیشتر برای کشینگ، مدیریت صف‌ها و داده‌های ریل تایم استفاده میشه. با استفاده ازش می‌تونی سرعت اپلیکیشن‌هات رو چند برابر کنی و از ساختار داده‌های پیچیده و کاربردی بهره ببری 😎

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

#redis

@ninja_learn_ir

💎 حمله CSRF و چطوری ازش جلوگیری کنیم؟ 💎

امروز می‌خوایم در مورد یکی از حملات معروف تو دنیای وب، یعنی CSRF یا همون Cross-Site Request Forgery صحبت کنیم.

حالا CSRF چیه؟ 🤔

خب CSRF یه جور حمله‌ست که هکر سعی می‌کنه با سوءاستفاده از سشن (session) کاربر، کارهایی رو به نمایندگی از کاربر انجام بده بدون اینکه اون کاربر خبر داشته باشه 😱. یعنی اگه کاربر توی یه سایت لاگین کرده باشه (مثل یه بانک یا شبکه اجتماعی) و بعد روی لینک یا دکمه‌ای توی یه سایت دیگه کلیک کنه، هکر می‌تونه درخواست‌هایی رو به سایت اصلی (که کاربر لاگین کرده) بفرسته و کارهایی مثل انتقال پول یا تغییر اطلاعات کاربر رو انجام بده.

چجوری این حمله کار می‌کنه؟ 🎯

1️⃣ کاربر لاگین می‌کنه:
مثلا کاربر وارد حساب بانکی خودش میشه و یه سشن معتبر داره.

2️⃣ هکر یه لینک مخرب می‌سازه:
یه هکر توی یه سایت دیگه یه لینک یا فرم مخرب می‌سازه که درخواست‌هایی رو به حساب کاربر توی سایت بانکی ارسال می‌کنه.

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

4️⃣ هکر درخواست‌ها رو اجرا می‌کنه:
سرور چون کاربر لاگین کرده، درخواست رو معتبر می‌دونه و اون کار انجام میشه (مثل انتقال پول، تغییر پسورد و...)

چجوری میشه جلوی CSRF رو گرفت؟ 🛡️

1️⃣ استفاده از CSRF Token
هر وقت کاربر یه فرم رو پر می‌کنه یا عملیاتی رو انجام میده، سرور یه توکن منحصربه‌فرد به فرم اضافه می‌کنه. این توکن رو سرور چک می‌کنه تا مطمئن بشه درخواست از طرف خود کاربر ارسال شده نه یه سایت دیگه. جنگو، فلکس و خیلی از فریمورک‌های معروف به صورت پیش‌فرض از این مکانیزم پشتیبانی می‌کنن 🔑.

2️⃣ استفاده از روش POST به جای GET
برای درخواست‌هایی که نیاز به تایید کاربر دارن (مثل انتقال پول یا تغییر اطلاعات)، از POST استفاده کن، نه GET. توی درخواست‌های GET داده‌ها توی URL قرار می‌گیرن که راحت‌تر میشه ازشون سوءاستفاده کرد. با POST درخواست‌ها ایمن‌تر میشن 🛠️.

3️⃣ محدود کردن Referer Header
   سرورها می‌تونن Referer header رو چک کنن تا مطمئن بشن که درخواست‌ها از یه منبع قابل اعتماد (مثلاً همون سایت خودت) ارسال شدن نه از یه سایت دیگه‌ای که هکرها توش لینک مخرب گذاشتن. اینجوری درخواست‌های مشکوک رد میشن 🚫.

4️⃣ استفاده از Double Submit Cookies
  
   یه راه دیگه برای جلوگیری از CSRF اینه که هم از کوکی‌ها و هم از پارامترها استفاده کنی. توی این روش، یه کوکی حاوی CSRF token ارسال میشه و سرور مطمئن میشه که درخواست معتبره.

5️⃣ لاگ‌اوت خودکار
  
   اگه کاربر برای مدت زیادی هیچ فعالیتی توی سایت نداشت، اونو به صورت خودکار از سیستم خارج کن. اینجوری خطر CSRF کمتر میشه چون سشن کاربر خیلی طولانی باز نمی‌مونه ⏳.

جمع‌بندی ✅

فهمیدیم CSRF یه حمله جدیه که اگه درست ازش جلوگیری نشه، می‌تونه خیلی از اطلاعات حساس رو به خطر بندازه. با استفاده از CSRF Token، چک کردن Referer header و بقیه روش‌هایی که گفتیم، می‌تونی از اپلیکیشن‌هات در برابر این حمله محافظت کنی و امنیتشون رو بالا ببری 💪.

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

#csrf #امنیت

@ninja_learn_ir

قسمت ۱۹ دوره 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