পোস্টের আগে পূর্বরূপ দেখানোর জন্য REST শেষ পয়েন্ট

Question

আমি একটি নতুন ওয়েব অ্যাপ্লিকেশন ডিজাইন করছি যা একটি REST ব্যাকএন্ড এবং এইচটিএমএল + জেএস সম্মুখভাগ দ্বারা চালিত।

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

POST /api/config BODY {config: ....}

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

আমি প্রথমে যে জিনিসটির কথা ভেবেছিলাম তা হ'ল পূর্বরূপের জন্য একটি জিইটি শেষ পয়েন্ট তৈরি করা, সত্তার নতুন অবস্থার মূল অংশটি পাঠানো। এই পথে:

GET /api/preview/items BODY {config: ....}

নতুন কনফিগারেশন সহ আইটেমগুলির জন্য নতুন রাজ্যটি দেখাতে পারে।

GET /api/preview/sales BODY {config: ....}

নতুন কনফিগারেশন সহ বিক্রয়ের জন্য নতুন রাজ্যটি দেখাতে পারে।

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

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

POST /api/preview/config BODY {config: ....}

GET /api/preview/items?idPreviewConfig=1

Comments

এই কনফিগারটি ঠিক কী হতে পারে এবং এটি কীভাবে প্রভাবিত করে itemsবা sales? এটি কি ফিরে আসা সত্তার প্রতিনিধিত্বকে প্রভাবিত করে?

— অ্যান্ডি

ধরা যাক আইটেম এবং বিক্রয় উভয়ই আপনার কনফিগারেশনে পরিবর্তনগুলি দ্বারা প্রভাবিত হয়ে যায়।

— এক্সট্রিম বাইকার মনিকা

তবে পরিবর্তনগুলি কী বোঝায়? এটি কি ফিরে আসা সত্তার সেটকে পরিবর্তন করে? এটি কি ফিরে কাঠামো পরিবর্তন করে?

— অ্যান্ডি

প্রকৃতপক্ষে এটি আপনার পোষ্ট করা কনফিগারেশনের উপর নির্ভর করে itemsএবং sales(কাঠামোর নয়) মানগুলি পরিবর্তন করে ।

— এক্সট্রিম বাইকার মনিকা

এবং কনফিগারটি ঠিক কতটা বড়? কয়েকশো কিলোবাইট বা তারও বেশি বাড়তে পারে?

— অ্যান্ডি

Answer 1

এইচটিটিপি-তে স্থানীয় সমর্থন পাওয়ার জন্য এটি খুব বেশি ডোমেন-নির্দিষ্ট।

পরিবর্তে, আপনি নিম্নলিখিতগুলির একটি করতে পারেন:

1. আছে একটি POST /api/config/preview । সার্ভারের দিকে, অ্যাপ্লিকেশনটি জানবে যে এটির আসল কনফিগারেশনটি পরিবর্তন করা উচিত নয়, তবে আপনি যে পোস্ট করেছেন তার সাথে প্রকৃতটি একত্রিত করুন এবং কী পরিবর্তন হয়েছে তা নির্দেশ করে ফলাফলটি ফিরিয়ে দিন।

   পরে, ব্যবহারকারী যদি ফলাফলটির সাথে সন্তুষ্ট হন তবে তিনি POST /api/configআগের অনুরোধের মতো একই পেডলোড সম্পন্ন করবেন। এটি কার্যকরভাবে কনফিগারেশন ওভাররাইট করবে।

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

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

2. আছে একটি POST /api/config/prepareযা মনে কি একটি অস্থায়ী রেকর্ডে প্রেরিত হয়েছিল এবং দুটি জিনিস ফেরৎ: (উদাহরণস্বরূপ অস্থায়ী রেকর্ডের আইডি12345 ) ও পরিবর্তনের পূর্বরূপ।

   ব্যবহারকারী যদি ফলাফলটির সাথে সন্তুষ্ট হন তবে তিনি অবশ্যই POST /api/config/commit/12345পরিবর্তনগুলি সংরক্ষণ করার জন্য একটি সম্পাদন করবেন । যদি তা না হয় তবে অস্থায়ী রেকর্ডটি কিছু সময়ের জন্য রাখা যেতে পারে এবং তারপরে ক্রোন জব দ্বারা ফেলে দেওয়া হবে।

   সুবিধাটি হ'ল, এখানে আবারও আপনি আসলটি রাখতে পারেন POST /api/config অক্ষত এবং যে ক্লায়েন্টদের পূর্বরূপের প্রয়োজন হয় না তারা ভাঙবে না।

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

3. ক্লায়েন্ট পক্ষের পূর্বরূপ যুক্তি সরাতে।

Comments

একটি শিরোলেখ পাঠানো সম্পর্কে কী বলা হয়েছে যে "এটি টিকিয়ে রাখবে না, কেবল আমাকে কী-যদি দেখান"? আপনার কাছে @

— আর্সেনি

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

— আর্সেনী মোরজেঙ্কো

আমার ক্ষেত্রে আমার বিকল্পের জন্য 1 বিকল্পের স্যুটটি আরও ভাল। সুতরাং আপনি পূর্বনির্ধারিত কনফিগারেশনটি পোস্ট করুন এবং প্রতিটি সংজ্ঞায়িত সংস্থার জন্য পূর্বরূপের শেষ বিন্দুগুলি সংজ্ঞায়িত না করে পরিবর্তিত ফলাফলগুলি পাবেন। যুক্তিযুক্ত মনে হয়। প্রযুক্তিগতভাবে বলতে গেলে সার্ভারে কোনও পরিবর্তন আনার জন্য আপনি কেবল একটি পোষ্ট ব্যবহার করছেন। বিকল্প 3 আমার ক্ষেত্রে অচল।

— এক্সট্রিম বাইকার মনিকা

@ পেড্রোবার্নেক আপনি কি এর উপর প্রসারিত করতে পারেন? আমার কাছে মনে হয় যে বিকল্প 2 অন্য সত্তা (একটি খসড়া কনফিগারেশন) সংজ্ঞায়িত করে এবং তাদের সাথে যোগাযোগের জন্য রাষ্ট্রবিহীন উপায় সরবরাহ করে।

— অ্যান্ড্রু বলছেন

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

— jpmc26

Answer 2

আরইএসটি-তে বিভিন্ন এপিআই কলগুলির জন্য নির্দিষ্ট এইচটিটিপি ক্রিয়াগুলি ব্যবহার করার বিষয়টি হ'ল বিদ্যমান এইচটিটিপি মেকানিক্স এবং প্রত্যাশাগুলি লাভ করা।

এই ক্ষেত্রে একটি জিইটি ব্যবহার করা উভয়ের বিপরীতে চলেছে বলে মনে হচ্ছে।

উ: ক্লায়েন্টকে জিইটি সহ কোনও দেহ অন্তর্ভুক্ত করা দরকার? অপ্রত্যাশিত

খ। সার্ভার শরীরের উপর নির্ভর করে একটি প্রাপ্তিতে আলাদা প্রতিক্রিয়া দেয়? স্পেক এবং ক্যাশিং মেকানিকগুলি ভঙ্গ করে

আপনি যদি বিশ্রামের প্রশ্নগুলির সাথে লড়াই করে থাকেন তবে আমার নিয়মটি নিজেকে জিজ্ঞাসা করা।

"সবকিছুর জন্য কেবল পোস্ট ব্যবহার করার চেয়ে এটি কীভাবে ভাল?"

তাত্ক্ষণিক এবং সুস্পষ্ট সুবিধা না হলে জাস্ট ইউজ পোস্ট স্টুপিড (JUPS) কৌশলটি নিয়ে যান

Comments

হাহাহাহা ভাল ক্যাচ

— এক্সট্রিম বাইকার মনিকা

@ ইওয়ান ... এটি ব্যবহারিক পদ্ধতি কিনা বা তা নির্বিশেষে ... আপনি যদি সমস্ত কিছু জন্য POST ব্যবহার করেন তবে এটি লক্ষ্য করা উচিত যে এটি আসলে বিশ্রামের নয়।

— অ্যালেন্ফ

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

— ইয়ান

Answer 3

আপনি একটি শিরোনাম প্রেরণ করতে পারেন যা সার্ভারের সাথে ইঙ্গিত করে "এটি অবিরত রাখবেন না, কেবল যদি আপনি করেন তবে ফলাফলটি কী হবে তা আমাকে দেখান"। যেমন

POST /api/config HTTP/1.1
Host: api.mysite.com
Content-Type: application/json
Persistence-Options: simulate

{
   "config": {
      "key": "value"
   }
}

যার প্রতি সার্ভার সাড়া দিতে পারে:

HTTP/1.1 200 OK
Persistence-Options: simulated
Content-Type: application/json

-- preview --

---

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

Comments

সরঞ্জামস.ইএইটিএফ.আর.এইচটিএমএল

— পিটার রেডার

ভাল পয়েন্ট @PeterRader সরানোX-

— marstato

আপনার স্বাগত। আপনি কি বলবেন যে সিমুলেশন অধীনে একটি সত্তা "সিমুলেশন আন্ডার" হিসাবে প্রতিনিধিত্ব করা উচিত?

— পিটার রেডার

না; একটি সিমুলেশন বিন্দু না, তাই না? শিরোনাম মানটিও হতে পারে noneতবে তা হবে - আমার স্বাদের জন্য - POSTপদ্ধতির প্রকৃতির সাথে খুব বেশি বিরোধিতা করা ।

— মার্সাতেটো

Answer 4

আপনি অনুসন্ধানগুলির সাথে একইভাবে আচরণ করার পরামর্শ দিচ্ছি। আমি একটি পোষ্ট শেষ পয়েন্ট সেট আপ করব /api/config/previewযেখানে একটি নতুন পূর্বরূপ তৈরি করে। তারপরে api/configআপনি বর্তমান কনফিগারেশনটি সম্পাদনা করতে চান বা পুরো কনফিগারেশনটি প্রতিস্থাপন করবেন কিনা তার উপর নির্ভর করে আমি একটি পুট বা প্যাচ এন্ড পয়েন্ট সেট আপ করব (সম্ভবত পূর্ববর্তী ক্ষেত্রে আপনি সদ্য তৈরি পূর্বরূপটি প্রেরণ করবেন)।

Answer 5

অন্যান্য ভাল উত্তরের পাশাপাশি, অন্য একটি বিকল্প হতে পারে উল্লিখিত মতো কনফিগারেশন পোস্ট করা এবং রোলব্যাক প্রক্রিয়াও উপলভ্য। আমি মনে করি, এগিল পদ্ধতিটির মতো আরও দানাদার, পুনরাবৃত্তিযোগ্য এবং পরীক্ষামূলক পদ্ধতি ব্যবহারের দ্বারা পরিবর্তনগুলি সম্পর্কে কম ভয় পাওয়ার থেকে ভাল এবং প্রয়োগের উপর নির্ভর করে ঝুঁকি কম বা কমিয়ে আনা হলে এটি আপনাকে ব্যাকআপ দেবে would ।

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

Answer 6

আরএফসি 6648 নতুন X-নির্মাণকে অবমূল্যায়ন করে তাই আমাকে নতুন শিরোনামের ক্ষেত্রটি প্রেরণের জন্য ধারণার বিরুদ্ধে ভোট দিতে হবে। REST হ'ল একটি আর্কিটেকচার শৈলী, আমরা যে বিষয়ে কথা বলি তা বিশিষ্ট - তবে এই মুহুর্তের জন্য এটিকে উপেক্ষা করা যাক।

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

GET  /api/emulation - 200 OK {first:1, last:123}
POST /api/emulation/124 - 200 OK
GET  /api/emulation/124/config - 200 OK {config:{tax:8}}
PUT  /api/emulation/124/config {config:{tax:16}} - 200 OK {config:{tax:16}}
GET  /api/emulation/124/items - 200 OK [first:1, last: 3000]
GET  /api/emulation/124/items/1 - 200 OK {price:1.79, name:'Cup'}
--- show emulation ---
--- commit emulation ---
PUT /api/config {config:{tax:16}}
DELETE /api/emulation/124 - 200 OK

অন্য পদ্ধতি আছে .... আপনি সম্ভবত লক্ষ্য করেছেন যে এইচটিএমএল / জাভাস্ক্রিপ্ট-ক্লায়েন্টের কাছ থেকে প্রচুর অনুরোধ থাকা অনেকগুলি অনুরোধ তৈরি করতে পারে যা একই সময়ে প্রায় 17 টি অনুরোধের সীমাতে পৌঁছে যায় ( এই পৃষ্ঠাটি দেখুন )। আপনি আরআরএসটি ব্যবহারের অদলবদল করতে পারেন এবং খোঁড়া বস্তু-রাজ্যগুলি সরবরাহের পরিবর্তে আপনি সমৃদ্ধ ব্যবহারকারী-নির্দিষ্ট পৃষ্ঠাগুলি সরবরাহ করতে পারেন। উদাহরণ:

GET /user/123/config - 200 OK {user:'Tim', date:3298347239847, currentItem:123, 
                  roles:['Admin','Customer'], config:{tax:16}, unsavedChanges:true, ...}

আন্তরিক শুভেচ্ছা