REST এপিআই 404: খারাপ ইউআরআই, না কি রিসোর্স হারিয়েছে?


219

আমি একটি REST এপিআই তৈরি করছি তবে আমি একটি সমস্যার মুখোমুখি হয়েছি।

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

তবে আমার কাছে এটি অপ্রয়োজনীয় অস্পষ্টতা যুক্ত করে। HTTP 404 traditionতিহ্যগতভাবে খারাপ ইউআরআইয়ের সাথে যুক্ত। সুতরাং বাস্তবে আমরা বলছি "হয় আপনি সঠিক জায়গায় পৌঁছে গেছেন, তবে সেই নির্দিষ্ট রেকর্ডটির অস্তিত্ব নেই, বা ইন্টারনেটসের তেমন কোনও স্থান নেই! আমি সত্যিই নিশ্চিত নই যে কোনটি ..."

নিম্নলিখিত ইউআরআই বিবেচনা করুন:

http://mywebsite/api/user/13

যদি আমি একটি 404 ফিরে পাই তবে এটি কি কারণ 13 ব্যবহারকারীর অস্তিত্ব নেই? বা এটি কারণ যে আমার ইউআরএলটি হওয়া উচিত ছিল :

http://mywebsite/restapi/user/13

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



7
অন্য প্রশ্নটি ইউআরআই ক্যোয়ারী স্ট্রিং ফর্ম্যাটের সাথে সম্পর্কিত বলে মনে হচ্ছে। 404-তে আলোচনাটি আমার প্রশ্নের উত্তর দেওয়ার পক্ষে যথেষ্ট নয়, এটি হ'ল 404 আসলে কী বোঝায় তার পক্ষে আরও উপযুক্ত বা দরকারী উপায় আছে কিনা way আমি পোস্ট করার আগে একটি পর্যালোচনা।
ব্রায়ান লেসি

ব্রাউজারের কনকোলটিতে ত্রুটিগুলি 404 থাকে এমনটি কি স্বাভাবিক? আমি যখন সঠিক ইউরি দিয়ে নিয়মিত অপারেশন করি তবে রিসোর্স পাওয়া যায় না।
ভাসিলি মাজহেকিন

3
404 একটি খারাপ ইউআরআই নির্দেশ করে না, এটি খুঁজে পাওয়া যায় নি এমন একটি সংস্থান নির্দেশ করে। এটি কোনও ব্যবহারকারী '13' না থাকার কারণ হতে পারে, বা এটি কোনও সংস্থান / মাইওবসাইট / এপিআই না থাকার কারণ হতে পারে।
ChrisV

উত্তর:


101

404 হ'ল এইচটিটিপি রেসপন্স কোড। তার উপরে, আপনি একটি প্রতিক্রিয়া সংস্থা এবং / অথবা অন্যান্য শিরোনামগুলিকে আরও অর্থবহ ত্রুটি বার্তা সরবরাহ করতে পারেন যা বিকাশকারীরা দেখতে পাবেন।


7
এইবার বুঝতে পারছি. আমার ভাবতে হবে, তবে, প্রথমে 404 ফিরিয়ে নেওয়া কোনও শূন্য প্রতিক্রিয়া সহ 200 ফিরিয়ে দেওয়ার চেয়ে কোনও সুবিধা আসলেই পাওয়া যায় কিনা?
ব্রায়ান লেসি

15
যদি আপনি শূন্যের সাথে 200 ফিরিয়ে দেন তবে আপনি এইচটিটিপি স্পেকের বিরুদ্ধে যাচ্ছেন। আপনি এটি করতে পারেন, তবে তারপরে আপনার এপিআইইএসইএসটির "ইউনিফর্মড ইন্টারফেস" বাধাকে মেনে চলবে না।
মামলা দায়ের করুন

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

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

59

404যদি সংস্থানটি না থাকে তবে ব্যবহার করুন । 200খালি শরীর নিয়ে ফিরে যাবেন না ।

প্রোগ্রামিংয়ে এটি undefinedবনাম খালি স্ট্রিংয়ের (যেমন "") অনুরূপ । যদিও খুব অনুরূপ, অবশ্যই একটি পার্থক্য আছে।

404এর অর্থ এই যে ইউআরআই তে কিছুই বিদ্যমান নেই (প্রোগ্রামিংয়ে অনির্ধারিত ভেরিয়েবলের মতো)। 200খালি শরীর নিয়ে ফিরে আসার অর্থ হল যে এখানে কিছু আছে এবং এটি এখনই খালি (প্রোগ্রামিংয়ের ফাঁকা স্ট্রিংয়ের মতো)।

404এর অর্থ এই নয় যে এটি একটি "খারাপ ইউআরআই" ছিল। এখানে বিশেষ এইচটিটিপি কোড রয়েছে যা ইউআরআই ত্রুটির জন্য উদ্দিষ্ট (উদাঃ 414 Request-URI Too Long)।


1
আরে, আমি মনে করি আপনি কোনও কিছুর দিকে চলেছেন। "41" এর মধ্যে একটির কী ফিরে আসার বিষয়টি কি আরও বুদ্ধিমান হবে না? অনুরোধকৃত সংস্থানটিতে কোনও সমস্যা আছে কিনা? উদাহরণস্বরূপ, 410 গনের অর্থ "অনুরোধ করা সংস্থানটি সার্ভারে আর উপলব্ধ নেই এবং কোনও ফরোয়ার্ডিং ঠিকানা জানা যায় না।" - ( w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.11 দেখুন )
ব্রায়ান লেসি

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

2
আমি মনে করি না যে 41x ত্রুটিগুলির কোনওটিই আপনার ব্যবহারের ক্ষেত্রে উপযুক্ত। আমি অপরিবর্তিত বনাম খালি স্ট্রিংয়ের সাথে তুলনা করতে পছন্দ করি যা আমার উত্তরে আমার পয়েন্টটির আরও সংক্ষিপ্ত সংস্করণ। একটি পার্থক্য আছে, কিন্তু এর অর্থ এই নয় যে একটি খালি স্ট্রিং একটি ত্রুটি। উপমা প্রসারিত করতে: আপনি একটি পদ্ধতি হতে পারে String getName()ভালো একটি বাস্তবায়ন হয়েছে যে: return this.name == null ? "" : this.name। যদি না আপনি ক্লায়েন্ট জানাতে চাই যে, চান যে ভুল নয় this.nameহয় null
ঝাড়িক্স

1
404 এখনও সবচেয়ে উপযুক্ত বিকল্প। ত্রুটি পাওয়ার জন্য ব্যবহারকারী / ক্লায়েন্টকে নির্দিষ্ট বিশদ সম্পর্কে অবহিত করার জন্য আপনি 404 প্রতিক্রিয়াটির শরীরটি (এবং উত্সাহিত) করতে পারেন। দেখুন: স্ট্যাকওভারফ্লো . com / a / 9999335 / 105484 । আপনার ক্ষেত্রে আপনি সেই শরীরটি ব্যবহারকারীর কাছে পরামর্শ দেওয়ার জন্য ব্যবহার করতে পারেন যে তারা / ইউআরআই / রিস্টি / ইউএসআইআইডি-র মতো দেখতে তাদের ইউআরআই পুনরায় ফর্ম্যাট করে
সংক্ষিপ্ত বিবরণ

ঠিক আছে, আমি এখানে কিছু ভাল পয়েন্ট দেখতে পাচ্ছি, তবে 4XX হ'ল ত্রুটি কোড, এটি ত্রুটির পরিস্থিতি কেমন? ক্লায়েন্ট কীভাবে 404 কে ঘটতে বাধা দিতে পারে?
ক্রুজিসটফ কুবিকি

20

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

প্রথমত, ইউআরআই এর অস্বচ্ছ হওয়া উচিত। এমনকি যদি তারা মানুষের কাছে অস্বচ্ছ না হয় তবে তারা মেশিনগুলির কাছে অস্বচ্ছ। অন্য কথায়, এর মধ্যে পার্থক্য http://mywebsite/api/user/13, http://mywebsite/restapi/user/13এর মধ্যে পার্থক্য হিসাবে একই http://mywebsite/api/user/13এবং http://mywebsite/api/user/14একই একই পর্ব নয় না অর্থাৎ। সুতরাং একটি 404 সম্পূর্ণরূপে উপযুক্ত হবে http://mywebsite/api/user/14(যদি এমন কোনও ব্যবহারকারী না থাকে তবে) কেবলমাত্র যথাযথ প্রতিক্রিয়া নয়।

আপনি খালি 200 প্রতিক্রিয়া বা আরও স্পষ্টভাবে 204 (কোনও সামগ্রী নয়) প্রতিক্রিয়াও ফিরিয়ে দিতে পারেন। এটি ক্লায়েন্টকে অন্য কিছু জানাতে পারে। এটি সূচিত করবে যে দ্বারা চিহ্নিত সংস্থার http://mywebsite/api/user/14কোনও সামগ্রী নেই বা মূলত কিছুই নেই is মানে কী যে হয় এই ধরনের একটি সম্পদ। তবে এটির অগত্যা এটির অর্থ এই নয় যে আপনি দাবি করছেন যে কোনও ব্যবহারকারী আইডি 14 দিয়ে একটি ডেটা স্টোরটিতে জেদ রয়েছে That's এটি আপনার ব্যক্তিগত উদ্বেগ, অনুরোধটি করার ক্লায়েন্টের উদ্বেগ নয়। সুতরাং, যদি আপনার উত্সগুলিকে সেইভাবে মডেল করে তোলা বোঝায় তবে এগিয়ে যান।

আপনার ক্লায়েন্টদের তথ্য দেওয়ার ক্ষেত্রে কিছু সুরক্ষা জড়িত রয়েছে যা তাদের পক্ষে বৈধ ইউআরআই অনুমান করা সহজ করে তুলবে। 404 এর পরিবর্তে মিস করাতে 200 ফিরিয়ে দেওয়া ক্লায়েন্টকে একটি সূত্র দিতে পারে যা কমপক্ষে http://mywebsite/api/userঅংশটি সঠিক। একটি দূষিত ক্লায়েন্ট কেবল বিভিন্ন পূর্ণসংখ্যার চেষ্টা চালিয়ে যেতে পারে। তবে আমার কাছে, একটি দূষিত ক্লায়েন্ট http://mywebsite/api/userযেভাবেই অংশটি অনুমান করতে সক্ষম হবে । ইউআইডি'র ব্যবহার করা আরও ভাল প্রতিকার হবে। অর্থাত্ http://mywebsite/api/user/3dd5b770-79ea-11e1-b0c4-0800200c9a66তার চেয়ে ভাল http://mywebsite/api/user/14। এটি করে, আপনি 200 টাকা ফেরত দেওয়ার কৌশলটি বেশি দূরে না দিয়ে ব্যবহার করতে পারেন।


1
এটিই আমি সমাধানটি বেছে নিয়েছিলাম এবং 404 এর পরিবর্তে 204 ব্যবহার করে চলেছি me আমার কাছে 204 এর অর্থ "আমি আপনার কোড খুঁজে পেয়েছি, তবে ফলাফল খুঁজে পাইনি" এবং 404 এর অর্থ "আমি কার্যকর করার জন্য কোনও কোড খুঁজে পাইনি, এটিই কি?" ভুল পথ? "
ম্যাট স্যান্ডার্স

11

404 প্রযুক্তিগতভাবে পাওয়া যায় নি তার অর্থ ইউরি বর্তমানে কোনও সংস্থায় মানচিত্র করে না । আপনার উদাহরণে, আমি এই অনুরোধটির অর্থ ব্যাখ্যা করি http://mywebsite/api/user/13যে 404 ফেরত দেয় যাতে বোঝা যায় যে এই ইউআরএলটি কোনও উত্সে কখনই ম্যাপ করা হয়নি । ক্লায়েন্টের কাছে, কথোপকথনের শেষ হওয়া উচিত।

অস্পষ্টতার সাথে উদ্বেগগুলির সমাধান করার জন্য, আপনি অন্যান্য প্রতিক্রিয়া কোড সরবরাহ করে আপনার API উন্নত করতে পারেন। উদাহরণস্বরূপ, ধরুন আপনি ক্লায়েন্টদের জিইটি অনুরোধ করার অনুমতি দিতে চান ইউআরএল http://mywebsite/api/user/13, আপনি যোগাযোগ করতে চান যে ক্লায়েন্টদের ক্যানোনিকাল ইউআরএল ব্যবহার করা উচিত http://mywebsite/restapi/user/13। সেক্ষেত্রে আপনি 301 স্থায়ীভাবে স্থানান্তরিত করে স্থায়ী পুনঃনির্দেশ জারি করার বিষয়ে বিবেচনা করতে পারেন এবং প্রতিক্রিয়ার অবস্থান শিরোনামে ক্যানোনিকাল ইউআরএল সরবরাহ করতে পারেন । এটি ক্লায়েন্টকে বলে যে ভবিষ্যতের অনুরোধগুলির জন্য তাদের উচিত ক্যানোনিকাল ইউআরএল ব্যবহার করা উচিত।


10

সুতরাং সংক্ষেপে, মনে হচ্ছে উত্তরটি কীভাবে অনুরোধটি তৈরি হয় তার উপর নির্ভর করতে পারে।

যদি অনুরোধ করা সংস্থানটি ইউআরআই-র অংশ হিসাবে অনুরোধ করে http://mywebsite/restapi/user/13এবং ব্যবহারকারীর 13 উপস্থিত না থাকে তবে একটি 404 সম্ভবত উপযুক্ত এবং স্বজ্ঞাত কারণ ইউআরআই একটি অস্তিত্বহীন ব্যবহারকারী / সত্তা / নথি / ইত্যাদির প্রতিনিধি। এটি একইসাথে আরও একটি সুরক্ষিত কৌশলটি একটি http://mywebsite/api/user/3dd5b770-79ea-11e1-b0c4-0800200c9a66জিইউইউডি এবং উপরের এপিআই / রিসাপি যুক্তি ব্যবহার করে ।

তবে যদি অনুরোধ শিরোনামের মধ্যে অনুরোধ করা সংস্থান আইডি অন্তর্ভুক্ত করা হয় [আপনার নিজস্ব উদাহরণ অন্তর্ভুক্ত করুন], বা সত্যই, ইউআরআইতে প্যারামিটার হিসাবে, উদাহরণস্বরূপ http://mywebsite/restapi/user/?UID=13তবে ইউআরআই এখনও সঠিক হবে (কারণ কোনও ইউএসআই এর ধারণাটি এখানে উপস্থিত রয়েছে http://mywebsite/restapi/user/); এবং সেইজন্য প্রতিক্রিয়াটি 200 হিসাবে উপযুক্ত হিসাবে প্রত্যাশিত হতে পারে (যথাযথ ভার্বোস বার্তা সহ) কারণ 13 হিসাবে পরিচিত নির্দিষ্ট ব্যবহারকারীর অস্তিত্ব নেই তবে ইউআরআই রয়েছে। এইভাবে আমরা বলছি ইউআরআই ভাল, তবে ডেটার অনুরোধের কোনও বিষয়বস্তু নেই।

ব্যক্তিগতভাবে একটি 200 এখনও সঠিক বোধ করে না (যদিও আমি আগে এটি যুক্তি দিয়েছি)। উদাহরণস্বরূপ কোনও ভুল আইডি প্রেরণ করা হলে একটি 200 প্রতিক্রিয়া কোড (কোনও ভার্বোস প্রতিক্রিয়া ছাড়াই) কোনও সমস্যা তদন্ত না করার কারণ হতে পারে।

একটি আরও ভাল পদ্ধতির একটি 204 - No Contentপ্রতিক্রিয়া প্রেরণ করা হবে । এটি ডাব্লু 3 সি এর বর্ণনার সাথে সামঞ্জস্যপূর্ণ * সার্ভারটি অনুরোধটি পূরণ করেছে তবে কোনও সত্তা-দেহ ফেরত দেওয়ার দরকার নেই, এবং আপডেট মেন্টেরফর্মেশনটি ফিরে আসতে চাইবে * * 1 আমার মতে বিভ্রান্তিটি উইকিপিডিয়ায় প্রবেশের কারণে 204 লেখা নয় - সার্ভারটি সফলভাবে অনুরোধটি প্রক্রিয়া করেছে, কিন্তু কোনও সামগ্রী ফিরে দিচ্ছে না। সফলভাবে মুছে ফেলার অনুরোধের প্রতিক্রিয়া হিসাবে সাধারণত ব্যবহৃত হয়শেষ বাক্যটি অত্যন্ত বিতর্কিত। বাক্যটি ছাড়াই পরিস্থিতিটি বিবেচনা করুন এবং সমাধানটি সহজ - সত্তাটির অস্তিত্ব না থাকলে কেবল একটি 204 প্রেরণ করুন। 404 এর পরিবর্তে 204 ফিরিয়ে দেওয়ার পক্ষে যুক্তিও রয়েছে, অনুরোধটি প্রক্রিয়া করা হয়েছে এবং কোনও সামগ্রী ফেরত দেওয়া হয়নি! দয়া করে সচেতন থাকুন, 204 এর প্রতিক্রিয়া শৃঙ্খলে লিখিত সামগ্রী অনুমতি দেয় না

সোর্স

http://en.wikedia.org/wiki/List_of_HTTP_status_codes 1. http://www.w3.org/Potocols/rfc2616/rfc2616-sec10.html


9

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

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

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

যখন ক্লায়েন্টকে ফেরত পাঠানোর কোনও ডেটা ছিল না তখন আমি ক্লায়েন্টকে "পাওয়া যায়নি" এর কারণ সম্পর্কে অবহিত করার জন্য অভ্যন্তরীণ ত্রুটি কোড ইত্যাদির সাথে একটি নিখুঁত জেএসওএন বার্তা প্রস্তুত করেছি এবং এটি HTTP 404 সহ ক্লায়েন্টকে ফেরত পাঠানো হয়েছিল That ঠিকভাবে কাজ করে.

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

তবে আমার এই বিভ্রান্তিকর অতিরিক্ত কোডটি লেখার দরকার ছিল কারণ এইচটিটিপি 404 এর দুটি আলাদা ফাংশন ছিল:

  • প্রকৃত এইচটিটিপি 404 যখন বাকী এপিআই প্রদত্ত ইউআরএলে উপলব্ধ না হয়, তখন এটি অ্যাপ্লিকেশন সার্ভার বা ওয়েব-সার্ভার দ্বারা ফেলে দেওয়া হয় যেখানে বাকী এপিআই অ্যাপ্লিকেশন চালিত হয়
  • ক্লায়েন্ট এইচটিটিপি 404 ফেরত পাবেন যখন কোয়েরির শর্তের ভিত্তিতে ডাটাবেসে কোনও ডেটা নেই।

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

এটি আমার ক্লায়েন্ট সহায়ক পদ্ধতির 1 ম সংস্করণ যা দুটি পৃথক HTTP 404 প্রতিক্রিয়া পরিচালনা করে:

public static String getSomething(final String uuid) {
    String serviceUrl = getServiceUrl();
    String path = "user/" + , uuid);
    String requestUrl = serviceUrl + path;
    String httpMethod = "GET";

    Response response = client
            .target(serviceUrl)
            .path(path)
            .request(ExtendedMediaType.APPLICATION_UTF8)
            .get();

    if (response.getStatus() == Response.Status.OK.getStatusCode()) {
        // HTTP 200
        return response.readEntity(String.class);
    } else {
        // confusing code comes here just because
        // I need to decide the type of HTTP 404...

        // trying to parse response body
        try {
            String responseBody = response.readEntity(String.class);
            ObjectMapper mapper = new ObjectMapper();
            ErrorInfo errorInfo = mapper.readValue(responseBody, ErrorInfo.class);

            // re-throw the original exception
            throw new MyException(errorInfo);

        } catch (IOException e) {
            // this is a real HTTP 404
            throw new ServiceUnavailableError(response, requestUrl, httpMethod);
        }

    // this exception will never be thrown
    throw new Exception("UNEXPECTED ERRORS, BETTER IF YOU DO NOT SEE IT IN THE LOG");
}

কিন্তু , কারণ আমার জাভা বা জাভাস্ক্রিপ্ট ক্লায়েন্ট দুটি প্রকারের HTTP 404 পেতে পারে কোনওরকমভাবে HTTP 404 এর ক্ষেত্রে আমাকে প্রতিক্রিয়ার শরীরটি পরীক্ষা করতে হবে I আমি যদি প্রতিক্রিয়ার বডিটি পার্স করতে পারি তবে আমি নিশ্চিত যে যেখানে ছিল সেখানে আমি একটি প্রতিক্রিয়া ফিরে পেয়েছি ক্লায়েন্টকে ফেরত পাঠানোর জন্য কোনও ডেটা নেই।

আমি যদি প্রতিক্রিয়াটি পার্স করতে সক্ষম না হয়েছি তার অর্থ আমি ওয়েব সার্ভার (বাকি এপিআই অ্যাপ্লিকেশন থেকে নয়) থেকে একটি আসল এইচটিটিপি 404 ফিরে পেয়েছি।

এটি এত বিভ্রান্তিকর এবং ক্লায়েন্ট অ্যাপ্লিকেশনটির সবসময় HTTP 404 এর আসল কারণ যাচাই করতে অতিরিক্ত পার্সিং করা প্রয়োজন needs

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

সুতরাং এই দুটি পৃথক পরিস্থিতিতে HTTP 404 ব্যবহার করার পরিবর্তে আমি সিদ্ধান্ত নিয়েছি যে আমি নিম্নলিখিতগুলি করব:

  • আমি আমার বিশ্রামের অ্যাপ্লিকেশনটিতে আর HTTP 404 প্রতিক্রিয়া হিসাবে HTTP কোড ব্যবহার করছি না।
  • আমি HTTP 404 এর পরিবর্তে HTTP 204 (কোনও সামগ্রী নেই) ব্যবহার করতে যাচ্ছি।

সেক্ষেত্রে ক্লায়েন্ট কোডটি আরও মার্জিত হতে পারে:

public static String getString(final String processId, final String key) {
    String serviceUrl = getServiceUrl();
    String path = String.format("key/%s", key);
    String requestUrl = serviceUrl + path;
    String httpMethod = "GET";

    log(requestUrl);

    Response response = client
            .target(serviceUrl)
            .path(path)
            .request(ExtendedMediaType.APPLICATION_JSON_UTF8)
            .header(CustomHttpHeader.PROCESS_ID, processId)
            .get();

    if (response.getStatus() == Response.Status.OK.getStatusCode()) {
        return response.readEntity(String.class);
    } else {
        String body = response.readEntity(String.class);
        ObjectMapper mapper = new ObjectMapper();
        ErrorInfo errorInfo = mapper.readValue(body, ErrorInfo.class);
        throw new MyException(errorInfo);
    }

    throw new AnyServerError(response, requestUrl, httpMethod);
}

আমি মনে করি এটি এই সমস্যাটিকে আরও ভালভাবে পরিচালনা করে।

আপনার যদি আরও ভাল সমাধান থাকে তবে তা আমাদের সাথে শেয়ার করুন।


অ্যাপাচি এইচটিটিপি ক্লায়েন্ট পদ্ধতিগুলি 204 প্রতিক্রিয়া ব্যতিক্রম করে না। যদি আপনার ক্লায়েন্ট কেবল ব্যবসায়ের জিনিসগুলিকে (মডেল) উত্তর দেয় তবে তা বাতিল হয়ে যাবে। কাজ করে, তবে শেষ ব্যবহারকারীদের জন্য ২০৪ পরিস্থিতি সনাক্ত করা কঠিন।
ক্রিসিনমটাউন

এটি সব ভাল, তবে একটি প্রশ্ন: 404 এর পক্ষে বিবৃতি দেওয়া হলে আপনি কতবার লিখবেন? এবং এটা কি হবে? অন্যদিকে, আপনি যদি এপিআইকে কল করেন, যা ভিতরে ত্রুটি জেসন দিয়ে 404 সম্ভাব্যভাবে সংজ্ঞায়িত করে, আপনি কেবল এই ক্ষেত্রে এটি পরিচালনা করতে পারেন।
সর্বাধিক

zappee আমি আপনার সাথে একমত। আমার একটি পরিষেবা রয়েছে যা ডেটা ফেরত দেয়। কিন্তু এমন পরিস্থিতি রয়েছে যেখানে ডেটা নষ্ট হয়ে যায়। অনুরোধ URL টি সঠিক (সুতরাং 404 নয়) তবে এটি আসলে কোনও যুক্তি ত্রুটি নয় (500), সুতরাং 204 সবচেয়ে উপযুক্ত বলে মনে হচ্ছে। কোনও বার্তা দেহের জিনিস না থাকা নিয়ে এটি সত্যিই বিরক্তিকর। যদিও যুক্তিযুক্তভাবে আমি একটি শিরোলেখার মধ্যে একটি কারণ sertোকাতে পারি।
cs94njw

6

এই পুরানো তবে দুর্দান্ত নিবন্ধটি ... http://www.infoq.com/articles/webber-rest-work প্রবাহটি এ সম্পর্কে বলেছে ...

404 পাওয়া যায় নি - আমাদের অনুরোধটি ব্যর্থ হবার একটি সত্য কারণ আমাদের দিতে পরিষেবাটি খুব অলস (বা সুরক্ষিত), তবে কারণ যাই হোক না কেন, আমাদের এটি মোকাবেলা করতে হবে to


1

ইউনিফর্ম রিসোর্স আইডেন্টিফায়ার হ'ল সংস্থানটির এক অনন্য পয়েন্টার। দুর্বল ফর্মের ইউআরআই রিসোর্সের দিকে ইঙ্গিত করে না এবং তাই এটিতে একটি জিইটি করানো কোনও সংস্থান ফিরে পাবে না। 404 এর অর্থ সার্ভারটি অনুরোধ-ইউআরআইয়ের সাথে মিলে এমন কিছু খুঁজে পায়নি। আপনি যদি ভুল ইউআরআই বা খারাপ ইউআরআই রাখেন তবে এটি আপনার সমস্যা এবং কারণটি কোনও HTML পৃষ্ঠা বা আইএমজি কিনা কোনও উত্সে পৌঁছায় না।


0

এই দৃশ্যের জন্য এইচটিটিপি 404 হ'ল 400, 401, 404, 422 অ্যাক্রোসেসেবল সত্তার মতোই REST এপিআইয়ের প্রতিক্রিয়ার কোড

সম্পূর্ণ ব্যতিক্রম বার্তাটি পরীক্ষা করতে ব্যতিক্রম হ্যান্ডলিংটি ব্যবহার করুন।

try{
  // call the rest api
} catch(RestClientException e) {
     //process exception
     if(e instanceof HttpStatusCodeException){
        String responseText=((HttpStatusCodeException)e).getResponseBodyAsString();
         //now you have the response, construct json from it, and extract the errors
         System.out.println("Exception :" +responseText);
     }

}

এই ব্যতিক্রম ব্লকটি আপনাকে REST API দ্বারা নিক্ষেপ করা যথাযথ বার্তা দেয়

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