যদি একাধিক ক্রিয়াকলাপ বিভিন্ন স্ট্যাটাসের সাথে শেষ হয় তবে কোন HTTP স্থিতি কোডটি ফিরে আসবে?


72

আমি এমন একটি এপিআই তৈরি করছি যেখানে ব্যবহারকারী সার্ভারকে একটি এইচটিটিপি অনুরোধে একাধিক ক্রিয়া সম্পাদন করতে বলতে পারে। প্রতিটি ক্রিয়াকলাপের জন্য একটি এন্ট্রি সহ ফলাফলটি JSON অ্যারে হিসাবে ফিরে আসে।

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

যদি ক্রমানুসারে একটি অনুরোধ থাকে তবে আমি স্থিতি কোডগুলি যথাক্রমে 200, 422 এবং 500 ফিরিয়ে দেব। তবে এখন যখন কেবল একটি অনুরোধ থাকবে, আমি কোন স্ট্যাটাস কোডটি ফিরিয়ে দেব?

কিছু বিকল্প:

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

3
আপনার প্রশ্ন আমাকে অন্য একটি সম্পর্কে ভাবতে বাধ্য করেছে: প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জার
কুইকশানস

7
সামান্যভাবে সম্পর্কিত এছাড়াও: প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জার / প্রশ্নগুলি

4
এই অনুরোধগুলি একসাথে ভাগ করে আপনি কী লাভ করবেন? এটি কি ব্যবসায়িক যুক্তি সম্পর্কিত, একাধিক সংস্থার উপর লেনদেনের মতো, বা এটি কর্মক্ষমতা সম্পর্কে? অথবা অন্য কিছু?
লস ফ্রাঙ্কেন

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

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

উত্তর:


21

সংক্ষিপ্ত, সরাসরি উত্তর

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


দীর্ঘ, দার্শনিক উত্তর

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

উপরের দিকে বলা হচ্ছে এবং এই উত্তরটিকে দীর্ঘ মতামতযুক্ত গাইডে পরিণত করার সাহস ছাড়াই নিম্নলিখিতটি একটি ইউআরআই স্কিম যা সংস্থান পরিচালনার পদ্ধতির সাথে সঙ্গতিপূর্ণ:

  • /tasks
    • GET সমস্ত কাজ তালিকাভুক্ত, পৃষ্ঠাযুক্ত
    • POST একটি একক কাজ যোগ করুন
  • /tasks/task/[id]
    • GET একক টাস্কের স্টেট অবজেক্টের সাথে সাড়া দেয়
    • DELETE কোনও কাজ বাতিল / মুছে দেয়
  • /tasks/groups
    • GET সমস্ত টাস্ক গ্রুপ তালিকাভুক্ত, পৃষ্ঠাযুক্ত
    • POST কাজের একটি গ্রুপ যুক্ত করে
  • /tasks/groups/group/[id]
    • GET একটি টাস্ক গ্রুপের রাষ্ট্রের সাথে প্রতিক্রিয়া জানায়
    • DELETE টাস্ক গ্রুপ বাতিল / মুছে দেয়

এই কাঠামোটি তাদের কী করবেন তা নয়, সম্পদের বিষয়ে কথা বলে। সম্পদ দিয়ে যা করা হচ্ছে তা হ'ল অন্য একটি পরিষেবার উদ্বেগ।

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

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


এই জাতীয় ইউআরআই স্কিমটি কীভাবে ব্যবহৃত হবে তার কয়েকটি উদাহরণ

একটি একক কার্য সম্পাদন এবং ট্র্যাকিং অগ্রগতি:

  • POST /tasks কার্য সম্পাদনের জন্য
    • GET /tasks/task/[id]প্রতিক্রিয়া অবজেক্টের completedবর্তমান অবস্থা / অগ্রগতি দেখানোর সময় ইতিবাচক মান না পাওয়া পর্যন্ত

একটি একক কার্য সম্পাদন এবং এর সমাপ্তির অপেক্ষায়:

  • POST /tasks কার্য সম্পাদনের জন্য
    • GET /tasks/task/[id]?awaitCompletion=truecompletedইতিবাচক মান না হওয়া পর্যন্ত (সম্ভবত সময়সীমা শেষ হতে পারে, এ কারণেই এটি লুপ করা উচিত)

একটি টাস্ক গ্রুপ কার্যকর করা এবং অগ্রগতি ট্র্যাক করা:

  • POST /tasks/groups কার্য সম্পাদনের জন্য গ্রুপের সাথে
    • GET /tasks/groups/group/[groupId]প্রতিক্রিয়ার অবজেক্টের completedসম্পত্তিটির মূল্য না হওয়া পর্যন্ত পৃথক কার্য স্থিতি দেখানো হয় (উদাহরণস্বরূপ 5 টির মধ্যে 3 টি কার্য সম্পন্ন হয়)

কোনও কার্য গ্রুপের জন্য মৃত্যুদণ্ডের অনুরোধ এবং এর সমাপ্তির অপেক্ষায়:

  • POST /tasks/groups কার্য সম্পাদনের জন্য গ্রুপের সাথে
    • GET /tasks/groups/group/[groupId]?awaitCompletion=true ফলস্বরূপ প্রতিক্রিয়া না দেওয়া পর্যন্ত যা সমাপ্তি নির্দেশ করে (সম্ভবত সময়সীমা শেষ হতে পারে, তাই লুপ করা উচিত)

আমি মনে করি যা অর্থহীনভাবে বোঝায় সে সম্পর্কে কথা বলাই এটির কাছে যাওয়ার সঠিক উপায়। ধন্যবাদ!
অ্যান্ডার্স

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

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

87

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

এই লিঙ্কটি থেকে অনুলিপি / আটকান:

একটি মাল্টি-স্ট্যাটাস প্রতিক্রিয়া এমন পরিস্থিতিতে একাধিক সংস্থান সম্পর্কে তথ্য জানায় যেখানে একাধিক স্থিতি কোডগুলি উপযুক্ত হতে পারে। ডিফল্ট মাল্টি-স্ট্যাটাস প্রতিক্রিয়া বডি হ'ল 'মাল্টিস্ট্যাটাস' মূল উপাদান সহ একটি পাঠ্য / এক্সএমএল বা অ্যাপ্লিকেশন / এক্সএমএল এইচটিটিপি সত্তা। পদ্ধতি অনুরোধের সময় পরবর্তী উপাদানগুলিতে 200, 300, 400 এবং 500 সিরিজের স্থিতি কোড রয়েছে। 100 সিরিজের স্থিতি কোডগুলি কোনও 'প্রতিক্রিয়া' XML উপাদানটিতে রেকর্ড করা উচিত নয়।

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


22
207ওপি যা চায় তা মনে হয় তবে আমি সত্যিই জোর দিয়ে বলতে চাই যে এটি সম্ভবত একাধিক-অনুরোধে এই একাধিক পদ্ধতির কাছে আসা একটি খারাপ ধারণা। উদ্বেগ অবদান হলে আপনি ক্লাউড-শৈলী অনুভূমিকভাবে মাপযোগ্য সিস্টেমের জন্য architecting হবে (যা কিছু যে HTTP ভিত্তিক সিস্টেম এ মহান হয়)
ডেভিড Grinberg

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

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

8
টমটম, ওপি পারমাণবিকতা চায় না । এটি নকশা করা আরও সহজ জিনিস হবে, কারণ একটি পারমাণবিক অপারেশনের শুধুমাত্র একটি স্ট্যাটাস রয়েছে। এছাড়াও, এইচটিটিপি স্পেকটি এইচটিটিপি / ২ মাল্টিপ্লেক্সিংয়ের মাধ্যমে পারফরম্যান্সের জন্য ব্যাচিং ক্রিয়াকলাপের অনুমতি দেয় (প্রাকৃতিকভাবে, এইচটিটিপি / ২ সমর্থন অন্য জিনিস, তবে অনুমানটি এটির অনুমতি দেয়)।
পল

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

24

যদিও মাল্টি-স্ট্যাটাসটি একটি বিকল্প, সমস্ত অনুরোধ সফল হলে এবং অন্যথায় একটি ত্রুটি (500 বা হতে পারে 207) যদি আমি 200 (সমস্ত ভাল) ফিরে আসি।

স্ট্যান্ডার্ড কেসটি সাধারণত 200 হওয়া উচিত - সবকিছু কাজ করে। এবং ক্লায়েন্টদের কেবল এটির জন্য পরীক্ষা করা উচিত। এবং কেবল ত্রুটি-কেস হলেই আপনি 500 (বা একটি 207) ফিরিয়ে দিতে পারবেন। আমি মনে করি কমপক্ষে একটি ত্রুটির ক্ষেত্রে 207 একটি বৈধ পছন্দ, তবে আপনি যদি পুরো প্যাকেজটিকে এক লেনদেন হিসাবে দেখেন তবে আপনি 500 টিও পাঠাতে পারেন The ক্লায়েন্ট ত্রুটি-বার্তাটি যে কোনওভাবে ব্যাখ্যা করতে চাইবে।

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


6
আমি বেশ রাজি হই না। যদি 1 এবং 3 সাবক্রিস্ট সফল হয়, আপনি একটি সম্মিলিত সংস্থান পাবেন এবং যাইহোক সম্মিলিত প্রতিক্রিয়াটি পরীক্ষা করতে হবে। আপনার আরও একটি কেস বিবেচনা করার দরকার আছে। যদি প্রতিক্রিয়া = 200 বা সাবস্ক্রেশন 1 = 200 হয় তবে অনুরোধ 1 সফল হয়েছে। যদি প্রতিক্রিয়া = 200 বা সাবস্ক্রেশন 2 = 200 হয় তবে কেবল সাব প্রতিক্রিয়াটি পরীক্ষা করার পরিবর্তে 2 টি সফল হওয়ার অনুরোধ করুন।
gnasher729

1
@ gnasher729 এটি আবেদনের উপর নির্ভর করে। আমি একটি ব্যবহারকারী দ্বারা চালিত ক্রিয়াটি কল্পনা করি, যখন সমস্ত অনুরোধগুলি সফল হয় তখন (সমস্ত কিছু ঠিক আছে) সহ পরবর্তী পদক্ষেপে চলে আসবে। - যদি কোনও কিছু ভুল হয়ে যায় (বৈশ্বিক রাষ্ট্র <= 200) তবে আপনাকে বিশদ ত্রুটি প্রদর্শন করতে হবে এবং কর্মপ্রবাহ বদলাতে হবে এবং প্রতিটি সাব্রাইকেস্টের জন্য কেবলমাত্র একক চেক প্রয়োজন, যেহেতু আপনি "হ্যান্ডেলমিক্সডস্টেট" ফাংশনে আছেন এবং "হ্যান্ডেলএলওক" ফাংশনটি নয় ।
ফ্যালকো

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

সাধারণ সমস্যা থাকলে (উদাহরণস্বরূপ ডেটাবেস ডাউন হয়ে থাকে) আমিও সম্ভবত একটি 500 প্রেরণ করব তাই সার্ভারটি স্বতন্ত্র অনুরোধগুলি চেষ্টা করে না, তবে কেবল একটি সাধারণ ত্রুটি ফিরে আসতে পারে। - কারণ ব্যবহারকারীর জন্য 3 টি পৃথক ফলাফল রয়েছে 1. সব ঠিক আছে, 2. সাধারণ সমস্যা, কিছুই কাজ করে না, 3. কিছু অনুরোধ ব্যর্থ হয়েছে। -> যা সাধারণত সম্পূর্ণ আলাদা প্রোগ্রাম-প্রবাহে নিয়ে যায়।
ফালকো

1
ঠিক আছে, সুতরাং একটি পদ্ধতির হবে: 207 = প্রতিটি অনুরোধের জন্য পৃথক স্থিতি। অন্য যে কোনও কিছু: স্থিতি প্রতিটি অনুরোধের জন্য প্রযোজ্য। 200, 401, ≥ 500 এর জন্য অর্থ প্রদান করে
gnasher729

13

একটি বিকল্প হ'ল সর্বদা একটি স্ট্যাটাস কোড 200 ফিরিয়ে দেওয়া এবং তারপরে আপনার জেএসওএন ডকুমেন্টের বডিটিতে নির্দিষ্ট ত্রুটিগুলি ফিরিয়ে দেওয়া। কিছু এপিআই নকশাকৃতভাবে ঠিক এটি হয় (তারা সর্বদা একটি স্ট্যাটাস কোড 200 ফিরিয়ে দেয় এবং ত্রুটিটি শরীরে প্রেরণ করে)। বিভিন্ন পদ্ধতির বিষয়ে আরও তথ্যের জন্য দেখুন http://archive.oreilly.com/pub/post/restful_error_handling.html


2
এই ক্ষেত্রে, আমি 200সমস্তটি ভালভাবে নির্দেশিত করার জন্য অনুরোধটি ব্যবহার করার ধারণাটি পছন্দ করি , অনুরোধটি গৃহীত হয়েছিল এবং বৈধ ছিল , এবং তারপরে সেই অনুরোধে কী ঘটেছিল (অর্থাৎ লেনদেনের ফলাফল) সম্পর্কে বিশদ সরবরাহ করতে JSON ব্যবহার করুন।
রিকনাগনি

4

আমার মনে হয় নীলসিম্প 1 সঠিক, তবে আমি আপনাকে ডেটা এমনভাবে প্রেরণ করা হচ্ছে যাতে আপনি একটি প্রেরণ করতে পারেন 206 - Acceptedএবং পরে ডেটা প্রক্রিয়া করতে পারেন। সম্ভবত কলব্যাক দিয়ে।

একক অনুরোধে একাধিক ক্রিয়াকলাপ প্রেরণের চেষ্টা করার সমস্যাটি হ'ল সত্য যে প্রতিটি ক্রিয়াটির নিজস্ব "স্থিতি" থাকা উচিত

একটি সিএসভি আমদানির দিকে তাকানো (আমি জানি না ওপিটি আসলে কী তা তবে এটি একটি সাধারণ সংস্করণ)। সিএসভি পোস্ট করুন এবং একটি 206 ফিরে পান Then

POST /imports/ -> 206
GET  /imports/1 -> 200
GET  /imports/1/errors -> 200 -> Has a list of errors

এই একই প্যাটার্নটি অনেকগুলি ব্যাচের পছন্দগুলিতে প্রয়োগ করা যেতে পারে

POST /operations/ -> 206
GET  /operations/1 -> 200
GET  /operations/1/errors -> 200 - > Has a list of errors.

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


2

ইতিমধ্যে এখানে অনেক ভাল উত্তর রয়েছে, তবে একটি দিক অনুপস্থিত:

আপনার ক্লায়েন্টদের প্রত্যাশার চুক্তি কী?

এইচটিটিপি রিটার্ন কোডগুলিতে কমপক্ষে একটি সাফল্য / ব্যর্থতার পার্থক্য চিহ্নিত করা উচিত এবং এভাবে "দরিদ্র ব্যক্তির ব্যতিক্রম" এর ভূমিকা পালন করা উচিত। তারপরে 200 অর্থ "চুক্তি সম্পূর্ণরূপে সম্পন্ন হয়েছে", এবং 4XX বা 5XX বাস্তবায়নে ব্যর্থতা নির্দেশ করে।

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

একটি ভিন্ন কাল্পনিক চুক্তি হতে পারে "সমস্ত ক্রিয়া করার চেষ্টা করুন"। তারপরে এটি সম্পূর্ণরূপে চুক্তির সাথে সামঞ্জস্যপূর্ণ (যদি কিছু) ক্রিয়া ব্যর্থ হয়। সুতরাং আপনি সর্বদা ২০০ টি প্লাস ফলাফলের নথিটি ফিরিয়ে আনবেন যেখানে আপনি পৃথক কাজের জন্য সাফল্য / ব্যর্থতার তথ্য পাবেন।

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

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


0

উত্তর:

ক্রিয়া প্রতি কেবল একটি অনুরোধ ব্যবহার করুন এবং অতিরিক্ত ওভারহেড গ্রহণ করুন।

একটি স্থিতি কোড একটি অপারেশনের স্থিতি বর্ণনা করে। সুতরাং, অনুরোধ অনুযায়ী একটি অপারেশন করা বোধগম্য।

একাধিক স্বতন্ত্র ক্রিয়াকলাপগুলি অনুরোধ-প্রতিক্রিয়া মডেল এবং স্থিতি কোডগুলির উপর ভিত্তি করে প্রধানকে ভেঙে দেয়। আপনি প্রকৃতির সাথে লড়াই করছেন।

HTTP / 1.1 এবং HTTP / 2 HTTP অনুরোধগুলির ওভারহেডকে অনেক কম করেছে। আমি অনুমান করি যে খুব কম পরিস্থিতি আছে যেখানে স্বতন্ত্র অনুরোধগুলির ব্যাচিংয়ের পরামর্শ দেওয়া হয়।


বলেছিল,

(1) আপনি প্যাচ অনুরোধের মাধ্যমে একাধিক পরিবর্তন করতে পারেন ( আরএফসি 5789 )। যাইহোক, এর জন্য প্রয়োজন স্বাধীন নয় পরিবর্তনের জন্য; সেগুলি পরমাণুভাবে প্রয়োগ করা হয় (সমস্ত বা কিছুই নয়)।

(2) অন্যরা 207 মাল্টি-স্ট্যাটাস কোডটি নির্দেশ করেছেন। তবে এটি কেবল ওয়েবডিএভি ( আরএফসি 4918 ) এর জন্য সংজ্ঞায়িত করা হয়েছে , এটি HTTP- র একটি এক্সটেনশান।

207 (মাল্টি-স্ট্যাটাস) স্থিতি কোড একাধিক স্বতন্ত্র ক্রিয়াকলাপের জন্য স্থিতি সরবরাহ করে (আরও তথ্যের জন্য বিভাগ 13 দেখুন)।

...

একটি মাল্টি-স্ট্যাটাস প্রতিক্রিয়া এমন পরিস্থিতিতে একাধিক সংস্থান সম্পর্কে তথ্য জানায় যেখানে একাধিক স্থিতি কোডগুলি উপযুক্ত হতে পারে। 'মাল্টিস্ট্যাটাস' মূল [এক্সএমএল] উপাদানটি কোনও ক্রমে শূন্য বা ততোধিক 'প্রতিক্রিয়া' উপাদান রাখে, প্রতিটি স্বতন্ত্র সংস্থান সম্পর্কে তথ্য সহ।

একটি 207 ওয়েবডিএভি এক্সএমএল প্রতিক্রিয়া আ নন-ওয়েবডিএভি এপিআইয়ের হাঁসের মতই বিজোড়। এটি করবেন না।


1
আপনি মূলত জোর দিয়ে বলছেন যে @ আন্ডারদের একটি এক্সওয়াই সমস্যা আছে । আপনি সঠিক হতে পারেন, তবে দুর্ভাগ্যক্রমে, এর অর্থ হল যে তিনি জিজ্ঞাসা করা প্রশ্নের উত্তরটি আপনি আসলে দিয়েছেন না (মাল্টি-অ্যাকশন অনুরোধের জন্য কোন স্ট্যাটাস কোডটি ব্যবহার করা হবে)।
Azuaron

2
@ আজুয়ারন, বাচ্চাদের মারধরের জন্য কোন ধরণের বেল্ট সবচেয়ে ভাল কাজ করে? আমি মনে করি "এন / এ" একটি অনুমোদিত উত্তর। এছাড়াও, আন্দ্রেস তার ধারণাগুলির তালিকায় একাধিক অনুরোধ অন্তর্ভুক্ত করেছিলেন। আমি আন্তরিকভাবে এই বিকল্পটি সমর্থন করেছি।
পল

আমি একরকম মিস করেছি যে সে তালিকাবদ্ধ করেছে। সেক্ষেত্রে আমি দৃ it's়ভাবে জিজ্ঞাসা করছি এটি একটি নির্বোধ প্রশ্ন, আপনার অনার!
Azuaron

1
@ আজুয়ারন আমি পুরোপুরি ভাবে মনে করি এটি একটি বৈধ উত্তর। আমি যদি এটির সব ভুল করে নিই তবে আমি চাই যে কেউ এ কথা বলুক, এবং কীভাবে একটি ক্লিফটি সরিয়ে নেওয়া যায় সে সম্পর্কে আমাকে নির্দেশনা দিবেন না।
অ্যান্ডার্স

1
207 প্রতিক্রিয়াতে JSON পাঠাতে কোনও কিছুই নিষেধ করে না, যতক্ষণ না কন্টেন্ট-টাইপ শিরোনাম যথাযথভাবে সেট করা থাকে এবং ক্লায়েন্ট যা জিজ্ঞাসা করেছিল তার সাথে মেলে (শিরোনাম গ্রহণ করুন)।
ডলম্যান

0

যদি আপনার সত্যিই একটি অনুরোধে একাধিক ক্রিয়া থাকা দরকার, তবে সমস্ত ক্রিয়াকলাপ কেন ব্যাকএন্ডে লেনদেনের মধ্যে আবদ্ধ করবেন না? এইভাবে তারা হয় সবাই সফল হয় বা সমস্ত ব্যর্থ হয়।

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


2
আমি ধরে নিলাম অনুরোধটি যদি পারমাণবিক হয় তবে তিনি এই প্রশ্নটি পোস্ট করবেন না।
অ্যান্ডি

@ অ্যান্ডি হতে পারে, তবে আপনি ধরে নিতে পারবেন না যে তিনি এই জাতীয় ডিজাইনের সমস্ত বিষয় বিবেচনা করেছেন।
ডিন

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