GET এবং POST HTTP অনুরোধ পদ্ধতির মধ্যে প্রধান পার্থক্য কি?

উদ্দেশ্য

• GET একটি সম্পদের প্রতিনিধিত্বের অনুরোধ করে। স্পেসিফিকেশন দ্বারা এটি শুধুমাত্র পঠনযোগ্য: ক্লায়েন্ট কোনো সার্ভারের অবস্থার পরিবর্তন আশা করে না। RFC 9110 নোট করে যে একটি GET অনুরোধে একটি বডি পাঠানোর অনির্ধারিত শব্দার্থ আছে, তাই GET একটি বডি বহন করবে না।
• POST সেই রিসোর্সের নিজস্ব শব্দার্থবিদ্যা (একটি রেকর্ড তৈরি করুন, একটি ফর্ম জমা দিন, একটি ফাইল আপলোড করুন, ইত্যাদি) অনুযায়ী অনুরোধের বডিতে সংযুক্ত ডেটা প্রক্রিয়া করতে টার্গেট রিসোর্সকে বলে৷

ডাটা কোথায় যায়

• GET URL ক্যোয়ারী স্ট্রিং-এ প্যারামিটার বহন করে (? এর পরে, key=value&... হিসাবে ফর্ম্যাট করা হয়েছে)। এগুলি ঠিকানা বারে দৃশ্যমান এবং ব্রাউজার ইতিহাস এবং সার্ভার লগগুলিতে রেকর্ড করা হয় এবং একটি ব্যবহারিক URL-দৈর্ঘ্য সীমা দ্বারা আবদ্ধ৷
• POST অনুরোধের অংশে ডেটা বহন করে; টাইপ Content-Type হেডার দ্বারা প্রদত্ত। HTML ফর্মগুলি সাধারণত application/x-www-form-urlencoded (ডিফল্ট) বা multipart/form-data (ফাইলের জন্য) ব্যবহার করে। কোন নির্দিষ্ট প্রোটোকল-স্তরের আকারের সীমা নেই, কিন্তু সার্ভার এবং প্রক্সিগুলি তাদের নিজস্ব সর্বোচ্চ কনফিগার করে (যেমন Nginx client_max_body_size )।

RFC 9110 প্রতি বৈশিষ্ট্য

• নিরাপদ: GET নিরাপদ (শুধু পড়ার জন্য); POST নয়।
• আদমশক্তিসম্পন্ন: একটি অনুরোধ যদি এটিকে N বার করা সার্ভারের অবস্থাতে একবার করার মতো একই প্রভাব ফেলে তবে তা অদম্য। GET অক্ষমতা; POST নয় — এটি পুনরাবৃত্তি করলে সদৃশ তৈরি হতে পারে, যেমন দুটি অভিন্ন অর্ডার। ইডেমপোটেন্ট নিরাপদ নয় (PUT এবং DELETE ইমপোটেন্ট কিন্তু নিরাপদ নয়), এবং এটি প্রতিক্রিয়া বডি অভিন্ন হওয়ার বিষয়ে কিছুই বলে না।
• ক্যাশেযোগ্য: GET প্রতিক্রিয়াগুলি ডিফল্টরূপে ক্যাশেযোগ্য; POST প্রতিক্রিয়াগুলি কেবল তখনই ক্যাশেযোগ্য হয় যখন সেগুলিতে স্পষ্ট তাজা তথ্য এবং একটি ম্যাচিং Content-Location হেডার অন্তর্ভুক্ত থাকে, যা অনুশীলনে বিরল৷

ব্যবহারিক প্রভাব

• পুনরুদ্ধার এবং নেভিগেশন জন্য GET ব্যবহার করুন; ফলাফলগুলি নিরাপদে পুনরাবৃত্তি, বুকমার্ক এবং প্রিফেচ করা যেতে পারে এবং একটি GET পৃষ্ঠা রিফ্রেশ করা ক্ষতিকারক নয়৷
• রাষ্ট্র-পরিবর্তন ক্রিয়া এবং সংবেদনশীল বা বড় পেলোড পাঠানোর জন্য POST ব্যবহার করুন। একটি POST পৃষ্ঠায় রিফ্রেশ করা বা নেভিগেট করা ব্রাউজারের "ফর্ম পুনরায় জমা দেওয়ার নিশ্চিত করুন" সতর্কতাকে ট্রিগার করে৷
• কখনই GET এর মাধ্যমে পাসওয়ার্ড পাঠাবেন না — সেগুলি URL, লগ এবং ইতিহাসে ল্যান্ড করবে৷ এটি স্বাস্থ্যবিধি, এনক্রিপশন নয়: HTTPS ট্রানজিটে ইউআরএল এবং বডি উভয়কেই এনক্রিপ্ট করে, কিন্তু ইউআরএল এখনও লগ করা আছে।

সাধারণ ফলো-আপ

• নিরাপদ পদ্ধতি হল GET, HEAD, OPTIONS; idempotent পদ্ধতি হল GET, HEAD, PUT, DELETE; POST কোনটিই নয়।
• উভয় পদ্ধতিই HTML ফর্ম (method বৈশিষ্ট্য) দ্বারা সমর্থিত।
• RFC অর্থে "নিরাপদ" মানে রাষ্ট্রীয় পরিবর্তন নয়, ডেটা সুরক্ষা নয়।
• অ্যাপ্লিকেশান-স্তরের POST idempotency প্রায়শই idempotency কী ব্যবহার করে প্রয়োগ করা হয়।