idempotent چیست؟

Idempotent از مفاهیمی است که به احتمال خیلی زیاد توی روند توسعه RESTful API بهش برمیخورید ولی قبل از خوندن ادامه مقاله نیازه که با مفاهیم API و RESTful API آشنا باشید اگر نیستید این دو مقاله رو برای درک بهتر مطالعه کنید:

• 1. API چیست؟
• 2. RESTful API چیست؟

در توسعه وب سرویس های RESTful، مفهموم Idempotent به این معنیه که چندین درخواست یا Request یکسان به یک API، همون نتیجه و اثری رو داشته باشه که یک درخواست یا Request داره و درخواست های اضافی باعث تغییر در وضعیت پاسخی که دریافت میشه نداشته باشن.

نتیجه ای که از مفهوم Idempotent به طورکلی میتونیم داشته باشیم اینه که تاثیر یک Request موفقیت آمیز روی Resource یا منابع سرور مستقل از تعداد دفعات Request است.

مثال: شما با متد GET یک سری data رو از سرور درخواست میکنید:

GET /api/blog/articles

پاسخ دریافتی از سمت سرور:

[
    {
        "id": 1,
        "title": "title 1",
        "slug": "slug-1",
        "author": "author 1"
    },
    {
        "id": 2,
        "title": "title 2",
        "slug": "slug-2",
        "author": "author 2"
    }
]

حالا شما این درخواست هر چند بار که به سرور بفرستید همون جوابی رو میگیرید که بار اول گرفتید پس میتونیم بگیم متد GET یک متد Idempotent است.

متد HTTP ای که صرف نظر از اینکه چندبار فراخوانی بشه، همون نتیجه اول رو بده، یک متد Idempotent است. مهم اینه که با تغییر کردن تعداد درخواست نتیجه همیشه یکسان باشه و تغییر نکنه.

نکته مهم: همین طور که در تصویر بالا میبینید فقط متد های POST و PATCH جزء متد های Idempotent نیستند.

نکته: یک متد دیگر به اسم TRACE هم داریم که معمولا توی حالت Development برای دیباگ کردن به کار میره و جزء متدهای Idempotent است.

وقتی که شما از اصول REST پیروی میکنید به صورت اتوماتیک متد های GET, PUT, DELETE, HEAD, OPTIONS، TRACE به شکل Idempotent هستند.

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

پس میشه نتیجه گرفت که GET، HEAD، OPTIONS، TRACE جزء متد های Idempotent هستند.

به طورکلی متد POST برای ایجاد کردن داده یا منبع (Resource) جدید در سرور به کار میره (البته لزوما همیشه متد POST فقط برای ایجاد کردن منبع جدید به کار نمیره و کاربرد های دیگه ای هم داره).

اگر شما N بار با متد POST به سرور درخواست بفرستید N تا منبع جدید در سرور ایجاد میشه و شرط Idempotent بودن اینه که Request های یکسان یک اثر و نتیجه رو داشته باشن پس نتیجه می گیریم که متد POST، یک متد Idempotent نیست.

متد PATCH برخلاف متد PUT کل منبع رو جایگزین نمی کنه بلکه بخش یا بخش هایی از یک منبع بخصوص رو طبق یکسری دستورات تغییر میده.

مثال: فک کنید توی یک منبع میخواید مقدار age رو تغییر بدید (مقدار اولیه 20 است) و بگید که مقدار این داده رو 5 تا افزایش بده پس:

-بار اول: age = 20 + 5 = 25

-بار دوم: age = 25 + 5 = 30

-بار سوم: age = 30 + 5 = 35

همین طور که میبینید طی هر درخواست نتیجه ی متفاوتی رو داره پس به طورکلی متد PATCH جزء متد های Idempotent نیست.

نکته: اگر توی مثال بالا دستور ما این باشه که مقدار age برابر با 30 بشه پس توی درخواست تکراری نتیجه ای که میگیریم یکسان میشه که باعث میشه متد PATCH یک متد Idempotent باشه ولی چون معمولا منطق دستوراتی که طی متد PATCH اجرا می کنیم همچین منطقی ندارن پس به طورکلی متد PATCH رو Idempotent حساب نمی کنن.

متد PUT به طورکلی برای آپدیت کردن یک منبع به کار میره و وقتی که شما N تا درخواست با متد PUT به سمت سرور ارسال میکنید فقط درخواست اول منبع سمت سرور رو آپدیت میکنه و تمام درخواست های N -1 (درخواست اول رو از کل درخواست ها کم کردیم) بعد از اون فقط همین حالت منبع به صورت تکراری بازنویسی میکنن پس نتیجه میگیریم که متد PUT هم یک متد Idempotent است.

این متد که برای حذف منبع به کار میره و به طورکلی متد DELETE هم Idempotent حساب میشه ولی میتونیم در دو حالت بررسیش کنیم:

در این روش که متداول تر هم است شما منبع بخصوصی که قرار حذف بشه رو مشخص می کنید. در مثال قراره مقاله ای با شناسه (اینجا id مقالس) 6 حذف بشه:

DELETE /api/blog/articles/6

وقتی شما N بار با این متد Request بزنید، توی درخواست اول منبع مد نظر حذف میشه و Status Code که دریافت می کنید 200 (OK) یا 204 (No Content) است و درخواست های بعدی (N -1) شما 404 (Not Found) دریافت می کنه چون منبع مد نظر توی همون درخواست اول حذف شده پس درخواست هایی غیر از درخواست اول به منبعی اشاره می کنند که دیگه وجود نداره.

درسته که پاسخی یا کد وضعیتی که طی درخواست اول گرفتیم با درخواست های بعدی متفاوت بود ولی در سمت سرور طی درخواست های مختلف تغییری به وجود نمیاد پس اینجا متد DELETE یک متد Idempotent محسوب میشه.

در این روش ما توی درخواستمون منبع بخصوصی رو با شناسه هدف قرار نمیدیم به عنوان مثال قراره طی درخواستی که می زنیم آخرین مقاله از سرور حذف بشه:

DELETE /api/blog/articles/last

توی این مثال منطق API این بوده که هر بار آخرین مقاله حذف بشه پس طی هر درخواست داره یک مقاله متفاوت حذف میشه پس ما نتیجه و اثر یکسانی از Request هامون نگرفتیم پس اینجا متد DELETE یک متد Idempotent محسوب نمیشه.

نکته:از اونجایی که حالت اول برای متد DELETE متداول تره به طور کلی متد DELETE رو جرء متدهای Idempotent حساب میکنن.