‏Idempotent & Safe methods در HTTP 🌐

‏دو مفهوم مهم HTTP که خیلی وقت‌ها با هم اشتباه گرفته می‌شن: Safe و Idempotent.


‏SAFE METHOD 🛡
‏یه متد وقتی Safe (ایمن) محسوب می‌شه که هدف اصلی ریکوئست فقط خوندن اطلاعات باشه و منجر به تغییر معنادار و عمدی resource نشه.

‏مثلا:

GET /users/1

‏اینجا فقط اطلاعات کاربر رو می‌خونیم. پس GET یه متد safe محسوب می‌شه.

‏البته سرور ممکنه برای این ریکوئست لاگ یا کش ایجاد کنه. این‌ها safe بودن GET رو نقض نمی‌کنن. چون منظور از تغییر، تغییر هدفمند و عمدی هست. مثل عوض کردن نام کاربر.

‏HEAD و OPTIONS هم safe هستن.
اما POST و PUT و PATCH و DELETE برای ایجاد تغییر طراحی شدن.


‏IDEMPOTENT METHOD 🔄
‏idempotent (هم توان؟!) بودن یعنی اگر یه ریکوئست رو چند بار اجرا کنیم اثر نهایی اون روی سرور با اجرای یک‌باره‌ ریکوئست یکسان باشه.

‏به زبون ریاضی:
f(f(x)) = f(x)

‏مثلا ‏اگر این ریکوئست رو هزار بار هم بفرستیم، در نهایت داریم: name = awat

PUT /users/1

{
    "name": "awat"
}

‏پس PUT با اینکه safe نیست، idempotent هست.

‏DELETE هم idempotent محسوب می‌شه:

DELETE /users/1

‏بار اول کاربر حذف می‌شه. ریکوئست‌های بعدی ممکنه 404 برگردونن، اما وضعیت نهایی همچنان اینه که کاربر حذف شده. دقیقا مثل دفعه اول.

‏مشخصه که همه متدهای safe تو دسته idempotentها هم قرار میگیرن.


‏و یه نکته مهم 🧨
‏idempotency فقط به اسم متد وابسته نیست. نحوه‌ پیاده‌سازی اندپوینت هم اهمیت داره.

‏مثلا

PUT /users/1

{
    "operation": "increment_age"
}

‏هر بار که ریکوئست رو می‌فرستیم یه واحد به سن اضافه میشه.

‏اینجا اجرای دوباره ریکوئست، اثر جدیدی ایجاد می‌کنه؛ بنابراین این عملیات idempotent نیست.

‏البته گفتیم HTTP متد PUT رو idempotent معرفی کرده. پس این اندپوینت درست طراحی نشده و برای این عملیات بهتره از PATCH استفاده کنیم.

حالا‏ خود PATCH تو کدوم دسته‌ست؟
ضمانت ‏خاصی براش نداریم. این موضوع به نحوه طراحیمون بستگی داره.

‏مثلا این یه عملیات idempotent هست:

PATCH /users/1

{
    "name": "awat"
}

‏اما اگر همچین اندپوینتی داشته باشیم:

PATCH /users/1

{
    "operation": "increment_age"
}

‏نتیجه می‌شه:
18 >> 19 >> 20

‏پس non-idempotent محسوب میشه.


‌‏POST و خطر Retry ☠️
‏POST رسما idempotent تعریف نشده. این موضوع تو عملیات‌های حساسی مثل تراکنش اهمیت زیادی داره.

‏مثلا:

POST /payments

{
    "amount": 100
}

‏فرض کنید پرداخت با موفقیت انجام می‌شه، اما به هر دلیلی کلاینت برای همین پرداخت دوباره درخواست بفرسته.

‏اگر سرور این دو ریکوئست رو دو تراکنش متمایز در نظر بگیره، مبلغ دو بار از موجودی کاربر کسر میشه.

‏برای جلوگیری از این مشکل می‌تونیم از idempotency key داخل هدر استفاده کنیم:

POST /payments
Idempotency-Key: abc123

{
    "amount": 100
}

‏سرور این کلید و نتیجه تراکنش رو ذخیره می‌کنه. اگر همون ریکوئست دوباره با کلید "abc123" فرستاده شه (retry)، سرور به جای انجام دوباره تراکنش، نتیجه قبلی رو برمی‌گردونه.

البته این کلید باعث نمیشه POST ماهیت idempotent بگیره؛ ما با این مکانیزم صرفا یه عملیات مشخص رو در برابر ریکوئست‌های تکراری مقاوم می‌کنیم.


‏پس دو سوال متفاوت داریم:
‏Safe:

‏هدف از طراحی این عملیات تغییر عمدی در سرور بوده؟

‏Idempotent:

‏اگر همین ریکوئست رو دوباره بفرستیم، وضعیت نهایی سرور مثل نتیجه اجرای اول باقی می‌مونه؟

مطالعه بیشتر در MDN 🤓
Safe
Idempotent
Idempotency-Key header


@awat_dev

Summer has ended, you know what`s coming

Winter is coming...

@awat_dev

از این به بعد هر کی به جاوااسکریپت بگه جاوا ، ارجاع داده میشه دادگاه برنامه‌نویسی — شعبه فرانت‌اند


کمترین حکم:

روزی ۱۰۰ بار بنویسه:

console.log("JavaScript");

@awat_dev

سه تا از مخرب ترین حملات سایبری تاریخ

∆ نوت‌پتیا توسط روسیه در 2017

شرکت‌های اوکراینی از یه نرم‌افزار حسابداری به اسم M.E.Doc استفاده می‌کردن. هکرها این نرم‌افزار رو هک کردن و از طریق آپدیتش، ویروس رو پخش کردن، ده میلیارد دلار خسارت جهانی وارد شد و شبکه یکی از غول های کشتیرانی در هفت دقیقه نابود شد

∆ استاکس‌نت توسط آمریکا و اسرائیل علیه ایران 2010

یه فلش مموری توسط یک مهندس ایرانی به کامپیوترهای نطنز وصل شد و ویروس منتقل شد.
حدود ۱۰۰۰ سانتریفیوژ رو از کار انداخت و روند غنی‌سازی اورانیوم رو متوقف کرد.
سیستم طوری دستکاری شده بود که اپراتورها همه چیز عادی می‌دیدن، در حالی که سانتریفیوژها داشتن خراب می‌شدن.



∆ کولونیال پایپ‌لاین احتمالا توسط روسیه 2021

بزرگ‌ترین خط لوله سوخت آمریکا هک شد. از یه VPN قدیمی بدون احراز هویت دو مرحله‌ای وارد شدند.
کل خط لوله تعطیل شد، کمبود بنزین و وضعیت اضطراری در ۱۷ ایالت.
۴.۴ میلیون دلار باج پرداخت شد.

@awat_dev

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

کد هایی که می‌زنید رو درک کنید نه اینکه اونارو حفظ کنید، قرار نیست سینتکس تک تک متُد ها یا ویژگی های HTML و CSS رو از بر باشید.

چیزی که شما رو از یه کد نویسِ کپی کن جدا می‌کنه اینه که بدونید:

° چرا این کد رو نوشتید
° این کد چه کاری واستون انجام میده
° کِی و کجا ازش استفاده میشه

ممکنه فردا سینتکس یه متد رو یادتون نباشه؛ مهم نیست، سرچش می‌کنید. اما اگه منطق پشت کد رو نفهمیده باشید،
با عوض شدن پروژه، مشکل همچنان همراهتونه.


برنامه‌نویسی حفظ کردن کد نیست؛
برنامه‌نویسی یعنی یاد بگیری چطور فکر کنی و چطور مسئله رو تحلیل کنی که پس فردا به باگ های فضایی خوردی بتونی از پسشون بر بیای.


@awat_dev

برنامه ریزی که باید انجام بشه متناسب با هر شخص متفاوت میتونه باشه ، یکی توانش بالاتره میتونه هم درس رو هندل کنه و هم کارهای برنامه نویسی رو ، یکی یکم بازدهی کمتری داره و خیلی کم میتونه به برنامه نویسی بپردازه ، و یکیم کلا نمیتونه برنامه نویسی کنه ، ولی ولی ولی ، کلا تایم شما در 3 مقطع خلاصه میشه :
دهم
یازدهم
دوازدهم

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



من خودم به شخصه رشتم ریاضی هست و الان دارم برای کنکور میخونم ، دوست داشتم که بدونید فشاری که در دوازدهم میاد بالا هست ، البته واسه رشته های نظری دارم میگم مثل ریاضی ، تجربی و انسانی که هر سه تا رشته های تاپی هستن به نوبه خودشون ، واسه تک تک شما ها ارزوی موفقیت میکنم ، یادتون نره که اگر سوالی درباره کنکور داشتید حتما داخل بخش گپ کانال بپرسید ، منتظر سوالات قشنگ شما هستیم ❤️


@awat_dev

نسخه آلفا Bootstrap 6 منتشر شد

سیستم تم دهی عوض شده
متغیر های Sass حذف شدن و‌جاشون CSS variables اومده

کلاس های ریسپانسیو سازی تغییرات ریزی داشته

کتابخانه jQuery هم حذف شده


@awat_dev