"এখনও প্রক্রিয়াজাতকরণ" এর জন্য এইচটিটিপি স্থিতির কোড


47

আমি একটি RESTful এপিআই তৈরি করছি যা শেষ হ্যান্ডলিংয়ের জন্য দীর্ঘ-চলমান কার্যগুলিকে সন্ধান করে supports

এই API এর জন্য আদর্শ ওয়ার্কফ্লোটি হ'ল:

  1. ব্যবহারকারী ফর্ম পূরণ করে
  2. ক্লায়েন্ট এপিআইতে ডেটা পোস্ট করে
  3. এপিআই 202 স্বীকৃত রিটার্ন দেয়
  4. ক্লায়েন্ট ব্যবহারকারীকে সেই অনুরোধের জন্য একটি অনন্য URL এ পুনঃনির্দেশ করে ( /results/{request_id})
  5. ~ অবশেষে ~
  6. ক্লায়েন্ট আবার ইউআরএল পরিদর্শন করে এবং সেই পৃষ্ঠাতে ফলাফলগুলি দেখে।

আমার সমস্যাটি ধাপে 6.. পদে যখন কোনও ব্যবহারকারী পৃষ্ঠাটি দেখেন, আমি আমার API ( GET /api/results/{request_id}) এ অনুরোধ জানাই । আদর্শভাবে, টাস্কটি এতক্ষণে শেষ হয়ে গিয়েছে এবং আমি তাদের কাজের ফলাফলের সাথে একটি 200 ওকে ফিরিয়ে দেব।

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

স্থিতি কোডের জন্য আমার সেরা বিকল্পটি কী তা নির্দেশ করতে পারে:

  • এই অনুরোধ বিদ্যমান,
  • এটি এখনও করা হয়নি,
  • তবে এটিও ব্যর্থ হয়নি।

আমি একক কোডটি এই সমস্তটি সম্পর্কে যোগাযোগ করার আশা করি না তবে আমি এমন কিছু চাই যা ক্লায়েন্টের সামগ্রীর প্রত্যাশার পরিবর্তে আমাকে মেটাডেটা পাস করতে দেয়।

২০২০ ফেরত আসাটা বোধগম্য হতে পারে, যেহেতু এখানে এর অন্য কোনও অর্থ থাকবে না: এটি একটি GETঅনুরোধ, সুতরাং কোনও কিছুই সম্ভবত "গৃহীত" হচ্ছে না। এটা কি যুক্তিসঙ্গত পছন্দ হবে?

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

200 OK

{
    status: "complete",
    data: {
        foo: "123"
    }
}

... অথবা ...

200 OK

{
    status: "pending"
}

তারপরে ক্লায়েন্ট-সাইড, অনুরোধটি সম্পন্ন হয়েছে কিনা তা নির্ধারণ switchকরার response.data.statusজন্য আমি দীর্ঘশ্বাস ফেলব ।

এটা কি আমার করা উচিত? নাকি এর চেয়ে ভাল বিকল্প আছে? এটি আমার কাছে কেবল ওয়েব 1.0 বলে মনে হচ্ছে।


1
1XX কোডগুলি ঠিক সেই উদ্দেশ্যে তৈরি হয় না?
অ্যান্ডি

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

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

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

উত্তর:


48

HTTP 202 স্বীকৃত (HTTP / 1.1)

আপনি HTTP 202 Acceptedস্থিতি খুঁজছেন । আরএফসি 2616 দেখুন :

প্রক্রিয়াজাতকরণের জন্য অনুরোধটি গ্রহণ করা হয়েছে, তবে প্রক্রিয়াজাতকরণ শেষ হয়নি।

HTTP 102 প্রসেসিং (ওয়েবডিএভি)

আরএফসি 2518 ব্যবহারের পরামর্শ দেয় HTTP 102 Processing:

১০২ (প্রসেসিং) স্থিতি কোডটি একটি অন্তর্বর্তীকালীন প্রতিক্রিয়া যা ক্লায়েন্টকে জানাতে ব্যবহৃত হয় যে সার্ভারটি সম্পূর্ণ অনুরোধটি স্বীকার করেছে, তবে এটি এখনও সম্পূর্ণ করেনি।

তবে এটি একটি সতর্কতা আছে:

অনুরোধটি শেষ হওয়ার পরে সার্ভারটি চূড়ান্ত প্রতিক্রিয়া প্রেরণ করবে।

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

উদাহরণস্বরূপ, দীর্ঘ কিন্তু লিনিয়ার প্রক্রিয়াটির জন্য, আপনি প্রতিটি চরিত্রের পরে ফ্লাশ করে একশ ডট প্রেরণ করতে পারেন। যদি ক্লায়েন্ট পক্ষ (যেমন একটি জাভাস্ক্রিপ্ট অ্যাপ্লিকেশন) জানে যে এটি ঠিক 100 টি অক্ষর আশা করতে পারে তবে এটি ব্যবহারকারীর কাছে প্রদর্শন করার জন্য এটি একটি অগ্রগতি বারের সাথে মিলিয়ে দিতে পারে।

আর একটি উদাহরণ এমন একটি প্রক্রিয়া সম্পর্কিত যা বেশ কয়েকটি অ-রৈখিক পদক্ষেপ নিয়ে গঠিত concerns প্রতিটি পদক্ষেপের পরে, আপনি একটি লগ বার্তা ফ্লাশ করতে পারেন যা শেষ পর্যন্ত ব্যবহারকারীর কাছে প্রদর্শিত হবে, যাতে শেষ ব্যবহারকারীটি প্রক্রিয়াটি কীভাবে চলছে তা জানতে পারে।

প্রগতিশীল ফ্লাশিং সহ সমস্যাগুলি

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

আরও ভাল পদ্ধতির সাথে সাড়া দেওয়া HTTP 202 Acceptedএবং হয় প্রক্রিয়াটি শেষ হয়েছে কিনা তা নির্ধারণ করার জন্য ব্যবহারকারীকে পরে আপনার কাছে ফিরে আসতে দেওয়া (উদাহরণস্বরূপ বারবার কোনও প্রদত্ত ইউআরআই কল করে যেমন /process/resultHTTP 404 পাওয়া যায় নি বা প্রক্রিয়া না হওয়া পর্যন্ত HTTP 409 সংঘাতের সাথে প্রতিক্রিয়া জানায়) শেষ হয়ে যায় এবং ফলাফল প্রস্তুত হয়) বা আপনি যদি কোনও বার্তা সারি পরিষেবা ( উদাহরণস্বরূপ ) বা ওয়েবসকেটের মাধ্যমে ক্লায়েন্টকে কল করতে সক্ষম হন তবে প্রসেসিংয়ের সময় ব্যবহারকারীকে অবহিত করুন ।

ব্যবহারিক উদাহরণ

এমন কোনও ওয়েব পরিষেবা কল্পনা করুন যা ভিডিওগুলিকে রূপান্তর করে। প্রবেশের স্থানটি হ'ল:

POST /video/convert

যা HTTP অনুরোধ থেকে একটি ভিডিও ফাইল নেয় এবং এটি দিয়ে কিছু যাদু করে। আসুন কল্পনা করুন যে যাদুটি সিপিইউ-নিবিড়, তাই অনুরোধের স্থানান্তরকালে এটি রিয়েল-টাইমে করা যায় না। এর অর্থ এই যে ফাইলটি স্থানান্তরিত হয়ে গেলে সার্ভারটি HTTP 202 Acceptedকিছু জেএসওএন সামগ্রী দিয়ে একটি প্রতিক্রিয়া জানাবে যার অর্থ হ্যাঁ, আমি আপনার ভিডিও পেয়েছি এবং আমি এতে কাজ করছি; এটি ভবিষ্যতে কোথাও প্রস্তুত হবে এবং আইডি 123 এর মাধ্যমে পাওয়া যাবে ”

প্রসেসিং শেষ হওয়ার পরে ক্লায়েন্টের কাছে একটি বার্তা কাতারে সাবস্ক্রাইব হওয়ার সম্ভাবনা রয়েছে। এটি শেষ হয়ে গেলে, ক্লায়েন্ট প্রক্রিয়াজাত ভিডিওটি এখানে যেতে পারেন:

GET /video/download/123

যা একটি বাড়ে HTTP 200

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

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

এই ক্ষেত্রে, আপনি অন্য একটি শেষ পয়েন্ট ব্যবহার করতে পারেন:

GET /video/status/123

যার ফলস্বরূপ এর প্রতিক্রিয়া হবে:

HTTP 200
{
    "id": 123,
    "status": "queued",
    "priority": 2,
    "progress-percent": 0,
    "submitted-utc-time": "2016-04-19T13:59:22"
}

অনুরোধটি বারবার করা এবং ততক্ষণ অগ্রগতি দেখাবে:

HTTP 200
{
    "id": 123,
    "status": "done",
    "progress-percent": 100,
    "submitted-utc-time": "2016-04-19T13:59:22"
}

এই তিন ধরণের অনুরোধের মধ্যে পার্থক্য করা অত্যন্ত গুরুত্বপূর্ণ:

  • POST /video/convertএকটি কাজ সারি। এটি কেবল একবার কল করা উচিত: এটিকে আবার কল করা অতিরিক্ত কাজ সারি করে।
  • GET /video/download/123অপারেশনের ফলাফল নিয়ে উদ্বেগ : সংস্থানটি ভিডিও। প্রক্রিয়াজাতকরণ - অনুরোধের পূর্বে এবং স্বতন্ত্রভাবে অনুরোধের আসল ফলাফল প্রস্তুত করার জন্য হুডের নীচে যা ঘটেছিল তা এখানে অপ্রাসঙ্গিক। এটি একবার বা একাধিকবার বলা যেতে পারে।
  • GET /video/status/123প্রতি সেমি প্রক্রিয়াজাতকরণ উদ্বেগ । এটি কিছু কিউ না। ফলস্বরূপ ভিডিওটি এটি যত্ন করে না। সম্পদ প্রক্রিয়াকরণ নিজেই। এটি একবার বা একাধিকবার বলা যেতে পারে।

1
একটি 202 একটি এর প্রতিক্রিয়া GET, যদিও? এটি অবশ্যই প্রাথমিকের জন্য সঠিক পছন্দ POST, যে কারণে আমি এটি ব্যবহার করছি। তবে GETযখন এটি নির্দিষ্ট অনুরোধ থেকে কোনও কিছু গ্রহণ না করে তখন "গ্রহণযোগ্য" বলা কোনওটির জন্য শব্দার্থগতভাবে সন্দেহজনক বলে মনে হয় ।
ম্যাথু হগেন

2
@ মাইনমা ​​যেমনটি আমি বলেছিলাম, আমি POSTসারিবদ্ধ হওয়ার জন্য কাজটি আপ করি , তখন GETক্লায়েন্ট সেশনটি বন্ধ করে দেওয়ার পরে আমি ফলাফলগুলি পাই । একটি 404 আমি ভাল হিসাবে বিবেচনা করে থাকেন, কিন্তু এটা ভুল বলে মনে হয়, যেহেতু অনুরোধ করা হয় পাওয়া, এটা ঠিক সম্পন্ন করা হয় নি। এটি আমার কাছে ইঙ্গিত করবে যে সারিবদ্ধভাবে কাজ পাওয়া যায় নি, যা খুব আলাদা পরিস্থিতি।
ম্যাথু হগেন

1
@ ম্যাথেজহোগেন: আপনি যখন GETঅংশটি করবেন তখন এটিকে অসম্পূর্ণ অনুরোধ হিসাবে ভাবেন না , তবে অপারেশনের ফলাফল পাওয়ার অনুরোধ হিসাবে । উদাহরণস্বরূপ, যদি আমি আপনাকে কোনও ভিডিও রূপান্তর করতে বলি এবং এটি করতে আপনাকে পাঁচ মিনিট সময় লাগে, দু'মিনিট পরে কোনও রূপান্তরিত ভিডিওর জন্য অনুরোধ করার ফলাফলটি এইচটিটিপি 404-এ হওয়া উচিত কারণ ভিডিওটি এখনও সেখানে নেই। , অপারেশন নিজেই অগ্রগতির অনুরোধ করা হচ্ছে অন্য দিকে, সম্ভবত একটি HTTP 200 বাইটের সংখ্যা রয়েছে যা রুপান্তরিত, গতি, ইত্যাদি পরিণাম ডেকে আনবে
আরসেনি Mourzenko

5
রিসোর্সের জন্য এইচটিটিপি স্থিতির কোড এখনও পাওয়া যায় না 409 বিরোধের প্রতিক্রিয়া ফিরিয়ে দেওয়ার পরামর্শ দেয় ("রিসোর্সের বর্তমান অবস্থার সাথে বিরোধের কারণে অনুরোধটি শেষ করা যায়নি।"), কোনও সংস্থান না হওয়ার ক্ষেত্রে 404 জবাবের পরিবর্তে এর অস্তিত্ব নেই কারণ এটি উত্পন্ন হওয়ার মাঝখানে রয়েছে।
ব্রায়ান

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

5

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

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

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

মনে রাখবেন এইচটিটিপি স্থিতি কোডগুলি সেই সংস্থার ক্লায়েন্ট এবং সার্ভারের সাথে রাষ্ট্রীয় স্থানান্তরের সাথে সম্পর্কিত হয়, স্বাধীনভাবে সেই সংস্থানটির যে কোনও বিবরণের সাথে সম্পর্কিত হয়। যখন আপনি GETকোনও সংস্থান করছেন যখন আপনার ক্লায়েন্ট সার্ভারকে বর্তমান অবস্থায় থাকা কোনও সংস্থার প্রতিনিধিত্বের জন্য জিজ্ঞাসা করছে That এটি কোনও পাখির ছবি হতে পারে, এটি একটি ওয়ার্ড ডকুমেন্ট হতে পারে, এটি বর্তমানের বাইরের টেম্প হতে পারে। এইচটিটিপি প্রোটোকল যত্ন করে না। এইচটিটিপি স্থিতি কোডটি অনুরোধের ফলাফলের সাথে মিলে যায়। কি POSTক্লায়েন্ট থেকে সার্ভারে সার্ভার, এর একটি সম্পদ হস্তান্তর যেখানে সার্ভার তারপর এটি একটি URL দিয়েছেন যে ক্লায়েন্ট দেখতে পাবেন? হ্যাঁ? তারপর যে একটি 201 Createdপ্রতিক্রিয়া।

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

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

ডোমেন নির্দিষ্ট স্টাফ ক্লায়েন্ট এবং সার্ভারের জন্য Content Typeসংস্থানটির উপর ভিত্তি করে নিজেদের মধ্যে নির্ধারণ করতে পারে । এইচটিটিপি প্রোটোকল এটি সম্পর্কে অজ্ঞেয়।

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

আশা করি যা বিষয়গুলিকে স্পষ্ট করতে সহায়তা করে


"ক্লায়েন্ট থেকে সার্ভারে পোষ্ট কি কোনও সংস্থান সার্ভারে স্থানান্তর করেছিল, যেখানে সার্ভার তখন ক্লায়েন্টটি দেখতে পারে এমন একটি URL দিয়েছে? হ্যাঁ? তারপরে এটি একটি 201 টি তৈরি প্রতিক্রিয়া response" 202 সার্ভারটি রিসোর্সটি প্রক্রিয়া করতে তাত্ক্ষণিকভাবে কাজ করতে না পারলে এটি ওপি যা করছে তা স্বীকার করার প্রতিক্রিয়া হিসাবেও গ্রহণযোগ্য।
অ্যান্ডি

1
জিনিসটি সার্ভারটি অবিলম্বে অভিনয় করছে acting এটি অবিলম্বে একটি ইউআরএল দিয়ে সংস্থান তৈরি করে। এটি কেবলমাত্র উত্সের স্থিতিটি "মুলতুবি" (বা কিছু)। এটি একটি ব্যবসায়িক ডোমেন রাষ্ট্র। যতক্ষণ HTTP প্রোটোকল সম্পর্কিত, সার্ভারটি উত্স তৈরি করার সাথে সাথেই কাজ করে এবং ক্লায়েন্টকে সংস্থানটির URL প্রদান করে URL আপনি এই সংস্থান পেতে পারেন। পোষ্ট অনুরোধ নিজেই মুলতুবি নেই। দুটি ভিন্ন ধারণাগত ডোমেনকে পৃথক করে রাখার অর্থ এই। যদি ক্লায়েন্ট কোনও আগুন প্রেরণ করে এবং পোষ্টের অনুরোধটি ভুলে যায় যে কয়েক ঘন্টা ধরে কাজ করা হয়নি তবে 202 প্রযোজ্য হবে।
করম্যাক মুলহাল

ইউআরএল উপস্থিত থাকলে কারওই পাত্তা নেই তবে আপনি যে ডেটাটি রিসোর্সটি উপস্থাপন করে তা পেতে পারেন না কারণ এটি এখনও প্রক্রিয়াধীন রয়েছে। ভিডিওটি পাওয়ার জন্য ইউআরএল তৈরি করা না পারা যেতে পারে।
অ্যান্ডি

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

4

আমি দেখেছি যুক্তিসংগত ব্লগ থেকে প্রস্তাবনা: বিশ্রাম ও দীর্ঘক্ষন ধরে চলা কাজ

সংক্ষেপ:

  1. স্থিতি পরীক্ষা করতে ক্লায়েন্টের জন্য একটি ইউআরআই-তে সেট করা "অবস্থান" শিরোনাম সহ "202 স্বীকৃত" কোডটি সার্ভারটি প্রদান করে, যেমন "/ সারি / 12345" client
  2. প্রক্রিয়াটি শেষ না হওয়া অবধি সার্ভার "200 ওকে" এবং কিছু প্রতিক্রিয়া ডেটার সাথে কাজের স্থিতি দেখায় স্থিতির প্রশ্নগুলিতে সাড়া দেয়।
  3. প্রসেসিং শেষ হওয়ার পরে, সার্ভার স্থিতির প্রশ্নগুলিতে "303 অন্যান্য দেখুন" এবং চূড়ান্ত ফলাফলটিতে ইউআরআই থাকা "অবস্থান" দিয়ে প্রতিক্রিয়া জানায়।

2

রিসোর্সের জন্য এইচটিটিপি স্থিতি কোড এখনও উপলভ্য নয় 4040 প্রতিক্রিয়ার চেয়ে 409 বিবাদ প্রতিক্রিয়া প্রত্যাবর্তনের পরামর্শ দেয়, যদি কোনও সংস্থান তৈরি না হওয়ার মাঝখানে থাকে তবে এই সংস্থার অস্তিত্ব নেই।

থেকে W3 বৈশিষ্ট :

10.4.10 409 সংঘাত

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

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

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

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

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


409 এর সত্যিকার অর্থে কী বোঝানো হয়েছে, যা একটি পুটের প্রতিক্রিয়া হিসাবে প্রসারিত বলে মনে হচ্ছে।
অ্যান্ডি

@ অ্যান্ডি: সত্য, তবে প্রতিটি বিকল্প রয়েছে। উদাহরণস্বরূপ, 202 আসলে অনুরোধটির প্রতিক্রিয়া হিসাবে বোঝানো হয়েছে যা প্রক্রিয়াকরণ শুরু করেছিল , যে অনুরোধটি প্রক্রিয়াজাতকরণের ফলাফলগুলির জন্য অনুরোধ করেছিল তা নয়। সত্যই, সর্বাধিক সুনির্দিষ্ট-সম্মতিযুক্ত প্রতিক্রিয়া হ'ল 404, যেহেতু সংস্থানটি পাওয়া যায় নি (কারণ এটি এখনও বিদ্যমান ছিল না)। 404 প্রতিক্রিয়াটির মধ্যে প্রাসঙ্গিক এপিআই ডেটা সরবরাহ থেকে API কে থামানোর কিছুই নেই। মনে মনে, 4xx / 5xx প্রতিক্রিয়াগুলি গ্রাস করতে বিরক্তিকর হতে থাকে; কিছু ভাষা কেবল একটি পৃথক স্থিতি কোড সরবরাহ করার চেয়ে একটি ব্যতিক্রমকে আগুন ধরিয়ে দেবে।
ব্রায়ান

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