REST API বাস্তব জীবনের পরিস্থিতিতে PUT বনাম PATCH পদ্ধতিগুলির ব্যবহার

681

প্রথমত, কিছু সংজ্ঞা:

PUT বিভাগ 9.6 আরএফসি 2616 এ সংজ্ঞায়িত করা হয়েছে :

পুট পদ্ধতিটি অনুরোধ করে যে বদ্ধ সত্তা সরবরাহ করা অনুরোধ-ইউআরআইয়ের অধীনে সংরক্ষণ করা উচিত। যদি অনুরোধ-ইউআরআই একটি ইতিমধ্যে বিদ্যমান সংস্থানটিকে বোঝায়, আবদ্ধ সত্তাটি উত্স সার্ভারে থাকা ব্যক্তির পরিবর্তিত সংস্করণ হিসাবে বিবেচিত হবে । যদি অনুরোধ-ইউআরআই কোনও বিদ্যমান উত্সকে নির্দেশ না করে এবং ইউআরআই অনুরোধকারী ব্যবহারকারী এজেন্ট দ্বারা একটি নতুন সংস্থান হিসাবে সংজ্ঞায়িত করতে সক্ষম হয়, তবে উত্স সার্ভারটি সেই ইউআরআই দিয়ে সংস্থান তৈরি করতে পারে।

প্যাচচটি আরএফসি 5789 এ সংজ্ঞায়িত করা হয়েছে :

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

এছাড়াও আরএফসি 2616 ধারা অনুযায়ী 9.1.2 PUT আইডেম্পোটেন্ট যখন PATCH নেই।

আসুন এখন আসল উদাহরণটি একবার দেখুন। আমি যখন /usersডেটা দিয়ে পোস্ট করি {username: 'skwee357', email: 'skwee357@domain.com'}এবং সার্ভার কোনও সংস্থান তৈরি করতে সক্ষম হয়, তখন এটি 201 এবং সংস্থান সংস্থান (অনুমান করে /users/1) দিয়ে সাড়া দেয় এবং জিইটি-তে পরবর্তী কোনও কল /users/1ফিরে আসবে {id: 1, username: 'skwee357', email: 'skwee357@domain.com'}।

এখন আমাদের বলুন আমি আমার ইমেলটি পরিবর্তন করতে চাই। ইমেল পরিবর্তনকে "পরিবর্তনের একটি সেট" হিসাবে বিবেচনা করা হয় এবং তাই আমার /users/1" প্যাচ ডকুমেন্ট " দিয়ে প্যাচ করা উচিত । আমার ক্ষেত্রে এটি JSON ডকুমেন্ট হবে: {email: 'skwee357@newdomain.com'}। সার্ভারটি তারপরে 200 ফেরত দেয় (অনুমতি ঠিক আছে ধরে নিয়ে)। এটি আমাকে প্রথম প্রশ্নে নিয়ে আসে:

প্যাচ আদর্শবান নয়। এটি আরএফসি 2616 এবং আরএফসি 5789 তে বলেছে However তবে আমি যদি একই প্যাচচ অনুরোধটি প্রকাশ করি (আমার নতুন ইমেল সহ), আমি একই সংস্থান স্থিতি পাব (আমার ইমেলটি অনুরোধকৃত মানের সাথে সংশোধন করা হবে)। কেন প্যাচচ তখন আদর্শবান নয়?

প্যাচচএচ একটি তুলনামূলকভাবে নতুন ক্রিয়া (মার্চ ২০১০-এ প্রবর্তিত আরএফসি), এবং এটি "প্যাচিং" বা ক্ষেত্রের সেটকে সংশোধন করার সমস্যাটি সমাধান করতে আসে। প্যাচএইচসি প্রবর্তনের আগে প্রত্যেকে সংস্থানগুলি আপডেট করার জন্য পুট ব্যবহার করেছিল। তবে প্যাচএইচ চালু হওয়ার পরে এটি পুট কী জন্য ব্যবহৃত হয় তা সম্পর্কে আমাকে বিভ্রান্ত করে তোলে। এবং এটি আমার দ্বিতীয় (এবং মূল) প্রশ্নের কাছে নিয়ে আসে:

PUT এবং প্যাচ এর মধ্যে আসল পার্থক্য কী? আমি কোথাও পড়েছি যে পুটটি নির্দিষ্ট সংস্থার অধীনে পুরো সত্তা প্রতিস্থাপনের জন্য ব্যবহৃত হতে পারে , সুতরাং একজনকে পুরো সত্তা পাঠানো উচিত (প্যাচের মতো বৈশিষ্ট্যের সেট পরিবর্তে)। এই জাতীয় ক্ষেত্রে বাস্তব ব্যবহারিক ব্যবহার কি? আপনি কখন কোনও নির্দিষ্ট সংস্থান ইউআরআই-তে কোনও সত্তাকে প্রতিস্থাপন / ওভাররাইট করতে চান এবং কেন এই জাতীয় ক্রিয়াকলাপ সত্তাকে আপডেট / প্যাচিং বিবেচনা করা হয় না? PUT- এর জন্য আমি দেখতে পাই কেবলমাত্র ব্যবহারিক ব্যবহারের ক্ষেত্রে একটি সংগ্রহের উপর একটি পুট দেওয়া হচ্ছে, /usersপুরো সংগ্রহটি প্রতিস্থাপন করা। একটি নির্দিষ্ট সত্তায় PUT ইস্যু করার পরে প্যাচএচচ চালু হওয়ার কোনও অর্থ হয় না। আমি কি ভূল?

— দিমিত্রি কুদ্রিভতসেভ
সূত্র

1

ক) এটি আরএফসি 2616, 2612 নয় b খ) আরএফসি 2616 অপ্রচলিত হয়েছে, পিইটি- র বর্তমান অনুমানটি গ্রিনবাইটস.ডে / টেক / ওয়েবেডাভ / আরএফসি 7231.html # PUT , গ) আমি আপনার প্রশ্নটি পাই না; এটি কি একেবারেই সুস্পষ্ট নয় যে PUT ব্যবহারের আগে কোনও সংস্থান প্রতিস্থাপনের জন্য ব্যবহার করা যেতে পারে, কেবলমাত্র সংগ্রহ নয়, d) প্যাচচটি চালু হওয়ার আগে, মানুষ সাধারণত পোষ্ট ব্যবহার করত, e) অবশেষে, হ্যাঁ, একটি নির্দিষ্ট প্যাচ অনুরোধ (প্যাচ ফর্ম্যাটের উপর নির্ভর করে) আদর্শবান হতে পারে; এটা ঠিক যে এটি সাধারণত হয় না।

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

যদি এটি সাহায্য করে আমি PATCH বনাম PUT eq8.eu/blogs/36-patch-vs-put-and-tatch-jatch-json-syntax-war

— সমমান 8

5

সাধারণ: POST একটি সংগ্রহে একটি আইটেম তৈরি করে। পুট একটি আইটেম প্রতিস্থাপন। প্যাচ একটি আইটেম সংশোধন করে। পোস্ট করার সময়, নতুন আইটেমটির জন্য ইউআরএল গণনা করা হয় এবং প্রতিক্রিয়াতে ফিরে আসে, অন্যদিকে PUT এবং PATCH এর অনুরোধে একটি URL প্রয়োজন। রাইট?

— টম রাসেল

এই পোস্টটি সহায়ক হতে পারে: মন্তব্যগুলি পোস্ট PUT প্যাচ বনাম বনাম: mscharhag.com/api-design/http-post-put-patch

— Micha

943

দ্রষ্টব্য : আমি যখন প্রথম বিশ্রামের বিষয়ে পড়ার সময় ব্যয় করি তখন আদর্শ পাওয়ার সঠিক হওয়ার চেষ্টা করার জন্য একটি বিভ্রান্তিমূলক ধারণা ছিল। আমি এখনও আমার আসল উত্তরে এটি সঠিকভাবে পাইনি, যেমন আরও মন্তব্য (এবং জেসন হোয়েটারের উত্তর ) দেখিয়েছে। কিছুক্ষণের জন্য, জেসনকে কার্যকরভাবে চুরি করা এড়াতে, আমি এই উত্তরটি ব্যাপকভাবে আপডেট করার বিরুদ্ধে প্রতিরোধ করেছি, তবে আমি এখন এটি সম্পাদনা করছি কারণ, ভাল, আমাকে জিজ্ঞাসা করা হয়েছিল (মন্তব্যে)।

আমার উত্তরটি পড়ার পরে, আমি আপনাকে এই প্রশ্নের জেসন হেটজারের দুর্দান্ত উত্তরটিও পড়ার পরামর্শ দিচ্ছি এবং আমি জেসন থেকে চুরি না করেই আমার উত্তর আরও ভাল করার চেষ্টা করব।

পুট আদর্শবান কেন?

যেমন আপনি আপনার আরএফসি 2616 উদ্ধৃতিতে উল্লেখ করেছেন, পুটকে আদর্শবান হিসাবে বিবেচনা করা হয়। আপনি যখন কোনও সংস্থান স্থাপন করেন, তখন এই দুটি অনুমানগুলি খেলায় থাকে:

আপনি কোনও সংস্থার উদ্দেশ্যে নয়, কোনও সত্তাটির উল্লেখ করছেন।
আপনি যে সত্তা সরবরাহ করছেন তা সম্পূর্ণ ( সম্পূর্ণ সত্তা)।

আসুন আপনার একটি উদাহরণ তাকান।

{ "username": "skwee357", "email": "skwee357@domain.com" }

যদি আপনি এই নথিকে পোস্ট /usersকরেন তবে আপনার পরামর্শ অনুসারে আপনি কোনও সত্তা যেমন ফিরে পেতে পারেন

## /users/1

{
    "username": "skwee357",
    "email": "skwee357@domain.com"
}

আপনি যদি এই সত্তাটি পরে পরিবর্তন করতে চান তবে আপনি PUT এবং PATCH এর মধ্যে বেছে নিন। একটি পুট দেখতে পারে:

PUT /users/1
{
    "username": "skwee357",
    "email": "skwee357@gmail.com"       // new email address
}

আপনি প্যাচএইচচ ব্যবহার করে এটি সম্পাদন করতে পারেন। এটি দেখতে এইরকম হতে পারে:

PATCH /users/1
{
    "email": "skwee357@gmail.com"       // new email address
}

আপনি এই দুইয়ের মধ্যেই একটি পার্থক্য লক্ষ্য করবেন notice PUT এই ব্যবহারকারীর সমস্ত পরামিতি অন্তর্ভুক্ত করেছে, তবে প্যাচএইচএইচএইচ (পিএইচসিএইচ) কেবলমাত্র সেইটিকেই সংশোধন করা হয়েছিল ( email)।

PUT ব্যবহার করার সময়, ধরে নেওয়া হয় যে আপনি সম্পূর্ণ সত্তা প্রেরণ করছেন, এবং সেই সম্পূর্ণ সত্তা সেই ইউআরআই-তে কোনও বিদ্যমান সত্তাকে প্রতিস্থাপন করে । উপরের উদাহরণে, পুট এবং প্যাচ একই লক্ষ্য অর্জন করে: তারা উভয়ই এই ব্যবহারকারীর ইমেল ঠিকানা পরিবর্তন করে। কিন্তু পুট পুরো সত্তাকে প্রতিস্থাপন করে এটি পরিচালনা করে, অন্যদিকে প্যাচচ কেবল সরবরাহিত ক্ষেত্রগুলিকেই আপডেট করে অন্যকে একা রেখে।

যেহেতু পিইটি অনুরোধগুলি পুরো সত্তাকে অন্তর্ভুক্ত করে, আপনি যদি একই অনুরোধ বারবার ইস্যু করেন তবে এর সর্বদা একই ফলাফল হওয়া উচিত (আপনি যে ডেটা প্রেরণ করেছিলেন সেটি এখন সত্তার পুরো ডেটা)। সুতরাং পুট আদর্শবান।

PUT ভুল ব্যবহার

আপনি যদি একটি পিটি অনুরোধে উপরের প্যাচচ ডেটা ব্যবহার করেন তবে কী হবে?

GET /users/1
{
    "username": "skwee357",
    "email": "skwee357@domain.com"
}
PUT /users/1
{
    "email": "skwee357@gmail.com"       // new email address
}

GET /users/1
{
    "email": "skwee357@gmail.com"      // new email address... and nothing else!
}

(আমি এই প্রশ্নের উদ্দেশ্যে ধরে নিচ্ছি যে সার্ভারের কোনও নির্দিষ্ট প্রয়োজনীয় ক্ষেত্র নেই, এবং এটি ঘটতে দেবে ... বাস্তবে এমনটি নাও হতে পারে।)

যেহেতু আমরা পুট ব্যবহার করেছি, তবে কেবল সরবরাহ করেছি email, এখন এই সত্তার মধ্যে এটিই একমাত্র জিনিস। এর ফলে ডেটা ক্ষতি হয়।

উদাহরণটি উদাহরণস্বরূপ এখানে - বাস্তবে কখনও এটি করবেন না। এই পুট অনুরোধটি প্রযুক্তিগতভাবে আদর্শবান, তবে এর অর্থ এটি কোনও ভয়ানক, ভাঙা ধারণা নয়।

প্যাচচ কীভাবে আদর্শবান হতে পারে?

উপরের উদাহরণে, প্যাচচ আদর্শবান ছিলেন । আপনি একটি পরিবর্তন করেছেন, তবে আপনি যদি বার বার একই পরিবর্তন করেন তবে এটি সর্বদা একই ফলটি ফিরিয়ে দেয়: আপনি ইমেল ঠিকানাটি নতুন মানতে পরিবর্তন করেছেন।

GET /users/1
{
    "username": "skwee357",
    "email": "skwee357@domain.com"
}
PATCH /users/1
{
    "email": "skwee357@gmail.com"       // new email address
}

GET /users/1
{
    "username": "skwee357",
    "email": "skwee357@gmail.com"       // email address was changed
}
PATCH /users/1
{
    "email": "skwee357@gmail.com"       // new email address... again
}

GET /users/1
{
    "username": "skwee357",
    "email": "skwee357@gmail.com"       // nothing changed since last GET
}

আমার আসল উদাহরণ, নির্ভুলতার জন্য স্থির

আমার কাছে প্রাথমিকভাবে এমন উদাহরণ ছিল যা আমি ভেবেছিলাম যে আদর্শহীনতা প্রদর্শন করছে তবে তারা বিভ্রান্তিকর / ভুল ছিল। আমি উদাহরণগুলি রাখছি, তবে সেগুলি একটি ভিন্ন বিষয় চিত্রিত করতে ব্যবহার করুন: একই অস্তিত্বের বিরুদ্ধে একাধিক প্যাচ ডকুমেন্টগুলি, বিভিন্ন বৈশিষ্ট্যগুলিকে সংশোধন করে, প্যাচগুলি অ-আদর্শবান করে তোলে না।

ধরা যাক কিছু আগের সময়ে, একজন ব্যবহারকারী যুক্ত হয়েছিল। এটি সেই রাষ্ট্র যা থেকে আপনি শুরু করছেন।

{
  "id": 1,
  "name": "Sam Kwee",
  "email": "skwee357@olddomain.com",
  "address": "123 Mockingbird Lane",
  "city": "New York",
  "state": "NY",
  "zip": "10001"
}

প্যাচ করার পরে আপনার একটি সংশোধিত সত্তা রয়েছে:

PATCH /users/1
{"email": "skwee357@newdomain.com"}

{
  "id": 1,
  "name": "Sam Kwee",
  "email": "skwee357@newdomain.com",    // the email changed, yay!
  "address": "123 Mockingbird Lane",
  "city": "New York",
  "state": "NY",
  "zip": "10001"
}

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

এক ঘন্টা পরে, আপনি কিছু কফি তৈরি করতে এবং বিরতি নেওয়ার পরে, অন্য কেউ তাদের নিজস্ব প্যাচ সহ আসেন। দেখে মনে হচ্ছে পোস্ট অফিস কিছু পরিবর্তন আনছে।

PATCH /users/1
{"zip": "12345"}

{
  "id": 1,
  "name": "Sam Kwee",
  "email": "skwee357@newdomain.com",  // still the new email you set
  "address": "123 Mockingbird Lane",
  "city": "New York",
  "state": "NY",
  "zip": "12345"                      // and this change as well
}

যেহেতু পোস্ট অফিস থেকে এই প্যাচএইচটি ইমেলের সাথে নিজেকে উদ্বেগ দেয় না, কেবল পিন কোড, যদি এটি বারবার প্রয়োগ করা হয় তবে এটিও একই ফলাফল পাবেন: জিপ কোডটি নতুন মানকে সেট করা হয়েছে। এ ,ুকে যায়, এ বেরিয়ে আসে, সুতরাং এটি আদর্শবানও।

পরের দিন, আপনি আবার আপনার প্যাচ প্রেরণ করার সিদ্ধান্ত নিয়েছেন।

PATCH /users/1
{"email": "skwee357@newdomain.com"}

{
  "id": 1,
  "name": "Sam Kwee",
  "email": "skwee357@newdomain.com",
  "address": "123 Mockingbird Lane",
  "city": "New York",
  "state": "NY",
  "zip": "12345"
}

গতকাল আপনার প্যাচটির একই প্রভাব ছিল: এটি ইমেল ঠিকানা সেট করে। এ ,ুকে গেল, এ বেরিয়ে এসেছিল, সুতরাং এটি আদর্শবানও।

আমার মূল উত্তরে আমি কী ভুল পেয়েছি

আমি একটি গুরুত্বপূর্ণ পার্থক্য আঁকতে চাই (আমার মূল উত্তরে আমি ভুল পেয়েছি)। অনেক সার্ভার আপনার পরিবর্তনগুলি (যদি থাকে তবে) দিয়ে নতুন সত্ত্বা রাষ্ট্রটি প্রেরণ করে আপনার বিশ্রামের অনুরোধের জবাব দেবে। সুতরাং, আপনি যখন এই প্রতিক্রিয়াটি ফিরে পাবেন, গতকাল আপনি যেটি পেয়েছিলেন তার থেকে আলাদা হয় , কারণ পিন কোডটি আপনি গতবারের মতো পেয়েছিলেন না। তবে আপনার অনুরোধটি কেবল ইমেলের সাথে জিপ কোড সম্পর্কিত নয়। সুতরাং আপনার প্যাচএইচ ডকুমেন্টটি এখনও আদর্শবান - আপনি প্যাচএইচএচ-এ পাঠানো ইমেলটি এখন সত্তার ইমেল ঠিকানা।

সুতরাং যখন প্যাচচ যখন আদর্শবান হয় না, তখন?

এই প্রশ্নের সম্পূর্ণ চিকিত্সার জন্য, আমি আবার আপনাকে জেসন হেইটজারের উত্তরটি উল্লেখ করব । আমি কেবল এটি এ ছেড়ে চলেছি, কারণ আমি সত্যই বলে মনে করি না যে আমি ইতিমধ্যে তার অংশের চেয়ে এই অংশটির উত্তর দিতে পারি।

— ড্যান লো
সূত্র

2

এই বাক্যটি একেবারেই সঠিক নয়: "তবে এটি আদর্শবান: যখনই এ প্রবেশ করে, বি সর্বদা বেরিয়ে আসে"। উদাহরণস্বরূপ, যদি আপনি GET /users/1পোস্ট অফিসের আগে জিপ কোডটি আপডেট করেন এবং পোস্ট অফিসের আপডেটের পরে আবার একই GET /users/1অনুরোধটি করেন তবে আপনি দুটি পৃথক প্রতিক্রিয়া (বিভিন্ন জিপ কোড) পাবেন। একই "এ" (জিইটি অনুরোধ) চলছে তবে আপনি বিভিন্ন ফলাফল পেয়ে যাচ্ছেন। তবুও জিইটি এখনও আদর্শবান।

— জেসন হেটগার

@ জেসনহয়েটগার জিইটি নিরাপদ (কোনও পরিবর্তনের কারণ হিসাবে অনুমিত), তবে সর্বদা আদর্শবান নয় ot পার্থক্য আছে. দেখুন বোঝায় যা RFC 2616 সেকেন্ড। 9.1 ।

— ড্যান লো

1

@ ড্যানলওয়ে: GET অবশ্যই নিশ্চিতভাবে আদর্শবান হওয়ার গ্যারান্টিযুক্ত। এটি ঠিক বলেছে যে আরএফসি 2616 এর ধারা 9.1.2, এবং আপডেট স্পেসে, আরএফসি 7231 বিভাগ 4.2.2-এ , "এই স্পেসিফিকেশন দ্বারা সংজ্ঞায়িত অনুরোধের পদ্ধতিগুলির মধ্যে, পুট, ডিলেট এবং নিরাপদ অনুরোধের পদ্ধতিগুলি আদর্শবান।" আদর্শহীনতার অর্থ এই নয় যে "প্রতিবার একই অনুরোধ করলে আপনি একই প্রতিক্রিয়া পান"। 7231 4.2.2 আরও বলেছে: "অনুরোধটি পুনরাবৃত্তি করা একই অনুরোধযুক্ত প্রভাব ফেলবে, এমনকি যদি মূল অনুরোধটি সফল হয়, যদিও প্রতিক্রিয়া ভিন্ন হতে পারে " "

— জেসন হোয়েটার

1

@ জেসনহয়েটার আমি এটি স্বীকার করব, তবে আমি এই উত্তর দিয়ে কী করব তা আমি দেখতে পাচ্ছি না, যা পুট এবং প্যাচ নিয়ে আলোচনা করেছিল এবং এমনকি কখনও জিইটি-র কথাও উল্লেখ করেনি ...

— ড্যান লোয়ে

1

আহ, @ জেসনহয়েটারের মন্তব্যটি এটিকে সাফ করেছে: একাধিক আদর্শবান্ধব পদ্ধতি অনুরোধের প্রতিক্রিয়াগুলির পরিবর্তে কেবল ফলস্বরূপ রাষ্ট্রগুলি একই রকম হওয়া দরকার।

— টম রাসেল

328

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

প্যাচচএচ কেন আদর্শবান নয়, তা দেখানোর জন্য, এটি আদর্শবানীর সংজ্ঞা দিয়ে শুরু করতে সহায়তা করে ( উইকিপিডিয়া থেকে ):

আইডেম্পোটেন্ট শব্দটি আরও কার্যকরভাবে একটি ক্রিয়াকলাপের জন্য ব্যবহৃত হয় যা একবারে বা একাধিকবার কার্যকর করা হলে একই ফলাফল উত্পন্ন করবে [...] আইডিম্পোটেন্ট ফাংশনটি এমন হয় যাতে সম্পত্তি f (f (x)) = f (x) থাকে কোনও মান x।

আরও অ্যাক্সেসযোগ্য ভাষায়, একটি আদর্শ প্যাচটিকে এই হিসাবে সংজ্ঞায়িত করা যেতে পারে: প্যাচ নথির সাহায্যে কোনও সংস্থান প্যাচ করার পরে, পরবর্তী সমস্ত প্যাচএইচ একই প্যাচ নথির সাথে একই সংস্থায় কল করে রিসোর্স পরিবর্তন হবে না।

বিপরীতে, একটি নন-আদর্শহীন অপারেশন হ'ল f (f (x))! = F (x), যা প্যাচ-এর জন্য বলা যেতে পারে: প্যাচ নথির সাহায্যে একটি সংস্থান প্যাচ করার পরে, পরবর্তী PATCH একই সংস্থানটিতে কল করে একই প্যাচ ডকুমেন্ট না রিসোর্স পরিবর্তন করুন।

একটি আদর্শহীন প্যাচএইচসিএইচ চিত্রিত করার জন্য, ধরুন এখানে / ব্যবহারকারীদের সংস্থান রয়েছে এবং ধরুন যে কলিংটি GET /usersব্যবহারকারীর একটি তালিকা ফিরিয়ে দেয়, বর্তমানে:

[{ "id": 1, "username": "firstuser", "email": "firstuser@example.org" }]

ওপ-এর উদাহরণ হিসাবে প্যাচিং / ব্যবহারকারী / {আইডি than পরিবর্তে, ধরুন যে সার্ভারটি প্যাচচিং / ব্যবহারকারীদের অনুমতি দেয়। এই প্যাচ অনুরোধটি ইস্যু করা যাক:

PATCH /users
[{ "op": "add", "username": "newuser", "email": "newuser@example.org" }]

আমাদের প্যাচ নথিটি সার্ভারকে ব্যবহারকারীদের newuserতালিকায় নতুন একটি ব্যবহারকারী যুক্ত করার নির্দেশ দেয়। এটি প্রথমবার বলার পরে, GET /usersফিরে আসবে:

[{ "id": 1, "username": "firstuser", "email": "firstuser@example.org" },
 { "id": 2, "username": "newuser", "email": "newuser@example.org" }]

এখন, আমরা যদি উপরের মতো ঠিক একই প্যাচ অনুরোধটি প্রকাশ করি তবে কী হবে? (এই উদাহরণের স্বার্থে, ধরে নেওয়া যাক / ব্যবহারকারী সংস্থানগুলি সদৃশ ব্যবহারকারীর নাম ব্যবহার করে।) "অপ "টি" অ্যাড "হয়, সুতরাং তালিকায় একটি নতুন ব্যবহারকারী যুক্ত করা হয় এবং পরবর্তী GET /usersফলাফলগুলি:

[{ "id": 1, "username": "firstuser", "email": "firstuser@example.org" },
 { "id": 2, "username": "newuser", "email": "newuser@example.org" },
 { "id": 3, "username": "newuser", "email": "newuser@example.org" }]

/ ব্যবহারকারীরা রিসোর্স পরিবর্তিত হয়েছে আবার , যদিও আমরা জারি সঠিক একই বিরুদ্ধে প্যাচ সঠিক একই শেষবিন্দু। যদি আমাদের প্যাচচ (চ) এক্স (এক্স) হয়, চ (চ (এক্স)) এফ (এক্স) এর মতো না হয় এবং তাই, এই নির্দিষ্ট প্যাচচ আদর্শবান নয় ।

যদিও প্যাচচ আইডিপোয়েন্টেন্ট হওয়ার গ্যারান্টিযুক্ত নয় , আপনাকে আপনার নির্দিষ্ট সার্ভার আইডেম্পোটেন্টে সমস্ত প্যাচ অপারেশন করা থেকে বিরত রাখার জন্য প্যাচচ নির্দিষ্টকরণের কিছুই নেই। আরএফসি 5789 এমনকি আদর্শ প্যাচ অনুরোধগুলি থেকে সুবিধার প্রত্যাশা করে:

প্যাচ অনুরোধটি আদর্শবান হওয়ার মতো উপায়ে জারি করা যেতে পারে, এটি একই সময়সীমার একই উত্সে দুটি প্যাচচ অনুরোধের মধ্যে সংঘর্ষ থেকে খারাপ পরিণতি রোধ করতে সহায়তা করে।

ড্যানের উদাহরণে, তার প্যাচচ অপারেশনটি আসলে আদর্শবান ide এই উদাহরণে, / ব্যবহারকারী / 1 সত্তা আমাদের প্যাচচ অনুরোধগুলির মধ্যে পরিবর্তিত হয়েছিল, তবে আমাদের প্যাচচ অনুরোধের কারণে নয় ; এটি আসলে পোস্ট অফিসের বিভিন্ন প্যাচ নথি যা পিন কোড পরিবর্তন করেছিল change পোস্ট অফিসের পৃথক প্যাচএইচসি একটি আলাদা অপারেশন; আমাদের প্যাচ যদি f (x) হয় তবে পোস্ট অফিসের প্যাচটি জি (এক্স)। আইডেম্পোটেন্সে বলা হয়েছে যে f(f(f(x))) = f(x), তবে কোনও গ্যারান্টি দেয় না f(g(f(x)))।

— জেসন হোয়েটার
সূত্র

11

ধরে নিই যে সার্ভার PUT এ ইস্যু করার অনুমতি দেয় /users, এটি পুটকেও অ-আদর্শহীন করে তুলবে। সার্ভারকে অনুরোধগুলি হ্যান্ডেল করার জন্য কীভাবে ডিজাইন করা হয়েছে তা এই সমস্তটিতে নেমে আসে।

— উজায়ের সাজিদ

13

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

— বোহর

6

যদি কোনও সংগ্রহের উপর PUT প্রয়োগ করা হয় (উদাঃ /users), যে কোনও পুট অনুরোধে সেই সংগ্রহের সামগ্রীগুলি প্রতিস্থাপন করা উচিত। সুতরাং একটি পুট /usersব্যবহারকারীর সংগ্রহ আশা এবং অন্যান্য সমস্ত মুছে ফেলা উচিত। এটি আদর্শবান। আপনি / ব্যবহারকারীদের শেষ পয়েন্টে এমন কোনও কাজ করার সম্ভাবনা নেই। তবে এর মতো কিছু /users/1/emailsসংগ্রহ হতে পারে এবং পুরো সংগ্রহটিকে নতুন করে প্রতিস্থাপনের অনুমতি দেওয়া এটি পুরোপুরি বৈধ হতে পারে।

— ভেক্টরজহান

5

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

— ivandov

7

আমি কখনও কোনও সংগ্রহের বিরুদ্ধে কোনও প্যাচ, কেবলমাত্র পোস্ট এবং মুছে ফেলা বিবেচনা করব না। এটি কি কখনও সম্পন্ন হয়? সুতরাং প্যাচচকে কি সমস্ত ব্যবহারিক উদ্দেশ্যে আদর্শবান হিসাবে বিবেচনা করা যেতে পারে?

— টম রাসেল

72

আমি এটি সম্পর্কে কৌতূহল ছিলাম এবং কয়েকটি আকর্ষণীয় নিবন্ধ পেয়েছি। আপনার প্রশ্নের উত্তর আমি পুরোপুরি নাও দিতে পারি, তবে এটি কমপক্ষে আরও কিছু তথ্য সরবরাহ করে।

http://restful-api-design.readthedocs.org/en/latest/methods.html

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

যে দেওয়া হয়েছে, তারপরে একটি PUT পুরো অবজেক্টটি প্রেরণ করবে। এই ক্ষেত্রে,

/users/1
PUT {id: 1, username: 'skwee357', email: 'newemail@domain.com'}

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

/users/1
PUT {id: 1, email: 'newemail@domain.com'}

এখন, যদি পুটটি নকশা অনুসারে ডিজাইন করা হয়, তবে পিটি ইউজারনেমটি বাতিল করে দেয় এবং আপনি নিম্নলিখিতটি ফিরে পাবেন।

{id: 1, username: null, email: 'newemail@domain.com'}

আপনি যখন কোনও প্যাচ ব্যবহার করেন, আপনি কেবলমাত্র নির্দিষ্ট ক্ষেত্রটি আপডেট করেন এবং বাকীটি আপনার উদাহরণ হিসাবে রেখে যান।

প্যাচচে নিম্নলিখিতটি নেওয়া আমি এর আগে দেখিনি তার চেয়ে একটু আলাদা।

http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/

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

PATCH /users/123

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

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

নিবন্ধটি এখানেই শেষ হয়।

এটি উল্লেখ করার মতো যে প্যাচএচইচটি সত্যিকার অর্থেই আরএসইপি এপিআইগুলির জন্য নকশাকৃত নয়, কারণ ফিল্ডিংয়ের গবেষণামূলক সংস্থানগুলি সম্পদের আংশিক পরিবর্তন করার কোনও উপায়ই সংজ্ঞায়িত করে না। তবে, রয় ফিল্ডিং নিজেই বলেছিলেন যে প্যাচচএইচ হ'ল [তিনি] প্রাথমিক এইচটিটিপি / ১.১ প্রস্তাবের জন্য তৈরি করেছিলেন কারণ আংশিক পুট কখনই বিশ্রামের হয় না। অবশ্যই আপনি একটি সম্পূর্ণ উপস্থাপনা স্থানান্তর করছেন না, তবে আরইএসটি-তে যাই হোক না কেন সম্পূর্ণ উপস্থাপনের প্রয়োজন হয় না।

এখন, আমি জানি না যে আমি বিশেষভাবে নিবন্ধের সাথে একমত পোষণ করেছি যেহেতু অনেক মন্তব্যকারী উল্লেখ করেছেন। আংশিক উপস্থাপনের মাধ্যমে প্রেরণ করা সহজেই পরিবর্তনের বর্ণনা হতে পারে।

আমার জন্য, আমি প্যাচ ব্যবহার করতে মিশ্রিত mixed বেশিরভাগ ক্ষেত্রে, আমি পুটকে একটি প্যাচ হিসাবে বিবেচনা করব যেহেতু আমি এখনও অবধি লক্ষ্য করেছি যে আসল পার্থক্যটি হ'ল পুট "অনুপস্থিত মানগুলি বাতিল করে দেয়"। এটি করার 'সর্বাধিক সঠিক' উপায় নাও হতে পারে তবে শুভকামি কোডিং নিখুঁত।

— কালের ওয়েড
সূত্র

7

এটি যোগ করার মতো হতে পারে: উইলিয়াম ডুরান্ডের নিবন্ধে (এবং আরএফসি 6902) এমন উদাহরণ রয়েছে যেখানে "অপ "টি" অ্যাড "রয়েছে। এটি অবশ্যই আদর্শবান নয়।

— জোহানেস ব্রডওয়াল

2

অথবা আপনি এর চেয়ে সহজ করতে এবং পরিবর্তে আরএফসি 7396 মার্জ প্যাচ ব্যবহার করতে পারেন এবং জেএসওএন বিল্ডিং প্যাচ এড়াতে পারেন।

— পাইটর কুলা

নসকিউএল টেবিলগুলির জন্য, প্যাচ এবং পুটের মধ্যে পার্থক্য গুরুত্বপূর্ণ, কারণ নোসকিএল-এর কোনও কলাম নেই

— স্ট্যাকডেভ

18

PUT এবং PATCH এর মধ্যে পার্থক্য হ'ল:

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

কীভাবে সংস্থানটি সংশোধন করতে হয় তা সার্ভারকে জানাতে PATCH এর জন্য কিছু "প্যাচ ভাষা" দরকার। কলার এবং সার্ভারকে কিছু "ক্রিয়াকলাপ" যেমন "অ্যাড", "প্রতিস্থাপন", "মুছুন" সংজ্ঞা দেওয়া দরকার। উদাহরণ স্বরূপ:

GET /contacts/1
{
  "id": 1,
  "name": "Sam Kwee",
  "email": "skwee357@olddomain.com",
  "state": "NY",
  "zip": "10001"
}

PATCH /contacts/1
{
 [{"operation": "add", "field": "address", "value": "123 main street"},
  {"operation": "replace", "field": "email", "value": "abc@myemail.com"},
  {"operation": "delete", "field": "zip"}]
}

GET /contacts/1
{
  "id": 1,
  "name": "Sam Kwee",
  "email": "abc@myemail.com",
  "state": "NY",
  "address": "123 main street",
}

সুস্পষ্ট "অপারেশন" ক্ষেত্রগুলি ব্যবহার করার পরিবর্তে প্যাচ ভাষাটি কনভেনশনগুলি সংজ্ঞায়িত করে এটিকে অন্তর্ভুক্ত করতে পারে:

প্যাচ অনুরোধ সংস্থায়:

কোনও ক্ষেত্রের অস্তিত্বের অর্থ সেই ক্ষেত্রটিকে "প্রতিস্থাপন" বা "যুক্ত" করা উচিত।
যদি কোনও ক্ষেত্রের মান শূন্য হয় তবে এর অর্থ ক্ষেত্রটি মুছুন।

উপরোক্ত কনভেনশন সহ, উদাহরণে প্যাচচটি নিম্নলিখিত ফর্মটি গ্রহণ করতে পারে:

PATCH /contacts/1
{
  "address": "123 main street",
  "email": "abc@myemail.com",
  "zip":
}

যা আরও সংক্ষিপ্ত এবং ব্যবহারকারী বান্ধব দেখায়। তবে ব্যবহারকারীদের অন্তর্নিহিত কনভেনশন সম্পর্কে সচেতন হওয়া দরকার।

আমি উপরে উল্লিখিত অপারেশনগুলির সাথে, প্যাচচচ এখনও আদর্শবান। তবে আপনি যদি অপারেশনগুলি যেমন: "ইনক্রিমেন্ট" বা "সংযোজন" হিসাবে সংজ্ঞায়িত করেন তবে সহজেই দেখতে পাবেন এটি আর আদর্শবান হবে না।

— বিন নি
সূত্র

7

টিএলডিআর - ডাম্বড ডাউন সংস্করণ

PUT => বিদ্যমান উত্সের জন্য সমস্ত নতুন বৈশিষ্ট্য সেট করুন।

প্যাচ => একটি বিদ্যমান সংস্থানটি আংশিকভাবে আপডেট করুন (সমস্ত বৈশিষ্ট্যের প্রয়োজন নেই)।

— বিজন
সূত্র

3

পূর্বের মন্তব্যে ইতিমধ্যে উদ্ধৃত হয়ে আরএফসি 7231 বিভাগ 4.2.2-এ আরও নিবিড়ভাবে উদ্ধৃত এবং মন্তব্য করি :

যদি সেই পদ্ধতির সাথে একাধিক অভিন্ন অনুরোধগুলির সার্ভারের উদ্দেশ্যে প্রভাব একইরকম একক অনুরোধের প্রভাবের মতো হয় তবে একটি অনুরোধের পদ্ধতিটিকে "আদর্শবান" হিসাবে বিবেচনা করা হয়। এই স্পেসিফিকেশন দ্বারা সংজ্ঞায়িত অনুরোধ পদ্ধতিগুলির মধ্যে, পুট, ডিলেট এবং নিরাপদ অনুরোধের পদ্ধতিগুলি আদর্শবান।

(...)

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

সুতরাং, একটি আদর্শবান পদ্ধতির বারবার অনুরোধের পরে "একই" হওয়া উচিত কী? সার্ভারের অবস্থা, না সার্ভারের প্রতিক্রিয়া নয় , অভিযুক্ত প্রভাব । বিশেষত, পদ্ধতিটি "ক্লায়েন্টের দৃষ্টিকোণ থেকে" আদর্শবান হওয়া উচিত। এখন, আমি মনে করি যে এই দৃষ্টিকোণটি দেখায় যে ড্যান লো এর উত্তরের সর্বশেষ উদাহরণ , যা আমি এখানে চুরি করতে চাই না, প্রকৃতপক্ষে দেখায় যে একটি প্যাচ অনুরোধটি আদর্শহীন হতে পারে (উদাহরণের চেয়ে প্রাকৃতিক উপায়ে আরও কিছু হতে পারে) জেসন হোয়েটারের উত্তর )।

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

PATCH /users/1
{"email": "skwee357@newdomain.com"}

যেহেতু এটিই একমাত্র সংশোধন। এখন, কিছু নেটওয়ার্ক সমস্যার কারণে অনুরোধটি ব্যর্থ হয়েছে এবং কয়েক ঘন্টা পরে স্বয়ংক্রিয়ভাবে পুনরায় জমা দেওয়া হবে। এরই মধ্যে, অন্য ক্লায়েন্টটি (ভ্রান্তভাবে) ব্যবহারকারীর 1 জিপটি পরিবর্তন করেছে Then এরপরে, একই প্যাচ অনুরোধটি দ্বিতীয়বার পাঠানো ক্লায়েন্টের উদ্দেশ্যপ্রাপ্ত প্রভাব অর্জন করে না , যেহেতু আমরা একটি ভুল জিপ দিয়ে শেষ করি। সুতরাং আরএফসি অর্থে পদ্ধতিটি আদর্শবান নয়।

পরিবর্তে ক্লায়েন্টটি ইমেলটি সংশোধন করার জন্য PUT অনুরোধটি ব্যবহার করে, ইমেলের সাথে সাথে ব্যবহারকারীর 1 এর সমস্ত বৈশিষ্ট্য প্রেরণ করে, অনুরোধটি পরে পুনরায় প্রেরণ করতে হবে এবং ব্যবহারকারী 1 সংশোধন করা হয়েছে তার পরেও তার উদ্দেশ্য কার্যকর হবে will ইতিমধ্যে --- দ্বিতীয় PUT অনুরোধটি প্রথম অনুরোধের পর থেকে সমস্ত পরিবর্তনগুলি ওভাররাইট করবে।

— Rolvernew
সূত্র

2

আমার বিনীত মতে, আদর্শবোধের অর্থ:

রাখুন::

আমি একটি প্রতিযোগিতামূলক সংস্থান সংজ্ঞা প্রেরণ করি, সুতরাং - ফলস্বরূপ সংস্থান স্থিতি PUT প্যারাম দ্বারা ঠিক সংজ্ঞায়িত। প্রতিবারই আমি একই PUT প্যারামগুলির সাহায্যে সংস্থানটি আপডেট করি - ফলস্বরূপ অবস্থাটি একই রকম।

প্যাচ:

আমি সংস্থান সংজ্ঞাটির কেবলমাত্র একটি অংশ প্রেরণ করেছি, তাই অন্য ব্যবহারকারীরা এই সংস্থার অন্য প্যারামিটারগুলি একটি সময়ের মধ্যে আপডেট করছে might ফলস্বরূপ - একই পরামিতিগুলির সাথে একটানা প্যাচগুলি এবং তাদের মানগুলি বিভিন্ন সংস্থান স্থিতির সাথে পরিণতি হতে পারে। এই ক্ষেত্রে:

নিম্নলিখিত হিসাবে সংজ্ঞায়িত একটি বস্তুর ধারণা করুন:

গাড়ি: - রঙ: কালো, - টাইপ: সেডান, - আসন: 5

আমি এটি দিয়ে প্যাচ:

{লাল রঙ'}

ফলাফল অবজেক্টটি হ'ল:

গাড়ি: - রঙ: লাল, - টাইপ: সেডান, - আসন: 5

তারপরে, আরও কিছু ব্যবহারকারী এই গাড়িটি সাথে প্যাচ করে:

{প্রকার: 'হ্যাচব্যাক'

সুতরাং, ফলাফল অবজেক্টটি হ'ল:

গাড়ি: - রঙ: লাল, - প্রকার: হ্যাচব্যাক, - আসন: 5

এখন, আমি যদি এই বিষয়টিকে আবার প্যাচ করি তবে:

{লাল রঙ'}

ফলাফল অবজেক্টটি হ'ল:

গাড়ি: - রঙ: লাল, - প্রকার: হ্যাচব্যাক, - আসন: 5

আমি যা পেয়েছি তার থেকে আলাদা কী!

এই কারণেই প্যাটচ আদর্শবান নয়, যখন পিইটি আদর্শবান ot

— Zbigniew Szczęsny
সূত্র

1

আদর্শবোধ নিয়ে আলোচনার অবসান ঘটাতে আমার নোট করা উচিত যে কেউ আরইএসএসটি প্রসঙ্গে আদর্শ পটেন্সিটি দুটি উপায়ে সংজ্ঞায়িত করতে পারে। প্রথমে কয়েকটি জিনিস আনুষ্ঠানিকভাবে করা যাক:

একটি রিসোর্স তার codomain স্ট্রিং বর্গ হচ্ছে একটি ফাংশন। অন্য কথায়, একটি সংস্থান হ'ল একটি সাবসেট String × Any, যেখানে সমস্ত কীগুলি অনন্য। চলুন রিসোর্সের ক্লাস বলি Res।

রিসোর্সগুলিতে একটি রেস্ট অপারেশন, একটি ফাংশন f(x: Res, y: Res): Res। আরআরএসটি অপারেশনের দুটি উদাহরণ হ'ল:

PUT(x: Res, y: Res): Res = x, এবং
PATCH(x: Res, y: Res): Res, যা কাজ করে PATCH({a: 2}, {a: 1, b: 3}) == {a: 2, b: 3}।

(এই সংজ্ঞাটি বিশেষত PUTএবং সম্পর্কে তর্ক করার জন্য ডিজাইন করা হয়েছে POSTএবং উদাহরণস্বরূপ এটি তেমন কোনও অর্থবোধ করে না GETএবং POSTকারণ এটি দৃ about়তার বিষয়ে চিন্তা করে না)।

এখন, স্থির করে x: Res(তথ্যের সাথে কথা বলার জন্য, তরকারী ব্যবহার করে), PUT(x: Res)এবং PATCH(x: Res)টাইপের অবিচ্ছিন্ন ফাংশন Res → Res।

একটি ফাংশন g: Res → Resবলা বিশ্বব্যাপী idempotent , যখন g ○ g == gকোন, অর্থাত্ y: Res, g(g(y)) = g(y)।
x: Resএকটি সংস্থান দেওয়া যাক , এবং k = x.keys। একটি ফাংশন g = f(x)বলা হয় বাম আদর্শবান , যখন প্রতিটি জন্য y: Res, আমাদের আছে g(g(y))|ₖ == g(y)|ₖ। মূলত এর অর্থ হ'ল ফলটি একই হওয়া উচিত, যদি আমরা প্রয়োগ কীগুলি দেখি।

সুতরাং, PATCH(x)বিশ্বব্যাপী আদর্শবান নয়, বাম আদর্শবান। এবং বাম ভাবমূর্তি হ'ল এখানে গুরুত্বপূর্ণ: আমরা যদি সংস্থানটির কয়েকটি কী প্যাচ করি তবে আমরা চাই যে সেগুলি আবার প্যাচ করে দিলে সেই কীগুলি একই থাকে এবং আমরা বাকী রিসোর্সের কোনও যত্ন করি না।

আর আরএফসি যখন প্যাচসিএইচ আদর্শবান হওয়ার কথা নয়, তখন এটি বিশ্বব্যাপী আদর্শের কথা বলছে। ঠিক আছে, এটি ভাল যে এটি বিশ্বব্যাপী আদর্শহীন নয়, তা না হলে এটি একটি ভাঙা অপারেশন হত।

এখন, জেসন হিটজারের উত্তরটি প্রমাণ করার চেষ্টা করছে যে প্যাচএইচসিও এমনকি আদর্শবান বাম নয়, তবে এটি করার জন্য এটি অনেকগুলি বিষয় ভঙ্গ করছে:

প্রথমত, PATCH একটি সেটে ব্যবহৃত হয়, যদিও মানচিত্র / অভিধান / কী-মান বস্তুগুলিতে কাজ করার জন্য PATCH সংজ্ঞায়িত করা হয়।
যদি কেউ সত্যিই সেটগুলিতে PATCH প্রয়োগ করতে চান, তবে একটি প্রাকৃতিক অনুবাদ রয়েছে যা ব্যবহার করা উচিত t: Set<T> → Map<T, Boolean>:, এর সাথে সংজ্ঞায়িত x in A iff t(A)(x) == True। এই সংজ্ঞাটি ব্যবহার করে, প্যাচিংটি আদর্শবান বামে রয়েছে।
উদাহরণস্বরূপ, এই অনুবাদটি ব্যবহার করা হয়নি, পরিবর্তে, প্যাচচটি একটি পোস্টের মতো কাজ করে। প্রথমত, কেন আইডিটি অবজেক্টের জন্য তৈরি করা হয়? এবং কখন এটি উত্পন্ন হয়? যদি প্রথমে সেটটির উপাদানগুলির সাথে বস্তুটির তুলনা করা হয়, এবং যদি কোনও মিলে যাওয়া অবজেক্টটি পাওয়া যায় না, তবে আইডি উত্পন্ন হয়, তারপরে আবার প্রোগ্রামটি আলাদাভাবে কাজ করা উচিত ( অন্যথায় এটি {id: 1, email: "me@site.com"}অবশ্যই মিলবে {email: "me@site.com"}, অন্যথায় প্রোগ্রামটি সর্বদা ভাঙ্গা থাকে এবং PATCH সম্ভবত সম্ভব না প্যাচ)। যদি আইডিটি সেটের বিপরীতে পরীক্ষা করার আগে তৈরি করা হয় তবে আবার প্রোগ্রামটি ভেঙে যায়।

এই উদাহরণে ভাঙা অর্ধেক জিনিস ভাঙার সাথে একজন পুট অ-আদর্শহীন হওয়ার উদাহরণ তৈরি করতে পারে:

উত্পন্ন অতিরিক্ত বৈশিষ্ট্য সহ একটি উদাহরণ সংস্করণ হবে। একটি একক বস্তুর পরিবর্তনের সংখ্যার রেকর্ড রাখতে পারে। এই ক্ষেত্রে, পিইটি আদর্শবান নয়: প্রথমবার এবং দ্বিতীয়বারের PUT /user/12 {email: "me@site.com"}ফলাফল results{email: "...", version: 1}{email: "...", version: 2}
আইডিগুলির সাথে মেসিং করা, প্রতিবার অবজেক্টটি আপডেট হওয়ার সাথে সাথে একটি নতুন আইডি তৈরি করতে পারে, যার ফলে একটি অ-আদর্শহীন পুট হয়।

উপরের সমস্ত উদাহরণ প্রাকৃতিক উদাহরণ যা একজনের মুখোমুখি হতে পারে।

আমার চূড়ান্ত বিষয়টি হ'ল, প্যাচটিএইচ বিশ্বব্যাপী আদর্শহীন হওয়া উচিত নয় , অন্যথায় আপনাকে পছন্দসই প্রভাব দেবে না। আপনি বাকী সমস্ত তথ্য স্পর্শ না করেই আপনার ব্যবহারকারীর ইমেল ঠিকানাটি পরিবর্তন করতে চান এবং আপনি একই সংস্থান অ্যাক্সেস করে অন্য পক্ষের পরিবর্তনগুলি ওভাররাইট করতে চান না।

— মোহাম্মদ-আলী এ'রবিবি
সূত্র

-1

কেবলমাত্র একটি অতিরিক্ত তথ্য আমি যুক্ত করতে চাই তা হল যে একটি প্যাচ অনুরোধ একটি পিইউটি অনুরোধের তুলনায় কম ব্যান্ডউইথ ব্যবহার করে যেহেতু কেবলমাত্র ডেটার একটি অংশ পুরো সত্তা না পাঠানো হয় is সুতরাং সুনির্দিষ্ট রেকর্ডগুলির আপডেটের জন্য একটি প্যাচ অনুরোধটি ব্যবহার করুন (১-৩ রেকর্ড) যখন প্রচুর পরিমাণে ডেটা আপডেট করার জন্য পিটি অনুরোধ করুন। এটাই, খুব বেশি চিন্তা করবেন না বা খুব বেশি চিন্তা করবেন না।

— বেঞ্জামিন
সূত্র