PATCH এবং PUT অনুরোধের মধ্যে প্রধান পার্থক্য কী?

186

আমি PUTআমার রেল অ্যাপ্লিকেশনটিতে একটি অনুরোধ ব্যবহার করছি । এখন, একটি নতুন এইচটিটিপি ক্রিয়া PATCHব্রাউজারগুলি প্রয়োগ করেছে। সুতরাং, আমি জানতে চাইছি PATCHএবং PUTঅনুরোধগুলির মধ্যে প্রধান পার্থক্য কী এবং কখন আমাদের একটি বা অন্যটি ব্যবহার করা উচিত।

— user3276063
সূত্র

139

এইচটিটিপি ক্রিয়াগুলি সম্ভবত এইচটিটিপি প্রোটোকল সম্পর্কে সর্বাধিক রহস্যজনক জিনিস। তাদের অস্তিত্ব আছে, এবং তাদের মধ্যে অনেকগুলি রয়েছে তবে কেন তারা বিদ্যমান?

রেলগুলি মনে হয় যে অনেকগুলি ক্রিয়া সমর্থন করে এবং এমন কিছু ক্রিয়া যুক্ত করতে চায় যা ওয়েব ব্রাউজারগুলি স্থানীয়ভাবে সমর্থন করে না।

এখানে HT ক্রিয়াগুলির একটি সম্পূর্ণ তালিকা রয়েছে: http://annevankesteren.nl/2007/10/http- পদ্ধতিগুলি

সেখানে অফিসিয়াল আরএফসি থেকে এইচটিটিপি প্যাচ: https://datatracker.ietf.org/doc/rfc5789/?incolve_text=1

প্যাচ পদ্ধতি অনুরোধ অনুরোধ সত্তা বর্ণিত পরিবর্তনের সেট রিসোর্স Request- কোনো URI দ্বারা চিহ্নিত প্রয়োগ করা যেতে। পরিবর্তনের সেটটি মিডিয়া টাইপ দ্বারা চিহ্নিত "প্যাচ ডকুমেন্ট" নামক ফর্ম্যাটে প্রতিনিধিত্ব করে। অনুরোধ-কোনো URI একটি বিদ্যমান সম্পদ দিকে নির্দেশ না করে, তাহলে সার্ভারের পারে একটি নতুন রিসোর্স তৈরি, প্যাচ ডকুমেন্ট ধরনের উপর নির্ভর করে (এটা কথাটি একটি নাল রিসোর্স পরিবর্তন করতে পারেন কিনা) ও অনুমতি, ইত্যাদি

PUT এবং PATCH অনুরোধগুলির মধ্যে পার্থক্য প্রতিবেদন -ইউআরআই দ্বারা চিহ্নিত সংস্থানটি সংশোধন করার জন্য সার্ভারটি যেভাবে আবদ্ধ সত্তাকে প্রক্রিয়াজাত করে তাতে প্রতিফলিত হয়। একটি পুট অনুরোধে, জড়িত সত্তাটি উত্স সার্ভারে সঞ্চিত সংস্থার পরিবর্তিত সংস্করণ হিসাবে বিবেচিত হয় এবং ক্লায়েন্ট অনুরোধ করে যে সঞ্চিত সংস্করণটি প্রতিস্থাপন করা হোক। সঙ্গে প্যাচ অবশ্য ঘিরা সত্তা বর্ণনা কিভাবে একটি সম্পদ বর্তমানে মূল সার্ভারে অবস্থিত একটি নতুন সংস্করণ উত্পাদন করতে পরিবর্তন করা উচিত নির্দেশাবলীর একটি সেট রয়েছে। প্যাচ পদ্ধতি রিসোর্স দ্বারা চিহ্নিত প্রভাবিত অনুরোধ-কোনো URI , এবং এটা মেঅন্যান্য সংস্থানগুলিতে পার্শ্ব প্রতিক্রিয়া রয়েছে; অর্থাত্, PATCH প্রয়োগের মাধ্যমে নতুন সংস্থান তৈরি হতে পারে বা বিদ্যমান সংশোধিত হতে পারে ।

আমি যতদূর জানি, প্যাচচ ক্রিয়াটি রেল অ্যাপ্লিকেশনগুলিতে যেমন ব্যবহার করা হয় না ... এটি আমি বুঝতে পেরেছি, আপনি যখন দুটি ফাইলের মধ্যে পার্থক্য করেন তখন আরএফসি প্যাচ ক্রিয়াটি প্যাচ নির্দেশনা প্রেরণে ব্যবহার করা উচিত। পুরো সত্তাকে আবার প্রেরণের পরিবর্তে, আপনি এমন একটি প্যাচ প্রেরণ করুন যা পুরো সত্তাকে পুনরায় বিক্রয় করার চেয়ে অনেক ছোট হতে পারে।

কল্পনা করুন আপনি একটি বিশাল ফাইল সম্পাদনা করতে চান। আপনি 3 টি লাইন সম্পাদনা করুন। ফাইলটি ফেরত পাঠানোর পরিবর্তে আপনাকে কেবল ভিন্নতাটি পাঠাতে হবে। প্লাস দিকে, একটি প্যাচ অনুরোধ প্রেরণ ফাইলগুলিকে সংযোজনীয়ভাবে মার্জ করতে ব্যবহৃত হতে পারে। একটি সংস্করণ নিয়ন্ত্রণ ব্যবস্থা সম্ভাব্যভাবে দূরবর্তী অবস্থান আপডেট করার জন্য PATCH ক্রিয়াটি ব্যবহার করতে পারে ।

অন্য একটি সম্ভাব্য ব্যবহারের কেস কিছুটা নোএসকিউএল ডাটাবেসের সাথে সম্পর্কিত, এটি নথি সংরক্ষণ করা সম্ভব। ধরা যাক আমরা সার্ভার থেকে ক্লায়েন্টের কাছে ডেটা পিছনে পাঠাতে JSON কাঠামো ব্যবহার করি use আমরা যদি একটি ক্ষেত্র মুছে ফেলতে চেয়েছিলেন, আমরা একটি বাক্য গঠন জন্য MongoDB এক অনুরূপ ব্যবহার করতে পারে $ সেট না । প্রকৃতপক্ষে, ডকুমেন্টগুলি আপডেট করতে মঙ্গোদব ব্যবহার করা পদ্ধতি সম্ভবত জসন প্যাচগুলি পরিচালনা করতে ব্যবহৃত হতে পারে।

এই উদাহরণ গ্রহণ করা:

db.products.update(
   { sku: "unknown" },
   { $unset: { quantity: "", instock: "" } }
)

আমরা এরকম কিছু পেতে পারি:

PATCH /products?sku=unknown
{ "$unset": { "quantity": "", "instock": "" } }

সর্বশেষে, তবে কম নয়, মানুষ এইচটিটিপি ক্রিয়াগুলি সম্পর্কে যা কিছু বলতে চায় তা বলতে পারে। একটি মাত্র সত্য আছে, এবং সত্যটি আরএফসিগুলিতে রয়েছে।

— Loïc Faure-Lacroix
সূত্র

1

এটি লক্ষণীয় যে, আরএফসি 5789 এখনও প্রস্তাবের পর্যায়ে রয়েছে এবং এটি আনুষ্ঠানিকভাবে গৃহীত হয়নি এবং বর্তমানে এটি 'ইররাটার অস্তিত্ব' হিসাবে চিহ্নিত করা হয়েছে। এই 'সেরা অনুশীলন' অত্যন্ত বিতর্কিত এবং প্রযুক্তিগতভাবে প্যাচটিএইচটি এখনও এইচটিটিপি মানের অংশ নয়। এখানে একমাত্র সত্য যেহেতু আরএফসি অগ্রহণযোগ্য, তাই আপনার এটি করা উচিত নয়।

— ফিশস্পেন 0

3

এমনকি এটি এখনও প্রস্তাবের মধ্যে থাকলেও এর অর্থ এই নয় যে এটি ব্যবহার করা উচিত নয়। যদি এটি হয় তবে আমরা ওয়েবসকেট এবং আরও অনেক আরএফসিএস ব্যবহার করতে সক্ষম হবো না যা এখনও প্রস্তাবের মধ্যে রয়েছে ... প্রস্তাব বাস্তবায়ন করা সম্পূর্ণ কাস্টম এমন কিছু বাস্তবায়নের চেয়ে 100 গুণ ভাল যা অন্য কেউ প্রয়োগ করে না।

— Loïc Faure-Lacroix

বিএস। এটি "প্রস্তাবিত" নয়, এবং এটি এইচটিটিপি স্ট্যান্ডার্ডের একটি অংশ (মানক, আরএফসি 7231 পদ্ধতিগুলির জন্য একটি আইএএনএ রেজিস্ট্রিতে প্রতিনিধি, এবং প্যাচএইচচি সেখানে তালিকাভুক্ত)।

— জুলিয়ান রেশকে

@ জুলিয়ানআরশকে যদি আপনি এই আরএফসিটির দ্বিতীয় লাইনটি পড়ে থাকেন তবে আপনি দেখতে পাবেন এটি এখনও প্রোপোজড স্ট্যান্ডার্ড হিসাবে চিহ্নিত হয়েছে । সুতরাং না, প্যাচ পদ্ধতিটি এখনও প্রস্তাবে রয়েছে। আরএফসি এখানে বিটিডব্লিউ। tools.ietf.org/html/rfc5789 এবং rfc7231 হয় স্ট্যান্ডার্ড PROPOSED । আপনি উদাহরণস্বরূপ RFC821 তাকান, তাহলে এটি হিসাবে চিহ্নিত হচ্ছে ইন্টারনেট স্ট্যান্ডার্ড

— Loïc Faure-মধ্যে Lacroix

1

@JulianReschke en.wikipedia.org/wiki/Internet_Standard#Proposed_Standard ... এটা আমার কথা নয়। প্রস্তাবিত মানটির অর্থ এই নয় যে আপনি উপরে বর্ণিত হিসাবে এটি সূক্ষ্মভাবে প্রয়োগ করতে পারবেন না। এর অর্থ এই নয় যে এটি বাস্তবায়নের পক্ষে যথেষ্ট স্থিতিশীল নয় ... তবে এটি ইন্টারনেট স্ট্যান্ডার্ড হিসাবে চিহ্নিত না করা অবধি প্রস্তাবের মধ্যে রয়েছে ... আপনি কীভাবে এই বিষয়ে তর্ক করছেন তা আমি নিশ্চিত নই। একে "প্রস্তাবিত স্ট্যান্ডার্ড" বলা হয় এটি প্রস্তাব ছাড়া আর কিছু বোঝাতে পারে না। আপনি যদি তর্ক করতে চান তবে প্রস্তাবিত মান ব্যবহার করা যেতে পারে। আমি যা লিখেছিলাম তা ঠিক তাই।

— Loïc Faure-Lacroix

104

আমি গুগলের সাথে কয়েক ঘন্টা কাটিয়েছি এবং উত্তরটি এখানে পেয়েছি

পুট => যদি ব্যবহারকারী সমস্ত বা কেবলমাত্র রেকর্ডের একটি অংশ আপডেট করতে পারে তবে পুট ব্যবহার করুন (ব্যবহারকারী কী আপডেট হয় তা নিয়ন্ত্রণ করে)

PUT /users/123/email
new.email@example.org

প্যাচ => যদি ব্যবহারকারী কেবল আংশিক রেকর্ড আপডেট করতে পারে তবে কেবল একটি ইমেল ঠিকানা বলুন (অ্যাপ্লিকেশন কী আপডেট করা যায় তা নিয়ন্ত্রণ করে), প্যাচ ব্যবহার করুন।

PATCH /users/123
[description of changes]

কেন Patch

PUTপদ্ধতিতে আরও বেশি ব্যান্ডউইথ প্রয়োজন বা আংশিক পরিবর্তে সম্পূর্ণ সংস্থানগুলি হ্যান্ডেল করা উচিত। তাই PATCHব্যান্ডউইথ কমাতে প্রবর্তিত হয়েছিল।

প্যাচএইচএইচ সম্পর্কে ব্যাখ্যা

PATCH এমন একটি পদ্ধতি যা নিরাপদ নয়, না আদর্শবান, এবং সম্পূর্ণ এবং আংশিক আপডেট এবং অন্যান্য সংস্থানগুলিতে পার্শ্ব-প্রতিক্রিয়াটিকে মঞ্জুরি দেয়।

PATCH এমন একটি পদ্ধতি যা বদ্ধ সত্তা নির্দেশাবলীর একটি সেট রয়েছে যা বর্ণনা করে যে কীভাবে মূল উত্স সার্ভারে বসবাসরত একটি সংস্থানটি নতুন সংস্করণ তৈরি করতে পরিবর্তন করা উচিত।

PATCH /users/123
[
  { "op": "replace", "path": "/email", "value": "new.email@example.org" }
]

পুট এবং প্যাচ সম্পর্কে আরও তথ্য এখানে

— Selvamani
সূত্র

7

কেন এই প্যাচচটি নিরাপদ নয়?

— বিশিষ্ট ভট্ট

1

PATCHমধ্যে POST, PUTইত্যাদি, "নিরাপদ" নয়, কারণ এটা আপনার ডেটা পরিবর্তন (পার্শ্ব প্রতিক্রিয়া আছে)। তুলনায় GET, OPTIONSইত্যাদি (নিরাপদ পদ্ধতি) যেখানে আপনি এন্ড পয়েন্ট কোন পার্শ্ব প্রতিক্রিয়া ছাড়া একাধিক বার কল করতে পারেন।

— এমিক্স

1

প্যাচ পুরোপুরি ব্যান্ডউইথ সংরক্ষণের জন্য প্রবর্তন করা হয়নি। আরএফসি 5789-তে যেমন বলা হয়েছে:> "আন্তঃব্যবহারযোগ্যতা উন্নত করতে এবং ত্রুটিগুলি রোধ করার জন্য একটি নতুন পদ্ধতি প্রয়োজনীয়" " একাধিক সমান্তরাল পরিবেশে কেবলমাত্র পিইউটি রয়েছে যার মধ্যে বাকী পে-লোড অন্তর্ভুক্ত থাকায় সংস্থানটির অন্যান্য বৈশিষ্ট্যগুলির পরিবর্তনের ঝুঁকি বাড়বে। প্যাচ এই জাতীয় সমস্যা সমাধান করে।

— টমাসজ নজর

43

করা
যদি আমি আমার পরিবর্তন করতে চান firstনাম তারপর সেন্ড করা আপডেটের জন্য অনুরোধ

{ "first": "Nazmul", "last": "hasan" }

কিন্তু এখানে একটি সমস্যা হয়েছে putঅনুরোধ যখন আমি পাঠাতে চান putআমি সব দুটি প্যারামিটার যে পাঠাতে হবে অনুরোধ firstএবং last
তাই এটি সব মান আবার পাঠাতে বাধ্যতামূলক

প্যাচ :
patchঅনুরোধ বলে। dataআপনি যা চান কেবল তা প্রেরণ করুন updateএবং এটি অন্য ডেটা প্রভাবিত বা পরিবর্তন করবে না।
সুতরাং আর সমস্ত মান পাঠানোর দরকার নেই। কেবলমাত্র আমি আমার প্রথম নামটি আপডেট করতে চাই যাতে আপডেট করার জন্য আমাকে কেবল firstনামটি প্রেরণ করতে হবে।

— নাজমুল হাসান
সূত্র

13

এইচটিটিপি প্রোটোকলের POST, PUT এবং PATCH পদ্ধতির মধ্যে পার্থক্য এখানে রয়েছে।

পোস্ট

একটি HTTP.POST পদ্ধতি সর্বদা সার্ভারে একটি নতুন সংস্থান তৈরি করে। এটি একটি আদর্শবিহীন অনুরোধ অর্থাৎ ব্যবহারকারী যদি একই অনুরোধটি 2 বার হিট করে তবে কোনও সীমাবদ্ধতা না থাকলে এটি অন্য নতুন সংস্থান তৈরি করতে পারে।

এইচপিএল পোস্ট পদ্ধতিটি এসকিউএল-তে একটি INSERT ক্যোয়ারির মতো যা সর্বদা ডাটাবেসে একটি নতুন রেকর্ড তৈরি করে।

উদাহরণ: নতুন ব্যবহারকারীর সংরক্ষণের জন্য POST পদ্ধতিটি ব্যবহার করুন, অর্ডার ইত্যাদি যেখানে ব্যাকএন্ড সার্ভার নতুন সংস্থার জন্য সংস্থান আইডি স্থির করে।

PUT

HTTP.PUT পদ্ধতিতে প্রথমে ইউআরএল থেকে সংস্থানটি সনাক্ত করা হয় এবং এটি উপস্থিত থাকলে তা আপডেট করা হয় অন্যথায় একটি নতুন সংস্থান তৈরি হয়। যখন লক্ষ্য সংস্থান উপস্থিত থাকে এটি সম্পূর্ণ নতুন বডি সহ সেই সংস্থানটিকে ওভাররাইট করে। এটি HTTP.PUT পদ্ধতিটি কোনও সংস্থান তৈরি বা আপডেট করার জন্য ব্যবহৃত হয়।

এইচটিকিউএল-তে পোট পদ্ধতিটি মার্জ ক্যোয়ারির মতো যা প্রদত্ত রেকর্ডটি বিদ্যমান কিনা তার উপর নির্ভর করে কোনও রেকর্ড সন্নিবেশ করে বা আপডেট করে।

পুট অনুরোধ আদর্শবান, অর্থাত্ একই অনুরোধ দু'বার আঘাত করা বিদ্যমান রেকর্ডিং আপডেট করবে (নতুন কোনও রেকর্ড তৈরি হয়নি)। PUT পদ্ধতিতে সংস্থান আইডি ক্লায়েন্ট দ্বারা সিদ্ধান্ত নেওয়া হয় এবং অনুরোধ url এ সরবরাহ করা হয়।

উদাহরণ: বিদ্যমান ব্যবহারকারী বা অর্ডার আপডেট করতে PUT পদ্ধতিটি ব্যবহার করুন।

তালি

একটি HTTP.PATCH পদ্ধতি কোনও সংস্থার আংশিক পরিবর্তনের জন্য যেমন ডেল্টা আপডেটগুলির জন্য ব্যবহৃত হয়।

এইচপিএল প্যাচ পদ্ধতিটি এসকিউএল-তে একটি আপডেটের ক্যোয়ারির মতো যা কেবলমাত্র নির্বাচিত কলামগুলিকে সেট করে বা আপডেট করে পুরো সারিতে নয়।

উদাহরণ: আপনি অর্ডার স্থিতি আপডেট করতে প্যাচচ পদ্ধতি ব্যবহার করতে পারেন।

প্যাচ / এপিআই / ব্যবহারকারী / 40450236 / অর্ডার / 10234557

অনুরোধ বডি: {স্থিতি: 'বিতরণ'}

— user8640104
সূত্র

পুট এবং প্যাচ সম্পর্কে যে কেউ যে কোনও সময় পড়তে পারে এটি সবচেয়ে খারাপ ব্যাখ্যা। এবং তদ্ব্যতীত, ইতিমধ্যে পোস্ট করা বেশ কয়েকটি ভাল উত্তর পরে, আপনার উত্তরটি এখানে আলাদা বলে কী মনে করে?

— কোডহান্টার

3

আপডেট করার সময় PUT ওভার প্যাচচে সীমাবদ্ধতা রয়েছে। PUT ব্যবহারের জন্য আমাদের কেবলমাত্র একটি বৈশিষ্ট্য পরিবর্তন করতে চাইলেও সমস্ত বৈশিষ্ট্য নির্দিষ্ট করা দরকার। তবে আমরা যদি প্যাচচ পদ্ধতিটি ব্যবহার করি তবে আমরা কেবল আমাদের প্রয়োজনীয় ক্ষেত্রগুলি আপডেট করতে পারি এবং সমস্ত ক্ষেত্র উল্লেখ করার দরকার নেই। প্যাচএচচ আমাদের একটি অ্যারেতে কোনও মান পরিবর্তন করতে বা কোনও বৈশিষ্ট্য বা অ্যারে প্রবেশ মুছে ফেলার অনুমতি দেয় না।

— আনন্দ মুহলে
সূত্র

1

PUT এবং প্যাচ পদ্ধতিগুলি প্রকৃতিতে একই, তবে মূল পার্থক্য রয়েছে।

পুট - পুট অনুরোধে, সংযুক্ত সত্তাকে সার্ভারে থাকা একটি সংস্থার পরিবর্তিত সংস্করণ হিসাবে বিবেচনা করা হবে এবং এটি এই পরিবর্তিত সত্তা দ্বারা প্রতিস্থাপন করা হবে।

প্যাচ - প্যাচচ অনুরোধে, সংযুক্ত সত্তায় নির্দেশাবলীর সেট রয়েছে যা সার্ভারে থাকা সত্তা কীভাবে নতুন সংস্করণ তৈরি করতে পরিবর্তিত হবে।

— নীরজ কুমার
সূত্র

1

এইচটিটিপি শর্তাবলী অনুসারে, PUTঅনুরোধটি একটি ডেটাবেস আপডেট বিবরণের মতোই। PUT- বিদ্যমান সংস্থান সংশোধন করার জন্য ব্যবহৃত হয় (পূর্বে পোস্ট)। অন্যদিকে PATCHঅনুরোধটি বিদ্যমান সংস্থার কিছু অংশ আপডেট করতে ব্যবহৃত হয়।

উদাহরণ স্বরূপ:

কাস্টমার বিস্তারিত:

// This is just a example.

firstName = "James";
lastName = "Anderson";
email = "email@domain.com";
phoneNumber = "+92 1234567890";
//..

আমরা কখন পুরো রেকর্ডে আপডেট করতে চাই? আমাদের এটি ব্যবহার Http PUT verbকরতে হবে।

যেমন:

// Customer Details Updated.

firstName = "James++++";
lastName = "Anderson++++";
email = "email@Updated.com";
phoneNumber = "+92 0987654321";
//..

অন্যদিকে আমরা যদি রেকর্ডের কেবলমাত্র অংশটি সম্পূর্ণ রেকর্ড না করে আপডেট করতে চাই তবে তার জন্য যান Http PATCH verb। যেমন:

   // Only Customer firstName and lastName is Updated.

    firstName = "Updated FirstName";
    lastName = "Updated LastName";
   //..

পুট ভিএস পোস্ট:

PUTঅনুরোধটি ব্যবহার করার সময় আমাদের সমস্ত পরামিতি যেমন ফার্সন নেম, লাস্টনাম, ইমেল, ফোন নাম্বার প্রেরণ করতে হবে যেখানে patchঅনুরোধ অনুসারে কেবলমাত্র কোনটি আমরা আপডেট করতে চাই সেগুলি প্যারামিটারগুলি প্রেরণ করুন এবং এটি অন্য ডেটা প্রভাবিত বা পরিবর্তন করবে না।

আরও তথ্যের জন্য দয়া করে এখানে যান: https://fullstack-developer.academy/restful-api-design-post-vs-put-vs-patch/

— রেহান শাহ
সূত্র

0

পুট এবং প্যাচ পদ্ধতি একই রকম। তবে রেলগুলিতে এর আলাদা মেটোড থাকে যদি আমরা পুরো রেকর্ডটি আপডেট / প্রতিস্থাপন করতে চাই তবে আমাদের পুট পদ্ধতিটি ব্যবহার করতে হবে। আমরা যদি বিশেষ রেকর্ড ব্যবহার প্যাচ পদ্ধতি আপডেট করতে চাই।

— শেল মিতাপেলী
সূত্র