ক্রিয়াপদ ছাড়াই কীভাবে আরএসটি ইউআরএল তৈরি করবেন?


283

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

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

  1. নতুন প্যারামিটারগুলি আপলোড করুন
  2. সর্বশেষতম পরামিতি পান
  3. প্রদত্ত ব্যবসায়ের তারিখের জন্য প্যারামিটার পান
  4. প্যারামিটারগুলির একটি সেট সক্রিয় করুন
  5. পরামিতিগুলির একটি সেট বৈধ করুন

আমি সংগ্রহ করেছি বিশ্রামের পদ্ধতির জন্য নিম্নলিখিত ধরণের ইউআরএল থাকবে:

/parameters
/parameters/12-23-2009

আপনি প্রথম তিনটি ব্যবহারের ক্ষেত্রে এটি অর্জন করতে পারেন:

  1. পোস্টের অনুরোধে আপনি যেখানে প্যারামিটার ফাইলটি অন্তর্ভুক্ত করুন সেখানে পোস্ট করুন
  2. প্রথম ইউআরএল পেতে
  3. দ্বিতীয় ইউআরএল পেতে

তবে আপনি কীভাবে একটি ক্রিয়া ছাড়াই চতুর্থ এবং 5 তম ব্যবহারের ক্ষেত্রে করবেন? আপনার কি ইউআরএলগুলির দরকার নেই:

/parameters/ID/activate
/parameters/ID/validate

??


3
আমি আংশিক আপডেটের জন্য পোস্টের চেয়ে প্যাচ পছন্দ করি।
ব্যবহারকারী2016971

উত্তর:


71

সম্ভবত এর মতো কিছু:

PUT /parameters/activation HTTP/1.1
Content-Type: application/json; encoding=UTF-8
Content-Length: 18

{ "active": true }

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

19
পুট একটি নতুন সংস্থান তৈরি করার জন্য, বা নির্দিষ্ট URL এ একটি নতুন সংস্থান স্থাপনের জন্য (পুরো অংশে নয়, অংশে নয়) for আমি দেখছি না কীভাবে পিটি এই ক্ষেত্রে ফিট করে।
ব্রেটন

30
আসলে, POSTবনাম PUTঠিক insertবনাম এর মতো নয় updatePUTপ্রদত্ত পথের সাথে সম্পর্কিত সংস্থানটিকে আপডেট করে বা প্রদত্ত পথের সাথে সম্পর্কিত একটি নতুন সংস্থান তৈরি করে। POSTকোথাও একটি নতুন সংস্থান তৈরি করে। উদাহরণস্বরূপ, PUT /blog/posts/3/comments/5উপযুক্ত মন্তব্য আপডেট করবে, যখন POST /blog/posts/3/commentsএকটি নতুন commentসংস্থান তৈরি করবে (এবং প্রতিক্রিয়াতে নতুন উত্সের পথে ফিরে আসা উচিত)।
yfeldblum

23
@Justice @Breton দ্য বেশি গুরুত্বপূর্ণ পার্থক্য হল PUTidempotent যখন POSTনয়। সাধারণত আপনি যতটা সম্ভব ফলাফল হিসাবে সরবরাহ করেন তাতে আপনার যতটা বাধা দেওয়া উচিত। সাথে স্টিক করা PUTপরিষেবাটির ক্লায়েন্টকে আরও তথ্য দেয়।
আন্দ্রে ভ্লাসোভস্কিখ

3
সংস্থানটি / পরামিতি / স্থিতিও থাকতে পারে এবং অনুরোধটির মূল অংশটি কেবল "সক্রিয়" থাকতে পারত। এইভাবে আপনি কোনও নির্দিষ্ট URL এ পুরোপুরি নতুন সংস্থান স্থাপন করছেন।
কার্লোস আগুয়াও

991

ভাল ইউআরআই ডিজাইনের জন্য সাধারণ নীতিগুলি:

  • অবস্থা পরিবর্তন করতে কোয়েরি প্যারামিটার ব্যবহার করবেন না
  • আপনি যদি সহায়তা করতে পারেন তবে মিক্সড-কেস পাথ ব্যবহার করবেন না ; ছোট হাতের বাচ্চা ভাল
  • আপনার ইউআরআইগুলিতে প্রয়োগকরণ-নির্দিষ্ট এক্সটেনশনগুলি ব্যবহার করবেন না (। Php, .py, .pl, ইত্যাদি)
  • না পড়া আরপিসি আপনার URI উল্লিখিত সঙ্গে
  • না যতটা সম্ভব আপনার কোনো URI স্থান সীমিত
  • দো রাখা পাথ অংশ সংক্ষিপ্ত
  • দো পারেন পছন্দ করা /resourceবা /resource/; আপনি যেটি ব্যবহার করবেন না তার থেকে 301 পুনর্নির্দেশগুলি তৈরি করুন
  • কোনও উত্সের উপ-নির্বাচনের জন্য কোয়েরি পরামিতিগুলি ব্যবহার করবেন না ; উদাহরণস্বরূপ, পৃষ্ঠা অনুসন্ধান, অনুসন্ধান অনুসন্ধানসমূহ
  • কি পদক্ষেপ কাপড় কোনো URI এর বাইরে যে HTTP শিরোলেখ বা শরীরে হওয়া উচিত

(দ্রষ্টব্য: আমি "রেস্টস্টুল ইউআরআই ডিজাইন" বলিনি; ইউআরআইগুলি অবশ্যই আরএসটি-তে অস্বচ্ছ।

HTTP পদ্ধতি পছন্দের জন্য সাধারণ নীতিগুলি:

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

HTTP সহ ওয়েব পরিষেবা ডিজাইনের সাধারণ নীতিগুলি:

  • না একটি প্রতিক্রিয়া শরীরের যে একটি হেডারের মধ্যে হওয়া উচিত মেটাডেটা করা
  • না আলাদা সম্পদ মেটাডেটা করা যদি না সহ এটা উল্লেখযোগ্য ওভারহেড তৈরি করবে
  • না উপযুক্ত অবস্থা কোড ব্যবহার
    • 201 Createdএকটি উত্স তৈরি করার পরে; প্রতিক্রিয়া প্রেরণের সময় সংস্থান থাকা আবশ্যক
    • 202 Accepted সফলভাবে কোনও ক্রিয়া সম্পাদন করার পরে বা অ্যাসিঙ্ক্রোনালি একটি সংস্থান তৈরি করার পরে
    • 400 Bad Requestযখন কেউ ডেটাতে কোনও অপারেশন করে যা স্পষ্টভাবে বোগাস; আপনার অ্যাপ্লিকেশন জন্য এটি একটি বৈধতা ত্রুটি হতে পারে; অপ্রকাশিত ব্যতিক্রমগুলির জন্য সাধারণত 500 রিজার্ভ করুন
    • 401 Unauthorizedযখন কেউ প্রয়োজনীয় Authorizationহেডার সরবরাহ না করেই আপনার এপিআই অ্যাক্সেস করে বা যখন শংসাপত্রগুলি Authorizationঅবৈধ হয়; আপনি যদি কোনও Authorizationশিরোনামের মাধ্যমে শংসাপত্রের প্রত্যাশা না করেন তবে এই প্রতিক্রিয়া কোডটি ব্যবহার করবেন না ।
    • 403 Forbidden যখন কেউ আপনার এপিআইতে এমনভাবে প্রবেশ করে যা দূষিত হতে পারে বা তারা অনুমোদিত না হয়
    • 405 Method Not Allowed যখন কেউ POST ব্যবহার করে যখন তাদের পুট ইত্যাদি ব্যবহার করা উচিত
    • 413 Request Entity Too Large যখন কেউ আপনাকে অগ্রহণযোগ্য বড় ফাইল প্রেরণের চেষ্টা করে
    • 418 I'm a teapot যখন একটি টিপোট দিয়ে কফি তৈরি করার চেষ্টা করা হয়
  • কি ক্যাশে হেডার ব্যবহার যখনই আপনি করতে পারেন
    • ETag আপনি যখন কোনও হ্যাশ মানকে সহজেই কোনও সংস্থান কমাতে পারেন তখন শিরোনামগুলি ভাল
    • Last-Modified আপনাকে নির্দেশ করতে হবে যে যখন সংস্থানগুলি আপডেট করা হয় তখন একটি টাইমস্ট্যাম্পের কাছাকাছি রাখা ভাল ধারণা
    • Cache-Controlএবং Expiresবোধগম্য মান দেওয়া উচিত
  • কি একটি অনুরোধ মধ্যে হেডার ক্যাশে সম্মান সবকিছু আপনি যা করতে পারেন ( If-None-Modified, If-Modified-Since)
  • পুনর্নির্দেশগুলি যখন বোধগম্য হয় তখন সেগুলি ব্যবহার করবেন না তবে ওয়েব পরিষেবাদির জন্য এগুলি বিরল হওয়া উচিত

আপনার নির্দিষ্ট প্রশ্নের সাথে সম্পর্কিত, পোষ্টটি # 4 এবং # 5 এর জন্য ব্যবহার করা উচিত। এই অপারেশনগুলি উপরের "আরপিসির মতো" নির্দেশিকার আওতায় পড়ে। # 5 এর জন্য, মনে রাখবেন যে পোষ্ট ব্যবহার করার প্রয়োজন হয় না Content-Type: application/x-www-form-urlencoded। এটি ঠিক তত সহজেই কোনও জেএসএন বা সিএসভি পে-লোড হতে পারে।


11
আপনাকে যে অনুরোধ প্রেরণ করা হচ্ছে তার আকারের জন্য 413 র উদ্দেশ্যে করা হয়েছে যাতে আপনি 411 এর সাথে একত্রে আপনাকে ডেটা জিগ প্রেরণকারী কাউকে বিনয়ের সাথে প্রত্যাখ্যান করতে পারেন যাতে আপনি লোকেরা আপনাকে কতটা প্রেরণ করা হচ্ছে তা বলতে বাধ্য করেন। ৪১৩ এর বিপরীতে দেওয়া উদাহরণের জন্য, আমি মনে করি 400 এর বেশি উপযুক্ত প্রতিক্রিয়া হবে।
গ্যারি শাটলার

5
+1 যেহেতু এটি একটি দুর্দান্ত সংস্থান। যাইহোক, এটি একটি সাধারণ সংস্থান এবং সরাসরি প্রশ্নটির উত্তর ও উত্তর দেয় না। এই আদর্শভাবে একটি নির্দিষ্ট উত্তর সহ একটি অতিরিক্ত অনুচ্ছেদ অন্তর্ভুক্ত করা উচিত।
স্যামুয়েল নেফ

@ গ্যারিশুটলার ভাল ধরা, আপনি একেবারে ঠিক আছে। সম্পাদনার জন্য ধন্যবাদ।
বব আমান

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

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

18

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

তবে আপনি যা লিখেছেন তা থেকে আমি বলব আপনার অ্যাপ্লিকেশনটিতে আরও অনেক বড় সমস্যা রয়েছে।

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

একটি 'পরামিতি' ঠিক কী উপস্থাপন করে? সম্ভবত বেশ কয়েকটি বিভিন্ন জিনিস, যার প্রত্যেকটির আলাদা আলাদা উত্স উত্সর্গ করা উচিত।

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

আপনার অ্যাপ্লিকেশনটি আপনার চারপাশে নকশা করা উচিত Those

আপনার যদি এখনও সম্ভাব্য ব্যবহারকারীদের সাথে এই রূপান্তর না ঘটে থাকে - এখনই সবকিছু বন্ধ করুন এবং আপনি না করা পর্যন্ত কোডের অন্য লাইনটি লিখবেন না! তবেই আপনার দলের কী তৈরি করা দরকার তা সম্পর্কে ধারণা পাবেন will

আমি আর্থিক সফ্টওয়্যার সম্পর্কে কিছুই জানি না, তবে যদি আমার অনুমান করতে হয় তবে আমি বলতাম যে কিছু সংস্থানগুলি "প্রতিবেদন", "অর্থ প্রদান", "স্থানান্তর" এবং "মুদ্রা" এর মতো নামে যেতে পারে।

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


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

1
মাঝে মাঝে শব্দগুলিকে "অ্যাক্টিভেটর" বা "বৈধকারক" এর মতো "প্রসেসিং রিসোর্সে" রূপান্তর করা দরকারী বলে মনে করি। আরএফসি অনুযায়ী 2616 পোস্টটি "ডেটা হ্যান্ডলিংয়ের প্রক্রিয়াতে ... একটি ব্লক ডেটা সরবরাহ করতে" ব্যবহার করা যেতে পারে
ড্যারেল মিলার

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

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

1
"আপনি যখন নিজের অ্যাপ্লিকেশনটি শেষ ব্যবহারকারীদের সাথে আলোচনা করেন তখন তারা নিজেরাই বারবার কী শব্দ ব্যবহার করেন?" ... এবং যদি তারা সমস্ত ক্রিয়া হয়? এক্সডি
অমলগোভিনাস

11

আপনার ইউআরএলগুলির ডিজাইনের সাথে আপনার অ্যাপ্লিকেশনটি বিশ্রামযুক্ত কিনা তা নিয়ে কিছুই করার নেই। "RESTful URL গুলি" শব্দগুচ্ছটি তাই বাজে কথা।

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

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

হার্মাম নাও হতে পারে।

এখানে ধারণাটি হ'ল আপনাকে সমস্ত কিছুকে একটি উত্স হিসাবে বিবেচনা করতে হবে, তাই একবারে কোনও পরামিতিগুলির সেটগুলির একটি URL থাকলে আপনি এটিকে উল্লেখ করতে পারেন, আপনি কেবল যুক্ত করুন:

GET [parametersurl]/validationresults

POST [paramatersurl]
body: {command:"activate"}

তবে আবার, সেই অ্যাক্টিভেট জিনিসটি আরপিসি, আরএসটি নয়।


আপনি এখানে একটি আকর্ষণীয় পয়েন্ট বর্ণনা। আপনি কি আরও কিছুটা বিশদভাবে বলতে পারেন যে এর মতো কোনও কিছুর জন্য রেস্টস্টুল অ্যাপ্রোচ কেমন হবে?
poezn

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

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

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

@ ড্যারেল, আমি মনে করি আপনি আরইএসইএসটির একটি অংশ চিহ্নিত করেছেন যা বিশ্রামে নতুন যারা অনেকের পক্ষে চ্যালেঞ্জ হতে পারে। আপনি কীভাবে "বৈধতা উত্স এক্স" অপারেশন বাস্তবায়ন করতে পারেন? আমি মনে করি যে চ্যালেঞ্জিং জিনিসটি হ'ল এটি একটি অপারেশন যার ফলে রাষ্ট্রের পরিবর্তন হতে পারে তবে নতুন রাষ্ট্রটি অনুরোধের ফলাফল is
শান

6

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

যেমন কিছু সংস্থান তৈরি করুন যেমন,

/ActiveParameters
/ValidatedParameters

আপনি যদি প্যারামিটারগুলির একটি সেট সক্রিয় করতে চান, তবে সেই সেটটি অ্যাক্টিভ প্যারামিটার সংগ্রহের সাথে যুক্ত করুন। আপনি হয় কোনও সত্তা সংস্থা হিসাবে পরামিতিগুলির সেটটি পাস করতে পারেন, বা আপনি কোয়েরি প্যারামিটার হিসাবে একটি ইউআরএল পাস করতে পারেন:

POST /ActiveParameters?parameter=/Parameters/{Id}

একই জিনিসটি / বৈধতাযুক্ত প্যারামিটারগুলি দিয়ে করা যায়। যদি প্যারামিটারগুলি বৈধ না থাকে তবে সার্ভার বৈধতাযুক্ত পরামিতিগুলি সংগ্রহের ক্ষেত্রে প্যারামিটারগুলি যুক্ত করার অনুরোধটিতে "খারাপ অনুরোধ" ফিরিয়ে দিতে পারে।


1

আমি নিম্নলিখিত মেটা রিসোর্স এবং পদ্ধতিগুলির পরামর্শ দেব।

প্যারামিটারগুলি সক্রিয় করুন এবং / অথবা এগুলিকে বৈধ করুন:

> PUT /parameters/<id>/meta HTTP/1.1
> Host: example.com
> Content-Type: application/json
> Connection: close
>
> {'active': true, 'require-valid': true}
>
< HTTP/1.1 200 OK
< Connection: close
<

প্যারামিটারগুলি সক্রিয় এবং বৈধ কিনা তা পরীক্ষা করুন:

> GET /parameters/<id>/meta HTTP/1.1
> Host: example.com
> Connection: close
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Connection: close
<
< {
<     'active': true,
<     'require-valid': true,
<     'valid': {'status': false, 'reason': '...'}
< }
<

আমি যতদূর বুঝতে পেরেছি, প্রশ্নটি বাকী ইউআরএলগুলির নামকরণ সম্পর্কে, কার্যকারিতা সম্পর্কে নয়, তাই না?
poezn

2
"RESTful URL গুলি" এ সীমাবদ্ধ একটি প্রশ্ন একটি খারাপ প্রশ্ন এবং এর উত্তর দেওয়া উচিত নয়। পরিবর্তে "সম্পর্কিত পদ্ধতি এবং ইউআরএলগুলির সাথে বিশ্রামদানকারী সংস্থানসমূহ" বিবেচনা করার জন্য প্রশ্নটি প্রসারিত করা উচিত - এবং এর উত্তর দেওয়া হয়েছে।
yfeldblum

যেহেতু আমি এটি বুঝতে পেরেছি, প্রশ্নটি ছিল URL নামকরণের কনভেনশনগুলি এবং এইচটিটিপি পদ্ধতিতে নামকরণকৃত উত্সটির প্রতিক্রিয়া জানানো উচিত।
আন্দ্রে ভ্লাসাভস্কিখ 21

1

আমি কিছুটা দু: খিত দেখতে পেয়েছি যে 10 বছরেরও বেশি সময় পরেও সত্যই কোনও উত্তর নেই যা ওপিতে অনুরোধ করা হয়েছে এমন একটি জিনিস কীভাবে একটি আর্কিটেকচারে নকশা করা যেতে পারে, তাই এখনই এটি করার প্রয়োজন বোধ করছি।

প্রথম জিনিস, প্রথমে রেস্ট কি ?! সংক্ষিপ্ত আরইএসটি বা আরইএসটি "প্রতিনিধিত্বমূলক রাজ্য স্থানান্তর" এর অর্থ দাঁড়ায় এবং একটি নির্দিষ্ট উপস্থাপনা বিন্যাসে একটি সংস্থার রাষ্ট্রের বিনিময়কে সংজ্ঞায়িত করে। উপস্থাপনা ফর্ম্যাট আলোচনামূলক মিডিয়া টাইপের জোয়ার। application/htmlউপস্থাপনা বিন্যাসের ক্ষেত্রে ব্রাউজারে রেন্ডার করা এইচটিএমএল ফর্ম্যাটযুক্ত পাঠ্য সামগ্রীর একটি স্ট্রিম হতে পারে, সম্ভবত কিছু নির্দিষ্ট স্থানে নির্দিষ্ট উপাদানগুলিতে কিছু স্টাইলশিট বিন্যাস প্রয়োগ করার পরে।

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

একটি ওয়েব ভিত্তিক ক্যালকুলেটর সাধারণত কিছু "পৃষ্ঠা" দিয়ে শুরু করতে পারে যা আপনাকে সার্ভারে প্রবেশ করা ডেটা প্রেরণের আগে গণনা করতে কিছু মানকে ইনপুট করতে দেয়। এইচটিএমএল এ সাধারণত এইচটিএমএল <form>উপাদানগুলির মাধ্যমে অর্জন করা হয় যা কোনও ক্লায়েন্টকে সেট করতে উপলব্ধ প্যারামিটারে শিখিয়ে দেয়, অনুরোধটি প্রেরণের লক্ষ্যের পাশাপাশি ইনপুট ডেটা প্রেরণের জন্য উপস্থাপনের ফর্ম্যাটটি প্রেরণ করে। এটি যেমন দেখতে পারে:

<html>
  <head>
    ...
  </head>
  <body>
    <form action="/../someResource" method="post" enctype="application/x-www-form-urlencoded">
      <label for="firstNumber">First number:</label>
      <input type="number" id="firstNumber" name="firstNumber"/>

      <label for="secondNumber">Second number:</label>
      <input type="number" id="secondNumber" name="secondNumber"/>

      <input type="submit" value="Add numbers"/>
    </form>
  </body>
</html>

উপরের নমুনাটিতে বলা হয়েছে যে এখানে দুটি ইনপুট ক্ষেত্র রয়েছে যা ব্যবহারকারী বা অন্য কোনও অটোমেটা দ্বারা পূরণ করা যেতে পারে, এবং যে ইনপুট উপাদানটি জমা দেওয়ার পরে ব্রাউজারটি ইনপুট ডেটা application/x-www-form-urlencodedউপস্থাপনের ফর্ম্যাটে প্রেরণ করে যা প্রেরণ করা হয় POSTএই ক্ষেত্রে নির্দিষ্ট HTTP অনুরোধ পদ্ধতির মাধ্যমে উল্লিখিত লক্ষ্য স্থানে location আমরা যদি লিখুন 1মধ্যে firstNumberইনপুট ক্ষেত্র এবং 2মধ্যে secondNumberইনপুট ক্ষেত্র, ব্রাউজার একটি প্রতিনিধিত্ব উত্পন্ন করবে firstNumber=1&secondNumber=2এবং টার্গেট রিসোর্স প্রকৃত অনুরোধের শরীর পে লোড হিসাবে এই পাঠান।

সার্ভারে ইস্যু করা কাঁচা এইচটিটিপি অনুরোধটি দেখতে এরকম দেখতে পারে:

POST /../someResource
Host: www.acme.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
Accept: application/html

firstNumber=1&secondNumber=2

সার্ভারটি গণনা সম্পাদন করতে পারে এবং আরও এইচটিএমএল পৃষ্ঠায় প্রতিক্রিয়া জানাতে পারে যা গণনার ফলাফল ধারণ করে, যেমন অনুরোধটি ইঙ্গিত দেয় যে ক্লায়েন্টটি এই ফর্ম্যাটটি বোঝে।

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

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

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

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

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

জিজ্ঞাসিত প্রকৃত প্রশ্নের ক্ষেত্রে, সিএসভি ফাইল হিসাবে ডেটা প্রেরণ application/x-www-form-urlencodedপ্রতিনিধিত্ব বা অনুরূপ স্টাফ ব্যবহারের চেয়ে আলাদা কিছু নয় । জিম ওয়েবার পরিষ্কার করে দিয়েছিলেন যে সমস্ত এইচটিটিপি হ'ল কেবল একটি ট্রান্সপোর্ট প্রোটোকল যার অ্যাপ্লিকেশন ডোমেনটি ওয়েবে নথির স্থানান্তরআরএফসি 7111text/csv হিসাবে সংজ্ঞায়িত হিসাবে ক্লায়েন্ট এবং সার্ভারের কমপক্ষে উভয় সমর্থন করা উচিত । কনফিগারেশনের আপলোড সম্পাদনের জন্য এইচটিটিপি পদ্ধতিতে অনুরোধ প্রেরণের জন্য ফর্ম উপাদান, একটি লক্ষ্য উপাদান বা বৈশিষ্ট্য হিসাবে সংশ্লেষ করে এমন একটি মিডিয়া টাইপ প্রক্রিয়াকরণের ফলাফল হিসাবে এই সিএসভি ফাইলটি উত্পন্ন হতে পারে।

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

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

নির্দিষ্ট কনফিগারেশন প্যারামিটারগুলি সক্রিয় বা নিষ্ক্রিয় করা কেবল হাইপারমিডিয়া নিয়ন্ত্রণগুলি চালিত করে যা এই সামর্থ্য সরবরাহ করে। এইচটিএমএল ফর্মগুলিতে এটি একটি সাধারণ চেকবক্স বা কোনও তালিকার বা kind ধরণের একাধিক-লাইন নির্বাচন হতে পারে। ফর্ম এবং এটি কোন পদ্ধতির দ্বারা এটি সংজ্ঞায়িত করে তার উপর নির্ভর করে সম্পূর্ণরূপে কনফিগারেশনটি প্রেরণ করতে PUTপারে বা পরিবর্তিত পরিবর্তনগুলি সম্পর্কে স্মার্ট হতে পারে এবং কেবল এর মাধ্যমে একটি আংশিক আপডেট সম্পাদন করতে পারে PATCH। পরবর্তীটির জন্য মূলত আপডেট হওয়াতে পরিবর্তনের প্রতিনিধিত্বের একটি ক্যালকুলটন প্রয়োজন এবং বর্তমান উপস্থাপনাটিকে কাঙ্ক্ষিতভাবে ট্রান্সফর্ম করার জন্য প্রয়োজনীয় পদক্ষেপগুলি সহ সার্ভারকে ফিড দিন। PATH স্পেসিফিকেশন অনুসারে এটি একটি লেনদেনের মধ্যেই সম্পন্ন করতে হবে যাতে পদক্ষেপগুলির সমস্ত বা কোনওটিই প্রয়োগ না হয়।

এইচটিটিপি পরিবর্তনগুলি প্রয়োগ করার আগে একটি সার্ভারকে একটি প্রাপ্ত অনুরোধকে বৈধতা দেওয়ার জন্য অনুমতি দেয় এবং উত্সাহ দেয়। পুটটি পুট করার জন্য :

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

উদাহরণস্বরূপ, যদি লক্ষ্য উত্সটি সর্বদা "পাঠ্য / এইচটিএমএল" এর সামগ্রী-প্রকারের জন্য কনফিগার করা থাকে এবং PUT হ'ল উপস্থাপনাটির "চিত্র / jpeg" এর একটি সামগ্রী-প্রকার থাকে, তবে উত্সের সার্ভারের একটি করা উচিত:

ক। নতুন মিডিয়া ধরণের প্রতিফলিত করতে লক্ষ্য সংস্থানটিকে পুনরায় কনফিগার করুন;

খ। নতুন রিসোর্স স্টেট হিসাবে সংরক্ষণের পূর্বে রিসোর্সের সাথে সামঞ্জস্যপূর্ণ একটি ফর্ম্যাটে PUT উপস্থাপনাকে রূপান্তর করুন; বা,

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

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

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


0

সম্পাদনা: প্রকৃতপক্ষে ইউআরআই GETবাকি থাকা আদর্শ থেকে অনুরোধগুলি আটকাতে পারে ।


বৈধতার জন্য তবে, কোনও অনুরোধের বৈধতা জানানোর জন্য HTTP স্থিতি কোডগুলি ব্যবহার করা (একটি নতুন তৈরি করতে বা বিদ্যমান 'প্যারামিটারটি সংশোধন করতে) একটি বিশ্রামের মডেল ফিট করবে।

400 Bad Requestজমা দেওয়া ডেটা যদি অবৈধ / অবৈধ হয় এবং পুনরায় জমা দেওয়ার আগে অনুরোধটি পরিবর্তন করতে হবে ( HTTP / 1.1 স্থিতি কোডগুলি ) যদি একটি স্থিতি কোডের সাথে ফিরে রিপোর্ট করুন ।

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


ইউআরআই বলতে একটি সনাক্তকারী হতে বোঝায়। একটি নির্দিষ্ট ইউআরএল ব্যবহারের পার্শ্ব প্রতিক্রিয়া হওয়া উচিত নয়। কোনও প্রক্সি এটি দিয়ে কী করবে তা কল্পনা করুন।
ব্রেটন

2
বা গুগল, এই বিষয়ে। আমি একবার একটি ওয়েবস্টোর সম্পর্কে একটি গল্প পড়ি যা তাদের সমস্ত পণ্য গুগল দ্বারা মুছে ফেলা হয়েছিল কারণ এই ধরণের বোকামির কারণে।
ব্রেটন

0

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

http://example.com/amort_cal/2009-10-20/30yrsfixed/monthly/5.00/200000

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


5
আমি মনে করি যে এখানে ফরোয়ার্ড স্ল্যাশগুলি ব্যবহার করা কিছুটা নির্বোধ, amort_cal এর সাথে কী ভুল হবে? তারিখ = ২০০৯-১০-২০ এবং টাইপ = ৩০ বছর বয়সী & পিরিয়ড = মাসিক এবং হার = 5.0 এবং উদ্যোগমাত = 200000? যতক্ষণ এটি রিসোর্স হয় ততক্ষণ রিস্ট করে না। কোনো URI বৈশিষ্ট আছে যত্ন যদিও। এই জাতীয় স্কিমের সাথে কাজ করার জন্য আপনি কীভাবে আপেক্ষিক লিঙ্কগুলি কল্পনা করতে পারেন?
ব্রেটন

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

1
এবং "পরামিতি" কোনও "সংস্থান" তে প্রয়োগ হয় না apply একটি উত্স একটি অনন্য শনাক্তকারী সহ একক সত্তা। আমার url একটি একক সংস্থান চিহ্নিত করে। একটি প্যারামিটারাইজড ইউআরএল প্যারামিটারগুলি ব্যবহার করে আপনি যে সংস্থানগুলি নির্বাচন করেছেন তা একটি সূচিত করে।
jmucchiello

2
REST "CRUDing સંપત્તિ" এর উপর ভিত্তি করে নয়। আপনার সমস্ত ক্যোয়ারী প্যারামিটারগুলি পাথ বিভাগগুলিতে স্টিক করা স্বয়ংক্রিয়ভাবে কোনও বিশ্রামের ইন্টারফেসের জন্য তৈরি করে না কারণ এখন আপনি মনে করেন যে প্রতিটি ক্রমবিন্যাসকে আপনি একটি উত্স বলতে পারেন। দুর্ভাগ্যক্রমে এমন কোনও জাদু প্রক্রিয়া নেই যা আপনি আপনার সিস্টেমে সংস্থানগুলি কী কী তা সনাক্ত করতে আবেদন করতে পারেন। এটির জন্য কোনও যান্ত্রিক সূত্র নয়, সতর্কতার সাথে নকশার প্রয়োজন।
ড্যারেল মিলার

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