متد Get و Post ای جکس در جی کوئری

Ajax به صفحه وب اجازه می دهد بخشی از اطلاعات را از سرور دریافت یا برای آن ارسال کند، بی آنکه مرورگر مجبور شود تمام صفحه را دوباره بارگذاری کند. در jQuery، متدهای کوتاه و خوانایی مانند $.get() و $.post() برای ساخت این درخواست ها در دسترس هستند.

متد GET معمولا زمانی استفاده می شود که هدف، دریافت اطلاعات از سرور باشد؛ برای نمونه، خواندن فهرست محصولات یا دریافت جزئیات یک مقاله. داده های همراه درخواست GET معمولا در نشانی یا query string قرار می گیرند، بنابراین نباید اطلاعات محرمانه را در آن ها گذاشت.

نمونه زیر محتوای پاسخ سرور را دریافت می کند. آرگومان اول نشانی فایل یا مسیر API است و تابع callback پس از دریافت موفق پاسخ اجرا می شود:

$.get("test.php", function(data) {
  console.log(data);
});

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

تابع موفقیت معمولا داده دریافتی از سرور را به عنوان آرگومان نخست دریافت می کند. در امضای callback، آرگومان های دیگری نیز ممکن است در دسترس باشند؛ از جمله وضعیت درخواست و شیء jqXHR. این اطلاعات برای ثبت گزارش، نمایش پیام مناسب یا بررسی جزئیات پاسخ مفید هستند.

در نمونه های قدیمی، وضعیت هایی مانند success، error، timeout و parsererror در توضیح نتیجه درخواست دیده می شوند. نام و جزئیات وضعیت ها به روش استفاده از Ajax و نسخه کتابخانه وابسته است؛ بنابراین برای مدیریت کامل خطا، از زنجیره های .done() و .fail() نیز می توان استفاده کرد.

نمونه زیر پاسخ موفق و خطای درخواست را جداگانه مدیریت می کند:

$.get("test.php", { page: 1 }, "json")
  .done(function(data) {
    console.log("پاسخ دریافت شد:", data);
  })
  .fail(function(jqXHR, textStatus, errorThrown) {
    console.error("درخواست ناموفق بود:", textStatus, errorThrown);
  });

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

متد POST زمانی کاربرد دارد که لازم باشد داده ای برای پردازش به سرور ارسال شود؛ مانند ثبت فرم، ایجاد یک نظر یا ذخیره تنظیمات. شیوه ارسال داده با GET تفاوت دارد و مقادیر معمول آن در بدنه درخواست قرار می گیرند، نه در query string نشانی.

POST به تنهایی داده را رمزنگاری یا ایمن نمی کند. برای محافظت از اطلاعات در مسیر انتقال، استفاده از HTTPS ضروری است و برنامه سمت سرور نیز باید اعتبارسنجی، مجوز دسترسی و کنترل های امنیتی لازم را انجام دهد.

قالب ساده متد در jQuery به شکل زیر است. نام تابع صحیح $.post() است و برخلاف برخی نمونه های نادرست، آن را به شکل متد یک selector مانند $(selector).post() فراخوانی نمی کنیم:

$.post(URL, data, success, dataType);

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

اگر درخواست فقط برای خواندن اطلاعات است و پارامترها کوچک و غیرمحرمانه هستند، GET معمولا انتخاب روشن تری است. امکان مشاهده پارامترها در نشانی، اشتراک گذاری یا ذخیره برخی درخواست های خواندنی را ساده می کند؛ البته نباید فرض کرد هر درخواست GET در همه شرایط ذخیره یا قابل اشتراک گذاری است.

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

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

POST داده را در بدنه درخواست می فرستد و برای ارسال حجم بیشتر انعطاف پذیرتر است؛ اما این به معنای نامحدود بودن حجم یا امن بودن خودکار آن نیست. محدودیت اندازه درخواست باید در سرور تنظیم شود و انتقال اطلاعات حساس باید با HTTPS محافظت شود.

GET در کاربرد معمول برای خواندن داده استفاده می شود و بهتر است فراخوانی آن باعث تغییر ناخواسته وضعیت سرور نشود. POST معمولا برای عملیاتی به کار می رود که داده ای را ایجاد یا پردازش می کنند. این تمایز به خوانایی API و پیش بینی رفتار درخواست ها کمک می کند.

برای مثال، فیلتر کردن فهرست محصولات می تواند با GET انجام شود؛ اما ایجاد یک سفارش جدید معمولا با POST صورت می گیرد. اگر endpoint در مستندات روش دیگری را تعریف کرده است، همان قرارداد را رعایت کنید تا درخواست از سوی سرور رد نشود.

پارامترهای GET ممکن است در نوار نشانی، تاریخچه مرورگر، گزارش های سرور یا ابزارهای واسط ثبت شوند. بنابراین رمز عبور، کلید خصوصی یا اطلاعات شخصی حساس را در query string قرار ندهید. برای انتقال داده حساس از روش مناسب، HTTPS و کنترل های امنیتی سمت سرور استفاده کنید.

اگر فقط callback موفقیت تعریف شود، خطاهایی مانند قطع اتصال، پاسخ نامعتبر یا خطای سرور ممکن است بدون پیام مناسب باقی بمانند. زنجیره .fail() یا سازوکار مدیریت خطای متناسب با نسخه jQuery را به کار ببرید و پیام قابل فهمی به کاربر نشان دهید.

اگر کد انتظار JSON داشته باشد اما سرور HTML یا متن نامعتبر برگرداند، پردازش پاسخ با مشکل روبه رو می شود. نوع داده مورد انتظار را با خروجی واقعی سرور هماهنگ کنید و پاسخ را در ابزار شبکه مرورگر بررسی کنید؛ حدس زدن قالب پاسخ جای بررسی قرارداد API را نمی گیرد.

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

متدهای GET و POST در jQuery Ajax هر دو برای ارتباط صفحه با سرور کاربرد دارند، اما هدف یکسانی ندارند. GET برای دریافت داده و ارسال پارامترهای غیرحساس مناسب است؛ POST معمولا برای فرستادن داده جهت ثبت یا پردازش به کار می رود. انتخاب نهایی باید با رفتار endpoint و قرارداد سمت سرور هماهنگ باشد.

پیش از پیاده سازی، نوع داده، حجم آن، قالب پاسخ و نحوه مدیریت خطا را مشخص کنید. اطلاعات حساس را در URL قرار ندهید، از HTTPS بهره ببرید و اعتبارسنجی سمت سرور را فراموش نکنید. رعایت این نکته ها باعث می شود درخواست های Ajax قابل فهم تر، قابل نگهداری تر و مناسب تر برای تجربه کاربری باشند.

• GET: برای دریافت اطلاعات و جست وجوی معمولی از آن استفاده کنید.
• POST: برای ارسال داده جهت پردازش یا ثبت، آن را با قرارداد API هماهنگ کنید.
• پاسخ: قالب واقعی داده و نوع مورد انتظار را یکسان نگه دارید.
• خطا: شکست درخواست را مدیریت کنید و پیام مناسبی نمایش دهید.
• امنیت: HTTPS و اعتبارسنجی سمت سرور را بخشی از پیاده سازی بدانید.