RESTFul: রাষ্ট্র পরিবর্তন করার ক্রিয়া


59

আমি আরইএসটিফুল এপিআই তৈরির পরিকল্পনা করছি তবে কিছু স্থাপত্য সংক্রান্ত প্রশ্ন রয়েছে যা আমার মাথায় কিছু সমস্যা তৈরি করছে। ক্লায়েন্টগুলিতে ব্যাকএন্ড বিসনেস লজিক যুক্ত করা বিকল্পটি আমি এড়াতে চাই যেহেতু একাধিক ক্লায়েন্ট প্ল্যাটফর্ম আপডেট করা বাস্তব সময়ে যখন বজায় রাখা যুক্তি দ্রুত পরিবর্তন করতে পারে তখনই বজায় রাখা শক্ত।

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

1) আমাদের এপিআই / নিবন্ধ / {আইডি} / {ক্রিয়া use ব্যবহার করা উচিত যেহেতু দূরবর্তী অবস্থানগুলিতে ঠেলা বা একাধিক সম্পত্তি পরিবর্তনের মতো সেখানে অনেক ব্যাকএন্ড যুক্তি ঘটতে পারে। সম্ভবত এখানে সবচেয়ে কঠিন জিনিসটি হ'ল আপডেট করার জন্য আমাদের সমস্ত নিবন্ধের ডেটা এপিআইতে ফেরত পাঠানো দরকার এবং মাল্টিউসার কাজটি কার্যকর করা যায়নি। উদাহরণস্বরূপ সম্পাদক 5 সেকেন্ড পুরানো ডেটা প্রেরণ করতে এবং ঠিক করতে ওভাররাইট করতে পারে যে অন্য কোনও সাংবাদিক ঠিক 2 সেকেন্ড আগে করেছিলেন এবং আমি ক্লায়েন্টদের কাছে এটি ব্যাখ্যা করার কোনও উপায় নেই যেহেতু নিবন্ধ প্রকাশকারীরা সত্যই কোনও বিষয়বস্তু আপডেট করার সাথে যুক্ত নয়।

২) নতুন সংস্থান তৈরি করাও একটি বিকল্প, এপিআই / নিবন্ধ- {ক্রিয়া} / আইডি হতে পারে তবে তারপরে ফিরে আসা সংস্থানটি নিবন্ধ-{ক্রিয়া} হবে না তবে এই নিবন্ধটি যথাযথ কিনা তা আমি নিশ্চিত নই। সার্ভারের সাইড কোডে আর্টিকেল ক্লাস উভয় সংস্থানেই বাস্তব কাজ পরিচালনা করছে এবং আমি নিশ্চিত নই যে এটি রেস্টস্টুল চিন্তাভাবনার বিরুদ্ধে যায় কিনা?

কোন পরামর্শ স্বাগত জানানো হয় ..


'ক্রিয়াগুলি' একটি বিশ্রামযুক্ত ইউআরআই-র অংশ হওয়া বৈধ আইনী - যদি তারা কোনও ক্রিয়া / অ্যালগরিদম সম্পাদন করার কথা বলে থাকে। এর সাথে কী হয়েছে api/article?action=publish? ক্যোয়ারী প্যারামিটারগুলি এমন ক্ষেত্রে তৈরি করা হয় যেখানে আপনার উল্লিখিত 'অ্যালগরিদম' (বা ক্রিয়া) এর উপর সম্পদের অবস্থা নির্ভরশীল। উদাহরণস্বরূপ api/articles?sort=ascবৈধ
পিএইচডি

1
আমি আপনাকে এই লিখনটি যাচাই করে নেওয়ার পরামর্শ দিচ্ছি , যা আপনাকে আরও বেশি বিশ্রামের সমাধানের সাথে অনুপ্রাণিত করতে পারে ।
বেনজল

এপিআই / নিবন্ধের সাথে আমি যে সমস্যার মুখ দেখছি? ক্রিয়া = প্রকাশিত হ'ল আরইএসটিফুল অ্যাপ্লিকেশনটিতে প্রকাশের জন্য সমস্ত নিবন্ধের ডেটা প্রেরণ করা উচিত যখন আমি কেবল এটি করতে পছন্দ করি: এপিআই / নিবন্ধ / 4545 / প্রকাশ / অতিরিক্ত কিছু ছাড়াই
মিরো Svrtan

2
এই ইস্যুতে দুর্দান্ত উত্স এবং আরও: REST এপিআই ডিজাইন - রিসোর্স মডেলিং
ইজাকি

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

উত্তর:


49

আমি এখানে বর্ণিত অনুশীলনগুলি সহায়ক বলে মনে করি:

সিআরইউডি অপারেশনগুলির জগতে ফিট না হওয়া এমন ক্রিয়াকলাপগুলির সম্পর্কে কী?

এখানেই জিনিসগুলি अस्पष्ट হয়ে উঠতে পারে। অনেকগুলি পন্থা রয়েছে:

  1. কোনও উত্সের ক্ষেত্রের মতো উপস্থিত হওয়ার জন্য ক্রিয়াকে পুনর্গঠন করুন। যদি ক্রিয়াটি প্যারামিটার না নেয় তবে এটি কাজ করে। উদাহরণস্বরূপ একটি অ্যাক্টিভেট অ্যাকশানটি বুলিয়ান activatedক্ষেত্রের সাথে ম্যাপ করা যেতে পারে এবং একটি প্যাচএইচসিএচ মাধ্যমে সংস্থানটিতে আপডেট করা যেতে পারে ।
  2. এটি RESTful নীতি সহ একটি উপ-উত্সের মতো আচরণ করুন। উদাহরণস্বরূপ, GitHub এর API আপনাকে করতে দেয় একটি সারকথা তারকা সঙ্গে PUT /gists/:id/starএবং তারকামুক্ত সঙ্গে DELETE /gists/:id/star
  3. কখনও কখনও আপনার কাছে বুদ্ধিমান RESTful কাঠামোতে ক্রিয়াটি মানচিত্র করার কোনও উপায় নেই। উদাহরণস্বরূপ, একটি বহু-সংস্থান অনুসন্ধান সুনির্দিষ্টভাবে কোনও নির্দিষ্ট সংস্থার শেষ বিন্দুতে প্রয়োগ করা অর্থবোধ করে না। এই ক্ষেত্রে, /searchএটি সবচেয়ে বেশি অর্থবোধ করবে যদিও এটি কোনও সংস্থান নয়। এটি ঠিক আছে - এপিআই গ্রাহকের দৃষ্টিকোণ থেকে ঠিক তাই করুন এবং বিভ্রান্তি এড়াতে এটি স্পষ্টভাবে নথিভুক্ত করা হয়েছে তা নিশ্চিত করুন।

আমি এই পদ্ধতির জন্য ভোট দিয়েছি २. যদিও এটি এপিআই কলারদের জন্য আনাড়ি কৃত্রিম সংস্থানগুলির মতো দেখায়, বাস্তবে তাদের সার্ভারে কী ঘটছে তা কোনও জ্ঞান নেই। আমি যদি /article/123/deactivations123 আর্টিকেলের জন্য একটি নতুন নিষ্ক্রিয়তার অনুরোধ তৈরি করতে পোষ্টকে কল করি তবে সার্ভারটি কেবলমাত্র অনুরোধ করা সংস্থানটি নিষ্ক্রিয় করতে পারে না, তবে প্রকৃতপক্ষে আমার নিষ্ক্রিয়তার অনুরোধ সংরক্ষণ করে যাতে আমি এর পরে অবস্থানটি পুনরুদ্ধার করতে পারি।
জাস্টামার্টিন

2
কেন PUT /gists/:id/star না POST /gists/:id/star?
ফিলিপ বার্টুজি

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

9

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

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

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

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

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


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

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

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

7

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

এই ধরণের জিনিসটি আপনি যা-ই করুন না কেন এটি একটি চ্যালেঞ্জ, এটি বিতরণ করা উত্স নিয়ন্ত্রণ (মার্উরিয়াল, গিট ইত্যাদি) এর মতো একটি অনুরূপ সমস্যা এবং এইচটিটিপি / আরএসটি-তে বানানযুক্ত সমাধানটি কিছুটা মিল দেখায়।

ধরা যাক আপনি দুজন ব্যবহারকারী, এলিস এবং বব দুজনেই কাজ করছেন /articles/lunch। (স্পষ্টতার জন্য, প্রতিক্রিয়া সাহসী মুখে হয়)

প্রথমত, এলিস নিবন্ধটি তৈরি করে।

PUT /articles/lunch HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic YWxpY2U6c2VjcmV0

Hey Bob, what do you want for lunch today?

301 Moved Permanently
Location: /articles/lunch/1 

সার্ভারটি কোনও সংস্থান তৈরি করে নি, কারণ অনুরোধটির সাথে কোনও "সংস্করণ" সংযুক্ত ছিল না, (এর একটি শনাক্তকারী ধরে /articles/{id}/{version}নিচ্ছে the সৃষ্টিটি সম্পাদন করতে, অ্যালিস যে নিবন্ধ / সংস্করণটি তৈরি করবেন তা ইউআরএলে পুনর্নির্দেশ করা হয়েছিল Alএলিসের ব্যবহারকারী এজেন্ট তারপরে নতুন ঠিকানায় অনুরোধটি পুনরায় আবেদন করবেন।

PUT /articles/lunch/1 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic YWxpY2U6c2VjcmV0

Hey Bob, what do you want for lunch today?

201 Created

এবং এখন নিবন্ধ তৈরি করা হয়েছে। পরবর্তী, বব নিবন্ধটি দেখুন:

GET /articles/lunch HTTP/1.1
Host: example.com
Authorization: Basic Ym9iOnBhc3N3b3Jk

301 Moved Permanently
Location: /articles/lunch/1 

বব সেখানে তাকান:

GET /articles/lunch/1 HTTP/1.1
Host: example.com
Authorization: Basic Ym9iOnBhc3N3b3Jk

200 Ok
Content-Type: text/plain

Hey Bob, what do you want for lunch today?

তিনি নিজের পরিবর্তন যুক্ত করার সিদ্ধান্ত নেন।

PUT /articles/lunch/1 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic Ym9iOnBhc3N3b3Jk

Hey Bob, what do you want for lunch today?
Does pizza sound good to you, Alice?

301 Moved Permanently
Location: /articles/lunch/2

অ্যালিসের মতো, ববকে পুনর্নির্দেশ করা হয়েছে যেখানে তিনি একটি নতুন সংস্করণ তৈরি করবেন।

PUT /articles/lunch/2 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic Ym9iOnBhc3N3b3Jk

Hey Bob, what do you want for lunch today?
Does pizza sound good to you, Alice?

201 Created

অবশেষে, অ্যালিস সিদ্ধান্ত নিয়েছে যে তিনি তার নিজের নিবন্ধে যুক্ত করতে চান:

PUT /articles/lunch/1 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic YWxpY2U6c2VjcmV0

Hey Bob, what do you want for lunch today?
I was thinking about getting Sushi.

409 Conflict
Location: /articles/lunch/3
Content-Type: text/diff

---/articles/lunch/2
+++/articles/lunch/3
@@ 1,2 1,2 @@
 Hey Bob, what do you want for lunch today?
-Does pizza sound good to you, Alice?
+I was thinking about getting Sushi.

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


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


1
ভারসোনিং এখানে কোনও সমস্যা ছিল না, আমি কেবল এটিকে সম্ভাব্য সমস্যার উদাহরণ হিসাবে বলেছি যদি নিবন্ধটি প্রকাশের ক্রিয়াকলাপ হিসাবে একটি সংস্থান হিসাবে ব্যবহার করা হয়
Miro Svrtan

3

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

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

এখানে সর্বাধিক বিশ্রামের পদ্ধতিটি কী? পোস্ট / পরিষেবা? কমান্ড = পুনঃসূচনা, উদাহরণস্বরূপ? বা পোস্ট / সার্ভিস / স্টেটের কোনও সংস্থা দিয়ে বলুন, 'চলছে'?

এখানে সেরা অনুশীলনগুলির কোডিফাই করা ভাল লাগবে এবং এই ধরণের পরিস্থিতিটিই REST সঠিক কিনা।

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

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

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


2

REST হ'ল ডেটা ওরিয়েন্টেড এবং এ জাতীয় সংস্থানগুলি "জিনিসগুলি" হিসাবে কাজ করে না তবে সবচেয়ে ভাল কাজ করে best এইচটিপি পদ্ধতিগুলির অন্তর্নিহিত শব্দার্থবিদ্যা; গেট, পুট, ডিলেট, ইত্যাদি প্রবর্তনকে জোরদার করার জন্য পরিবেশন করে। অবশ্যই পোস্ট এটি ব্যতিক্রম।

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

বাস্তবায়ন সম্পর্কে আমি সম্ভবত টোকেনম্যাকগুয়ের পরামর্শ মতো কিছু করব। আমি নিবন্ধে একটি মেটাডেটা ক্ষেত্রও যুক্ত করব, 'লকড' এবং 'প্রকাশিত' এর মতো পুনর্বিবেচনা নয়।


1

এটিকে নিবন্ধের স্থিতিটি সরাসরি পরিচালনা করার মতো ভাববেন না। পরিবর্তে, আপনি নিবন্ধটি তৈরি করার অনুরোধ করে একটি পরিবর্তন অর্ডার দিচ্ছেন

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

প্রকাশনা যদি তাত্ক্ষণিক প্রক্রিয়া না হয় তবে ক্লায়েন্টের কাছে ফিরে যাওয়ার আগে আপনাকে এটি শেষ হওয়ার জন্য অপেক্ষা করতে হবে না। আপনি কেবল স্বীকার করেছেন যে পরিবর্তন অর্ডার তৈরি হয়েছিল এবং পরিবর্তন অর্ডার আইডি ফিরিয়ে দিন। তারপরে পরিবর্তনের ক্রমের স্থিতি ভাগ করে নেওয়ার জন্য আপনি সেই পরিবর্তনের সাথে সম্পর্কিত URL টি ব্যবহার করতে পারেন।

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


আমি এটিকে ওওর চেয়ে অভিনেতার মডেলের আরও কাছাকাছি বিবেচনা করব। REST অনুরোধগুলি বার্তাগুলি হিসাবে বিবেচনা করা (যা তারা হ'ল) ​​রাষ্ট্র পরিচালনার জন্য ইভেন্ট সোর্সিংয়ে এগুলি খুব ঝরঝরে করে সাজায়। REST ঝরঝরেভাবে CQRS লাইন ধরে এর মিথস্ক্রিয়াগুলি ভাগ করে। প্রাপ্ত বার্তা হ'ল কমান্ড অঞ্চলে কোয়েরি, পোস্ট, পুট, প্যাচ, মোছা।
উইলডি

0

যদি আমি আপনাকে সঠিকভাবে বুঝতে পারি তবে আমি মনে করি যে আপনার কাছে যা আছে তা প্রযুক্তিগত সমস্যার চেয়ে 'ব্যবসায়িক নিয়ম' নির্ধারণের বিষয়।

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

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


আমি বিশ্বাস করি না যে এটি একটি ব্যবসায়িক নিয়ম তবে কঠোরভাবে একটি প্রযুক্তিগত নিয়ম। সংস্করণ যুক্ত করার ধারণাটি ওভাররাইডিং বিধিগুলির সাথে সহায়তা করার জন্য ভাল তবে এখনও পরিস্থিতি সমাধান করতে পারে না যে সামগ্রী আপডেট করা এবং সামগ্রী প্রকাশ করা সম্পর্কিত ক্রিয়া নয়।
মিরো স্ব্রতান
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.