আংশিক-সংশোধনযোগ্য সংস্থানগুলিতে একটি REST এপিআই কীভাবে PUT অনুরোধগুলি হ্যান্ডেল করবে?

Question

ধরুন, কোনও এইচটিটিপি GETঅনুরোধের প্রতিক্রিয়া হিসাবে একটি REST এপিআই, একটি সাব-অবজেক্টে কিছু অতিরিক্ত ডেটা প্রদান করে owner:

{
  id: 'xyz',
  ... some other data ...
  owner: {
    name: 'Jo Bloggs',
    role: 'Programmer'
  }
}

স্পষ্টতই, আমরা চাই না যে কেউ PUTফিরে আসতে সক্ষম হোক

{
  id: 'xyz',
  ... some other data ...
  owner: {
    name: 'Jo Bloggs',
    role: 'CEO'
  }
}

এবং যে সাফল্য আছে। প্রকৃতপক্ষে, আমরা সম্ভবত এটির ক্ষেত্রে এমনকি সম্ভাব্য সফল হওয়ার জন্য কোনও উপায়ও প্রয়োগ করতে যাচ্ছি না this

তবে এই প্রশ্নটি কেবল সাব-অবজেক্টের বিষয়ে নয়: সাধারণভাবে, এমন ডেটা দিয়ে কী করা উচিত যা একটি পুট অনুরোধে পরিবর্তনযোগ্য না হয়?

এটি পুট অনুরোধ থেকে অনুপস্থিত প্রয়োজন?

চুপচাপ ফেলে দেওয়া উচিত?

এটি পরীক্ষা করা উচিত, এবং যদি এটি সেই গুণকের পুরানো মান থেকে পৃথক হয় তবে প্রতিক্রিয়াতে কোনও HTTP ত্রুটি কোডটি ফেরত দিন?

বা পুরো জেএসএন পাঠানোর পরিবর্তে আমাদের আরএফসি 6902 জেএসএন প্যাচগুলি ব্যবহার করা উচিত?

Comments

এই সব কাজ করবে। আমার ধারণা এটি আপনার প্রয়োজনীয়তার উপর নির্ভর করে।

— রবার্ট হার্ভে

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

— ম্যাকিয়েজ পাইচোটকা

@ ম্যাসিজেপিয়েটকটকা এর সাথে সমস্যাটি হ'ল আপনি কীভাবে সন্নিবেশ করানোর মতো পাতায় একই মডেলটি ব্যবহার করতে পারবেন না বা পেয়ে যাবেন না, আমি একই মডেলটি ব্যবহার করতে পছন্দ করবো এবং ক্ষেত্রের অনুমোদনের নিয়মগুলি সহজ হবে তাই যদি তারা কোনও মান প্রবেশ করে তবে যে ক্ষেত্রটি তাদের পরিবর্তন করা উচিত নয়, তারা একটি 403 নিষিদ্ধ ফিরিয়ে দেয়, এবং পরে যদি অনুমোদনের জন্য সেটআপ করা হয় তবে অনুমতি দেওয়া না হলে তারা 401 অননুমোদিত পাবে

— জিমি হোফা

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

— ম্যাকিয়েজ পাইচোটকা

Answer 1

ডাব্লু 3 সি অনুচ্ছেদে বা আরইএসটি-র আনুষ্ঠানিক বিধিগুলিতে কোনও নিয়ম নেই, এতে বলা হয়েছে যে কোনও ব্যক্তিকে PUTঅবশ্যই এটির অনুরূপ স্কিমা / মডেল ব্যবহার করতে হবে GET।

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

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

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

আপনি যদি এই বিকল্পটি চয়ন করেন তবে একটি দুর্দান্ত কাজ হ'ল প্রতিক্রিয়াতে আসল আপডেট হওয়া সত্তা সহ একটি 200 (ঠিক আছে) ফেরত পাঠানো হবে , যাতে ক্লায়েন্টরা স্পষ্ট দেখতে পাবে যে কেবলমাত্র পঠনযোগ্য ক্ষেত্রগুলি আপডেট হয়নি।

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

এটির জন্য দুটি কনভেনশন রয়েছে, এটি উভয়ই আপনার মূল ধারণার সাথে মিলে যায় তবে আমি সেগুলি প্রসারিত করব। প্রথমটি হ'ল কেবলমাত্র পঠনযোগ্য ক্ষেত্রগুলিকে সামগ্রীতে উপস্থিত হওয়া থেকে নিষেধ করা, এবং যদি তারা HTTP 400 (খারাপ অনুরোধ) করে তবে তা ফিরিয়ে দিন। এই ধরণের API গুলি একটি এইচটিটিপি 400 ফিরিয়ে আনতে হবে যদি অন্য কোনও অপরিজ্ঞাত / অব্যবহৃত ক্ষেত্র থাকে। দ্বিতীয়টি হ'ল কেবলমাত্র পঠনযোগ্য ক্ষেত্রগুলি বর্তমান সামগ্রীর সাথে সাদৃশ্যপূর্ণ হওয়া দরকার এবং মানগুলি মেলে না, তবে 409 (সংঘাত) ফেরত।

আমি 409 এর সাথে সাম্যতার চেকটি সত্যই অপছন্দ করি কারণ এটির জন্য অবিচ্ছিন্নভাবে GETবর্তমান ডেটা পুনরুদ্ধার করার জন্য ক্লায়েন্টকে একটি কাজ করার প্রয়োজন হয় PUT। এটি ঠিক সুন্দর নয় এবং সম্ভবত কারও কারও জন্য, কোথাও খারাপ অভিনয় হতে চলেছে। আমি এটির জন্য সত্যই 403 (নিষিদ্ধ) পছন্দ করি না কারণ এটি বোঝায় যে পুরো সম্পদ এটির কেবল একটি অংশ নয়, সুরক্ষিত। সুতরাং আমার মতামতটি হ'ল, যদি আপনার দৃ .়তা নীতি অনুসরণ করার পরিবর্তে অবশ্যই একেবারে বৈধতা দিতে হবে , আপনার সমস্ত অনুরোধগুলি বৈধ করে তুলুন এবং অতিরিক্ত বা অ-লিখনযোগ্য ক্ষেত্রগুলির যে কোনওটির জন্য একটি 400 ফিরিয়ে দিন।

আপনার 400/409 / যা সুনির্দিষ্ট সমস্যা কী এবং কীভাবে এটি ঠিক করবেন সে সম্পর্কে তথ্য অন্তর্ভুক্ত রয়েছে তা নিশ্চিত করুন।

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

Comments

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

— রিনোগো

এই উত্তরটি ভুল। আরএফসি 2616 থেকে 2 কারণে: 1. (বিভাগ 9.1.2) পুটকে স্বাধীন হতে হবে। অনেকবার রাখুন এবং এটি কেবল একবারে রাখার মতো একই ফল প্রকাশ করবে। ২. কোনও উত্স পাওয়ার জন্য সেই সত্তাকে ফেরত দেওয়া উচিত যদি অন্য কোনও অনুরোধ সংস্থানটি পরিবর্তনের জন্য না করা হয়

— ব্রুনোইস

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

— আহমদ আবদেলঘাণী

ধন্যবাদ, অভিজ্ঞতা থেকে আসা শেষ অনুচ্ছেদে আপনি যে গভীরতার তুলনা করেছেন তা হ'ল আমি যা খুঁজছিলাম।

— dিল

Answer 2

আইডেম শক্তি

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

আপনি যদি আংশিক আপডেটের অনুমতি দেন তবে এটি আর আদর্শ-শক্তিমান হতে পারে না। আপনার যদি দুটি ক্লায়েন্ট থাকে ক্লায়েন্ট এ এবং বি, তারপরে নিম্নলিখিত দৃশ্যের বিবর্তন ঘটতে পারে:

ক্লায়েন্ট এ রিসোর্স ইমেজ থেকে একটি ছবি পেয়েছে। এটিতে চিত্রটির একটি বিবরণ রয়েছে যা এখনও বৈধ। ক্লায়েন্ট বি একটি নতুন চিত্র রাখে এবং সেই অনুযায়ী বিবরণটি আপডেট করুন। ছবি বদলে গেছে। ক্লায়েন্ট এ দেখেন, তাকে বিবরণ পরিবর্তন করতে হবে না, কারণ এটি তাঁর ইচ্ছা অনুযায়ী এবং কেবল চিত্রটি রাখেন put

এটি কোনও অসঙ্গতি সৃষ্টি করবে, ছবিটির ভুল মেটাডাটা যুক্ত আছে!

আরও বিরক্তিকর হ'ল যে কোনও মধ্যস্থতাকারী অনুরোধটি পুনরাবৃত্তি করতে পারে। ক্ষেত্রে এটি কোনওভাবে সিদ্ধান্ত নেয় পুট ব্যর্থ হয়েছে।

PUT এর অর্থ পরিবর্তন করা যায় না (যদিও আপনি এটির অপব্যবহার করতে পারেন)।

অন্যান্য অপশন

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

PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 20
{fielda: 1, fieldc: 2}

এবং সার্ভারটি পতাকাটির সাফল্যে 204 (কোনও সামগ্রী নেই) দিয়ে জবাব দিতে পারে। ত্রুটিতে আপনি কাঠামোর একটি অংশ আপডেট করতে পারবেন না। প্যাচচ পদ্ধতিটি পারমাণবিক।

এই পদ্ধতির অসুবিধাটি হ'ল, সমস্ত ব্রাউজারগুলি এটি সমর্থন করে না তবে এটি একটি আরএসটি-পরিষেবাতে সর্বাধিক প্রাকৃতিক বিকল্প।

প্যাচ অনুরোধ উদাহরণ: http://tools.ietf.org/html/rfc5789#section-2.1

জেসন প্যাচিং

Json বিকল্পটি বেশ বিস্তৃত এবং একটি আকর্ষণীয় বিকল্প বলে মনে হচ্ছে। তবে তৃতীয় পক্ষের জন্য এটি কার্যকর করা কঠিন হতে পারে। আপনার ব্যবহারকারী বেসটি এটি পরিচালনা করতে পারে কিনা তা আপনাকে সিদ্ধান্ত নিতে হবে।

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

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

খারাপ হচ্ছে

আপনি যদি পিটি বিকল্পের সাথে যাওয়ার সিদ্ধান্ত নেন তবে এটি কিছুটা ঝুঁকিপূর্ণ। তারপরে আপনার কমপক্ষে ত্রুটিটি বাতিল করা উচিত নয়। ব্যবহারকারীর একটি নির্দিষ্ট প্রত্যাশা রয়েছে (ডেটা আপডেট হবে) এবং আপনি যদি এটি ভঙ্গ করেন তবে আপনি কিছু বিকাশকারীকে একটি ভাল সময় দেবেন না।

আপনি পিছনে পতাকাঙ্কিত করার জন্য চয়ন করতে পারেন: 409 সংঘাত বা একটি 403 নিষিদ্ধ। এটি নির্ভর করে আপনি আপডেট প্রক্রিয়াটি কীভাবে দেখছেন। আপনি যদি এটিকে নিয়মের সেট (সিস্টেমকেন্দ্রিক) হিসাবে দেখেন তবে সংঘাত আরও ভাল হবে ic কিছু মত, এই ক্ষেত্রগুলি আপডেটযোগ্য নয়। (নিয়মের সাথে বিরোধে) যদি আপনি এটিকে কোনও অনুমোদনের সমস্যা (ব্যবহারকারীকেন্দ্রিক) হিসাবে দেখেন তবে আপনার নিষিদ্ধ হওয়া উচিত। সহ: আপনি এই ক্ষেত্রগুলি পরিবর্তন করার জন্য অনুমোদিত নন।

আপনার এখনও ব্যবহারকারীদের সমস্ত সংশোধনযোগ্য ক্ষেত্র প্রেরণে বাধ্য করা উচিত।

এটি প্রয়োগের একটি যুক্তিসঙ্গত বিকল্প হ'ল এটি একটি সাব-রিসোর্সে সেট করা, যা কেবলমাত্র পরিবর্তিতযোগ্য ডেটা সরবরাহ করে।

নিজের মতামত

ব্যক্তিগত প্যাচচ মডেলের জন্য ব্যক্তিগতভাবে আমি যেতে (যদি আপনাকে ব্রাউজারগুলির সাথে কাজ না করতে হয়) এবং পরে এটি জেএসএন প্যাচ প্রসেসরের সাহায্যে প্রসারিত করতে পারি। মাইম টাইপগুলিতে পার্থক্য করে এটি করা যেতে পারে: মাইম টাইপ জসন প্যাচ:

আবেদন / JSON-প্যাচ

এবং জসন: অ্যাপ্লিকেশন / জসন-প্যাচ

এটিকে দুটি পর্যায়ে কার্যকর করা সহজ করে তোলে।

Comments

আপনার আদর্শশক্তি উদাহরণটি বোঝায় না। হয় আপনি বিবরণ পরিবর্তন করুন বা আপনি করবেন না। যে কোনও উপায়ে, আপনি প্রতিবার একই ফলাফল পাবেন।

— রবার্ট হার্ভে

আপনি ঠিক বলেছেন, আমার মনে হয় বিছানায় যাওয়ার সময় হয়েছে। আমি এটি সম্পাদনা করতে পারি না। এটি PUT অনুরোধে সমস্ত ডেটা প্রেরণের যৌক্তিক সম্পর্কে আরও উদাহরণ। পয়েন্টারের জন্য ধন্যবাদ।

— এডগার ক্লার্কস

আমি জানি এটি 3 বছর আগে ছিল ... তবে আপনি কি জানেন যে আরএফসিতে আমি "PUT- কে সম্পদে পুরো অবজেক্ট সরবরাহ করতে হবে" সম্পর্কে আরও তথ্য খুঁজে পেতে পারি। আমি এটি অন্য কোথাও উল্লিখিত দেখেছি তবে দেখতে চাই এটি কীভাবে বর্ণনায় সংজ্ঞায়িত করা হয়েছে।

— সিএস্পার

আমি মনে করি এটি খুঁজে পেয়েছি? tools.ietf.org/html/rfc5789#page-3

— CSharper