বিশ্রামের পথে কোনও উত্সে একটি সার্ভার-সাইড পদ্ধতিটি কল করুন

142

মনে রাখবেন আমার কাছে REST সম্পর্কে প্রাথমিক ধারণা রয়েছে। ধরা যাক আমার এই URL টি রয়েছে:

http://api.animals.com/v1/dogs/1/

এবং এখন, আমি সার্ভারটি কুকুরের ছাল তৈরি করতে চাই। এটি কীভাবে করা যায় তা কেবল সার্ভারই ​​জানেন। ধরা যাক আমি এটি একটি সিআরএন কাজের জন্য চালাতে চাই যা কুকুরটিকে অনন্তকাল ধরে প্রতি 10 মিনিটে ছাঁটাই করে তোলে। এই কলটি দেখতে কেমন? আমি এই ধরনের করতে চাই:

ইউআরএল অনুরোধ:

ACTION http://api.animals.com/v1/dogs/1/

অনুরোধ সংস্থায়:

{"action":"bark"}

আমার নিজের এইচটিটিপি পদ্ধতিটি তৈরি করার জন্য আপনি আমার উপর ক্ষিপ্ত হওয়ার আগে আমাকে সাহায্য করুন এবং আমাকে কীভাবে একটি আরামদায়ক উপায়ে সার্ভার-সাইড পদ্ধতিতে প্রার্থনা করা উচিত সে সম্পর্কে আরও ভাল ধারণা দিন। :)

বর্ণালীকরণের জন্য সম্পাদনা করুন

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

  1. বাকল কেবল কুকুর.ইমেলকে একটি ইমেল পাঠায় এবং কিছুই রেকর্ড করে না।
  2. বার্ক কুকুরের কাছে একটি ইমেল প্রেরণ করে ইমেল এবং বর্ধিত কুকুর.বার্ককাউন্টকে 1 দ্বারা।
  3. বাকলটি যখন ছালটি ঘটে তখন বার্ক.টাইমস্ট্যাম্প রেকর্ডিংয়ের সাথে একটি নতুন "ছাল" রেকর্ড তৈরি করে। এটি কুকুর.বার্ককাউন্টকে 1 দ্বারা বৃদ্ধি করে।
  4. বার্ক গিথুব থেকে কুকুর কোডের সর্বশেষতম সংস্করণটি টানতে একটি সিস্টেম কমান্ড চালায়। এরপরে এটি কুকুরের মালিককে একটি টেক্সট বার্তা প্রেরণ করে তাদের জানায় যে নতুন কুকুর কোডটি প্রস্তুত রয়েছে।
api  rest  url  api-design  restful-architecture 
— কার্ক ওউইমেট
সূত্র
14
মজার বিষয় হল, একটি বেনিস্টি যুক্ত করা আপনার কাছে মূল উত্তরগুলির চেয়ে খারাপ উত্তরগুলি আকর্ষণ করে বলে মনে হয় ;-) উত্তরের মূল্যায়ন করার সময় মনে রাখবেন যে: 1) এইচটিটিপি ক্রিয়াগুলির জন্য চশমা পোষ্ট ব্যতীত অন্য কোনও পছন্দকে বাদ দেয়। ২) ইউআরএল কাঠামোর সাথে রিস্টের কোনও যোগসূত্র নেই - এটি কনফারেন্টগুলির (জেনারেল তালিকা, ক্যাশেযোগ্য, স্তরযুক্ত, ইউনিফর্ম ইন্টারফেস ইত্যাদি) সুবিধার তুলনায় (স্কেলিবিলিটি, নির্ভরযোগ্যতা, দৃশ্যমানতা ইত্যাদি) এর জেনেরিক তালিকা। 3) বর্তমান অনুশীলন (যেমন আরপিসি চশমাগুলিতে পোষ্ট ব্যবহার করে) ট্রাম্প সংজ্ঞাবাদীরা যারা তাদের নিজস্ব এপিআই বিধি তৈরি করে চলেছে। 4) REST এর জন্য অভিন্ন ইন্টারফেসের প্রয়োজন (HTTP অনুমান অনুসরণ করে)।
— রেমন্ড হেটিঙ্গার
@ কির্ক নতুন উত্তর সম্পর্কে আপনার মতামত কি? এমন কি এমন কিছু আছে যা আপনি এখনও জানতে চান তবে সেগুলির কোনওটিতেই সম্বোধন করা হয়নি? আমার উত্তরটি সম্পাদনা করে আমি আরও বেশি খুশি হব যদি এটি আরও সহায়ক হতে পারে।
— জর্দান
@RaymondHettinger PATCHউপযুক্ত হতে পারে না। আমি আমার উত্তরটির শেষের দিকে কেন ব্যাখ্যা করব ।
— জর্দান
প্যাচচ কেবলমাত্র কুকুর.বার্ককাউন্টকে বাড়ানোর জন্য উপযুক্ত । পোষ্ট হ'ল ইমেল প্রেরণ, একটি নতুন ছাল রেকর্ড তৈরি করা, গিথুব থেকে ডাউনলোড করার জন্য কমান্ড চালানো, বা কোনও পাঠ্য বার্তা ট্রিগার করার পদ্ধতি। @ জর্দান, আপনার প্যাচ আরএফসি পড়ার ধারণাটি কল্পনাযোগ্য তবে কিছুটা আংশিক সম্পদ পরিবর্তনের জন্য পিটি-র একটি রূপ হিসাবে তার অভিপ্রায় বিরোধী। দূরবর্তী প্রক্রিয়া কলগুলির জন্য POST ব্যবহারের স্ট্যান্ডার্ড অনুশীলনকে স্বীকৃতি দেওয়ার পরিবর্তে আপনি HTTP স্পেসগুলির অপ্রচলিত পাঠ নিয়ে এসে ওপিকে সহায়তা করছেন বলে আমি মনে করি না।
— রেমন্ড হেটিঙ্গার
@RaymondHettinger যার অনুশীলন কার্যত standardizes পোষ্ট? সমস্ত স্ট্যান্ডার্ড আরপিসি ইন্টারফেস আমি দেখেছি কোনও সত্তা (আরএসএসফুল নয়), বনাম ইউআরআই দ্বারা একটি সংস্থান চিহ্নিত করুন, সুতরাং আরপিসি কনভেনশনকে অগ্রাধিকার দেওয়ার একটি বৈধ উত্তর যেভাবেই হোক অপ্রচলিত হওয়া দরকার, যা আমি মনে করি প্রচলিত আরপিসির মানটিকে অস্বীকার করে: একটি কল্পনাশক্তি বা অসঙ্গত । আপনি কখনই পোষ্টের সাথে ভুল হতে পারবেন না কারণ এটি ডেটা প্রসেসিংয়ের জন্য ক্যাচ-অল, তবে আরও নির্দিষ্ট পদ্ধতি রয়েছে। REST এর অর্থ সম্পদগুলির নামকরণ এবং তাদের রাজ্যে পরিবর্তনগুলি বর্ণনা করা, রাষ্ট্র পরিবর্তনকারী পদ্ধতির নামকরণ নয়। প্যাচ এবং পোস্ট উভয়ই রাষ্ট্রের পরিবর্তনের বর্ণনা দেয়।
— জর্দান

উত্তর:

280

বিশ্রামের নকশার লক্ষ্য কেন?

RESTful নীতিগুলি এমন বৈশিষ্ট্যগুলি নিয়ে আসে যা ওয়েব সাইটগুলিকে API নকশায় ওয়েব সাইটগুলিকে (একটি র্যান্ডম মানব ব্যবহারকারী "তাদের" "সার্ফ" করতে) সহজ করে তোলে তাই প্রোগ্রামার ব্যবহারকারীর পক্ষে এগুলি সহজ। REST ভাল না কারণ এটি REST, এটি ভাল কারণ এটি ভাল। এটি বেশিরভাগ ক্ষেত্রেই সহজ কারণ এটি সহজ ।

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

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

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

Actions কর্মের দিক থেকে চিন্তা করার পরিবর্তে এটি সম্পাদন করতে পারে ("মানচিত্রে স্থানগুলির জন্য অনুসন্ধান করুন") ...

... সেই ক্রিয়াগুলির ফলাফলের দিক দিয়ে ভাবার চেষ্টা করুন ("মানচিত্রের অনুসন্ধানের মানদণ্ডের সাথে মিলে যায় এমন জায়গাগুলির তালিকা")।

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


প্রথম ডিজাইন ইস্যু

চলুন একবার দেখে নেওয়া যাক প্রস্তাবিত নকশা:

ACTION http://api.animals.com/v1/dogs/1/

প্রথমে, আমাদের একটি নতুন এইচটিটিপি ক্রিয়া ( ACTION) তৈরি করার কথা ভাবা উচিত নয় । সাধারণভাবে বলতে গেলে, এটি বেশ কয়েকটি কারণে অনাকাঙ্ক্ষিত :

  • (1) কেবলমাত্র ইউআরআই পরিষেবা দেওয়া, একজন "এলোমেলো" প্রোগ্রামার কীভাবে জানবে ACTIONক্রিয়াটি বিদ্যমান?
  • (২) প্রোগ্রামার যদি এটি জানে তবে সে এর শব্দার্থক কীভাবে জানবে? সেই ক্রিয়াটির অর্থ কী?
  • (3) কোন বিশেষণ (সুরক্ষা, আদর্শ) এর ক্রিয়াটি প্রত্যাশা করা উচিত?
  • (4) যদি প্রোগ্রামারটির খুব সাধারণ ক্লায়েন্ট থাকে যা কেবলমাত্র স্ট্যান্ডার্ড এইচটিটিপি ক্রিয়াকলাপ পরিচালনা করে?
  • (5) ...

এখন আসুন ব্যবহার বিবেচনা করুনPOST (আমি নীচে কেন এটির জন্য আলোচনা করব, কেবল এখনই এটির জন্য আমার শব্দটি গ্রহণ করুন):

POST /v1/dogs/1/ HTTP/1.1
Host: api.animals.com

{"action":"bark"}

এটি ঠিক হতে পারে ... তবে কেবল যদি :

  • {"action":"bark"}একটি দলিল ছিল; এবং
  • /v1/dogs/1/ছিল একটি "ডকুমেন্ট প্রসেসর" (কারখানার মতো) ইউআরআই। একটি "ডকুমেন্ট প্রসেসর" এমন একটি ইউআরআই যা আপনি কেবল "জিনিসগুলিতে নিক্ষেপ" এবং তাদের সম্পর্কে "ভুলে যেতে" চান - প্রসেসর আপনাকে "নিক্ষেপ" করার পরে একটি নতুন তৈরি উত্সে পুনর্নির্দেশ করতে পারে। উদাহরণস্বরূপ একটি বার্তা দালাল পরিষেবাতে বার্তা পোস্ট করার জন্য ইউআরআই, যা পোস্ট করার পরে আপনাকে এমন একটি ইউআরআই-এ স্থানান্তরিত করে যা বার্তার প্রসেসিংয়ের স্থিতি দেখায়।

আমি আপনার সিস্টেম সম্পর্কে খুব বেশি কিছু জানি না, তবে আমি ইতিমধ্যে বাজি দিয়েছি যে উভয়ই সত্য নয়:

  • {"action":"bark"} কোনও দস্তাবেজ নয় , এটি আসলে সেই পদ্ধতি যা আপনি পরিষেবাতে নিনজা-গোপন করার চেষ্টা করছেন ; এবং
  • /v1/dogs/1/কোনো URI একটি "কুকুর" রিসোর্স (সম্ভবত সঙ্গে কুকুর প্রতিনিধিত্ব করে id==1) এবং একটি নথি প্রসেসর।

সুতরাং আমরা এখন যা জানি কেবল এটিই হ'ল উপরের নকশাটি এত বিশ্রামের নয়, তবে এটি ঠিক কী? এ সম্পর্কে এত খারাপ কী? মূলত, এটি খারাপ কারণ এটি জটিল অর্থ সহ জটিল ইউআরআই। আপনি এটি থেকে কিছু অনুমান করতে পারবেন না। একজন প্রোগ্রামার কীভাবে জানতে barkপারে যে একটি কুকুরের এমন ক্রিয়া রয়েছে যা গোপনে POSTএটিতে প্রবেশ করতে পারে ?


আপনার প্রশ্নের API কলগুলি ডিজাইন করা

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

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

উপরের বর্ণনার পরে আমরা দেখতে পাচ্ছি যে এটির একটি সাবসোর্সbark হিসাবে মডেল করা যেতে পারে (যেহেতু একটি কুকুরের মধ্যে রয়েছে , অর্থাত্dog কুকুরটি একটি কুকুর দ্বারাbark "ছাঁটাই" )।

এই যুক্তি থেকে আমরা ইতিমধ্যে পেয়েছি:

  • পদ্ধতিটি হ'ল POST
  • সংস্থানটি হ'ল /barksকুকুরের সাবসোর্স:, /v1/dogs/1/barksএকটি bark"কারখানার" প্রতিনিধিত্ব করে । যে ইউআরআই প্রতিটি কুকুরের জন্য অনন্য (যেহেতু এটি অধীন রয়েছে /v1/dogs/{id})।

এখন আপনার তালিকার প্রতিটি ক্ষেত্রে একটি নির্দিষ্ট আচরণ রয়েছে।

1. বাকল কেবল একটি ইমেল প্রেরণ করে dog.emailএবং কিছুই রেকর্ড করে না।

প্রথমতঃ, কি বারিং (কোনও ইমেল প্রেরণ করা) একটি সিনক্রোনাস বা অ্যাসিঙ্ক্রোনাস টাস্ক? দ্বিতীয়ত barkঅনুরোধটির জন্য কোনও নথির প্রয়োজন (ই-মেইল, সম্ভবত) বা এটি খালি?


1.1 বাকল কোনও ইমেল প্রেরণ করে dog.emailএবং কিছুই রেকর্ড করে না (সিনক্রোনাস টাস্ক হিসাবে)

এই ক্ষেত্রে সহজ। barksকারখানার রিসোর্সে কল করার সাথে সাথে একটি ছাল পাওয়া যায় (একটি ইমেল প্রেরিত) এখনই এবং প্রতিক্রিয়া (ঠিক আছে বা না থাকলে) এখনই দেওয়া হবে:

POST /v1/dogs/1/barks HTTP/1.1
Host: api.animals.com
Authorization: Basic mAUhhuE08u724bh249a2xaP=

(entity-body is empty - or, if you require a **document**, place it here)

200 OK

এটি রেকর্ড হিসাবে (পরিবর্তন) কিছুই, 200 OKযথেষ্ট। এটি দেখায় যে সবকিছু প্রত্যাশার মতো চলে গেছে।


১.২ বার্ক একটি ইমেল প্রেরণ করে dog.emailএবং কিছুই রেকর্ড করে না (একটি অ্যাসিনক্রোনাস টাস্ক হিসাবে)

এই ক্ষেত্রে, ক্লায়েন্টের অবশ্যই barkকাজটি ট্র্যাক করার একটি উপায় থাকতে হবে । barkকাজের তারপর, এটা নিজস্ব কোনো URI সঙ্গে একটি সম্পদ থাকা উচিত .:

POST /v1/dogs/1/barks HTTP/1.1
Host: api.animals.com
Authorization: Basic mAUhhuE08u724bh249a2xaP=

{document body, if needed;
NOTE: when possible, the response SHOULD contain a short hypertext note with a hyperlink
to the newly created resource (bark) URI, the same returned in the Location header
(also notice that, for the 202 status code, the Location header meaning is not
standardized, thus the importance of a hipertext/hyperlink response)}

202 Accepted
Location: http://api.animals.com/v1/dogs/1/barks/a65h44

এইভাবে, প্রতিটি barkসনাক্তযোগ্য able ক্লায়েন্ট তারপর একটি ইস্যু করতে পারে GETথেকে barkএটি সাম্প্রতিক রাষ্ট্র নিশ্চিত করে জেনে নিতে কোনো URI। এমনকি DELETEএটি বাতিল করতে একটি ব্যবহার করুন ।


২. বাকল একটি ইমেল প্রেরণ করে dog.emailএবং তারপরে dog.barkCount1 দ্বারা বর্ধিত হয়

আপনি যদি ক্লায়েন্টকে জানাতে চান তবে এই dogসংস্থানটি পরিবর্তিত হয়ে উঠতে পারে:

POST /v1/dogs/1/barks HTTP/1.1
Host: api.animals.com
Authorization: Basic mAUhhuE08u724bh249a2xaP=

{document body, if needed; when possible, containing a hipertext/hyperlink with the address
in the Location header -- says the standard}

303 See Other
Location: http://api.animals.com/v1/dogs/1

এই ক্ষেত্রে, locationশিরোনামের উদ্দেশ্য হ'ল ক্লায়েন্টকে জানানো উচিত যে তার একবার নজর দেওয়া উচিত dog। এইচটিটিপি আরএফসি303 থেকে :

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

যদি কাজটি barkঅ্যাসিক্রোনাস হয় তবে 1.2পরিস্থিতিটির মতো একটি সাব্রোসোর্স প্রয়োজন এবং টাস্ক সম্পূর্ণ হওয়ার পরে একটিটি 303ফিরে দেওয়া উচিত GET .../barks/Y।


3. বাকলটি যখন ছালটি ঘটে তখন রেকর্ডিংয়ের barkসাথে একটি নতুন রেকর্ড তৈরি করে bark.timestamp। এটি বৃদ্ধি করেও dog.barkCount১।

POST /v1/dogs/1/barks HTTP/1.1
Host: api.animals.com
Authorization: Basic mAUhhuE08u724bh249a2xaP=

(document body, if needed)

201 Created
Location: http://api.animals.com/v1/dogs/1/barks/a65h44

এখানে, barkঅনুরোধের কারণে এটি তৈরি করা হয়েছে, সুতরাং স্থিতি 201 Createdপ্রয়োগ করা হয়।

যদি সৃষ্টিটি অ্যাসিক্রোনাস হয় তবে পরিবর্তে এটির202 Accepted প্রয়োজন ( যেমন HTTP আরএফসি বলেছে )।

টাইমস্ট্যাম্প সংরক্ষণ করা barkসম্পদের একটি অংশ এবং GETএটিতে এটি দিয়ে পুনরুদ্ধার করা যেতে পারে । আপডেট কুকুর এছাড়াও "নথিভুক্ত" হতে পারে GET dogs/X/barks/Y।


4. ছাল গিথুব থেকে কুকুর কোডের সর্বশেষতম সংস্করণটি টানতে একটি সিস্টেম কমান্ড চালায়। এটি তখন dog.ownerতাদের কাছে একটি পাঠ্য বার্তা প্রেরণ করে যে নতুন কুকুর কোডটি প্রস্তুত রয়েছে in

এইটির কথাটি জটিল, তবে এটি প্রায় একটি সাধারণ অ্যাসিনক্রোনাস কাজ:

POST /v1/dogs/1/barks HTTP/1.1
Host: api.animals.com
Authorization: Basic mAUhhuE08u724bh249a2xaP=

(document body, if needed)

202 Accepted
Location: http://api.animals.com/v1/dogs/1/barks/a65h44

ক্লায়েন্ট তারপরে বর্তমান অবস্থা জানার GETজন্য এস প্রদান করবে /v1/dogs/1/barks/a65h44(যদি কোডটি টানা থাকে তবে এটি ইমেলটি মালিকের কাছে প্রেরণ করা হয়েছিল এবং এ জাতীয়)। যখনই কুকুর পরিবর্তন হয়, একটি 303প্রশংসনীয়।


মোড়ক উম্মচন

রয় ফিল্ডিংয়ের উদ্ধৃতি :

আরআরইএসটিগুলির পদ্ধতির জন্য কেবলমাত্র প্রয়োজনীয় জিনিস হ'ল এগুলি সমস্ত সংস্থার জন্য সমানভাবে সংজ্ঞায়িত করা উচিত (যেমন, যাতে অনুরোধটির অর্থ বোঝার জন্য মধ্যস্থতাকারীদের উত্সের ধরণটি জানতে না হয়)।

উপরের উদাহরণগুলিতে, POSTঅভিন্নভাবে ডিজাইন করা হয়েছে। এটি কুকুরটিকে তৈরি করবে " bark" এটি নিরাপদ নয় (অর্থের মধ্যে ছালের প্রভাব রয়েছে), এবং না আদর্শবান (প্রতিটি অনুরোধ একটি নতুন ফল দেয় bark), যা POSTক্রিয়াটি ভালভাবে ফিট করে ।

প্রোগ্রামার জানতে চাই: একটি POSTথেকে barksউৎপাদনের একটি bark। প্রতিক্রিয়া স্থিতি কোডগুলি (প্রয়োজন অনুসারে সত্তা-দেহ এবং শিরোনামগুলির সাথেও) কী পরিবর্তন হয়েছে এবং কীভাবে ক্লায়েন্ট কীভাবে এগিয়ে যেতে পারে এবং কীভাবে এগিয়ে যেতে হবে তা ব্যাখ্যা করার কাজ করে।

দ্রষ্টব্য: ব্যবহৃত প্রাথমিক উত্সগুলি হ'ল : " রেস্টফুল ওয়েব সার্ভিসেস " বই, এইচটিটিপি আরএফসি এবং রায় ফিল্ডিংয়ের ব্লগ ।



সম্পাদনা:

প্রথমবার তৈরি হওয়ার পরে প্রশ্ন এবং উত্তরটি বেশ খানিকটা বদলে গেছে। মূল প্রশ্ন কোনো URI মত ডিজাইন সম্পর্কে জিজ্ঞেস করেন:

ACTION http://api.animals.com/v1/dogs/1/?action=bark

এটি কেন ভাল পছন্দ নয় তার ব্যাখ্যা নীচে:

ক্লায়েন্টরা কীভাবে সার্ভারকে ডেটা দিয়ে কী করতে বলে তা হল পদ্ধতি সম্পর্কিত তথ্য ।

  • RESTful ওয়েব পরিষেবাদি HTTP পদ্ধতিতে পদ্ধতির তথ্য সরবরাহ করে।
  • সাধারণ আরপিসি-স্টাইল এবং এসওএপি পরিষেবাগুলি তাদের সত্তা-দেহ এবং এইচটিটিপি শিরোনামে রাখে।

কোন অংশ ডেটার [ক্লায়েন্ট চায় সার্ভার] এ অপারেট হয় scoping তথ্য ।

  • বিশ্রামের পরিষেবাগুলি ইউআরআই ব্যবহার করে। এসওএপি / আরপিসি-স্টাইল পরিষেবাগুলি আবার সত্তা-দেহ এবং এইচটিটিপি শিরোনাম ব্যবহার করে।

উদাহরণ হিসাবে, গুগলের ইউআরআই নিন http://www.google.com/search?q=DOG। সেখানে, পদ্ধতি সম্পর্কিত তথ্য GETএবং স্কোপিংয়ের তথ্য /search?q=DOG।

দীর্ঘ সংক্ষিপ্ত বিবরণ:

  • ইন RESTful আর্কিটেকচারের , পদ্ধতি তথ্য HTTP- র পদ্ধতি মধ্যে যায়।
  • ইন রিসোর্স ওরিয়েন্টড আর্কিটেকচার , scoping তথ্য কোনো URI মধ্যে যায়।

এবং থাম্বের নিয়ম:

যদি HTTP পদ্ধতিটি পদ্ধতির তথ্যের সাথে মেলে না, তবে পরিষেবাটি বিশ্রামের নয়। যদি স্কোপিংয়ের তথ্য ইউআরআইতে না থাকে তবে পরিষেবাটি সংস্থান-ভিত্তিক নয়।

আপনি "ছাল" "ক্রিয়া" টি ইউআরএল (বা সত্তা-দেহে) রাখতে এবং ব্যবহার করতে পারেন POST। সেখানে কোনও সমস্যা নেই, এটি কাজ করে এবং এটি করার সহজতম উপায় হতে পারে তবে এটি আরামদায়ক নয় ।

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

আমি আপনার নির্দিষ্ট ব্যবসায়ের প্রয়োজন সম্পর্কে কথা বলতে পারি না, তবে আমি আপনাকে একটি উদাহরণ দিতে পারি: একটি বিশ্রামযুক্ত অর্ডারিং পরিষেবা বিবেচনা করুন যেখানে ইউআরআইতে অর্ডার পছন্দ হয় example.com/order/123।

এখন বলুন আমরা একটি অর্ডার বাতিল করতে চাই, আমরা এটি কীভাবে করব? কেউ "বিলোপ" "ক্রিয়া" এবং এটির মতো ডিজাইন করার জন্য প্ররোচিত হতে পারে POST example.com/order/123?do=cancel।

এটি বিশ্রামের মতো নয়, যেমন আমরা উপরে আলোচনা করেছি। পরিবর্তে, আমরা এটিকে পাঠানো একটি উপাদান সহ একটি PUTনতুন উপস্থাপনা হতে পারে :ordercanceledtrue

PUT /order/123 HTTP/1.1
Content-Type: application/xml

<order id="123">
    <customer id="89987">...</customer>
    <canceled>true</canceled>
    ...
</order>

এবং এটাই. যদি অর্ডারটি বাতিল করা না যায়, তবে একটি নির্দিষ্ট স্থিতি কোড ফেরত দেওয়া যেতে পারে। ( POST /order/123/canceledসত্তা-দেহের মতো একটি সাবসোর্স ডিজাইন trueসরলতার জন্যও উপলভ্য হতে পারে))

আপনার নির্দিষ্ট দৃশ্যে, আপনি অনুরূপ কিছু চেষ্টা করতে পারেন। এই ভাবে, যখন একটি কুকুর ঘেউ ঘেউ করা হয়, উদাহরণস্বরূপ, একটি GETসময়ে /v1/dogs/1/সেই তথ্য অন্তর্ভুক্ত হতে পারে (যেমন <barking>true</barking>) । বা ... যদি এটি খুব জটিল হয় তবে আপনার বিশ্রামের প্রয়োজনীয়তাটি আলগা করুন এবং এতে আঁকুন POST।

হালনাগাদ:

আমি উত্তরটি খুব বড় করতে চাই না, তবে সংস্থানগুলির এক সেট হিসাবে একটি অ্যালগরিদম (একটি ক্রিয়া ) প্রকাশের হ্যাং পেতে এটি কিছুটা সময় নেয় । ক্রিয়া পদ চিন্তা করার পরিবর্তে ( "মানচিত্র এ স্থান অনুসন্ধান করা" এক চাহিদা ক্রিয়াটি (ফলাফল পরিপ্রেক্ষিতে মনে করা), "একটি অনুসন্ধানের মিলে মানচিত্রে থাকা স্থানগুলির তালিকা" )।

আপনি যদি দেখতে পান যে আপনার ডিজাইনটি এইচটিটিপির ইউনিফর্ম ইন্টারফেসের সাথে ফিট করে না তবে আপনি নিজেকে এই পদক্ষেপে ফিরে আসতে পারেন back

ক্যোয়ারী ভেরিয়েবল হয় তথ্য scoping কিন্তু কি না বোঝাতে নতুন সম্পদগুলি ( /post?lang=enপরিষ্কারভাবে হয় একই হিসাবে রিসোর্স /post?lang=jp, শুধু একটি বিভিন্ন উপস্থাপনা)। বরং বোঝাতে ব্যবহার করা হয় ক্লায়েন্ট রাষ্ট্র (যেমন ?page=10; যাতে রাষ্ট্র সার্ভার রাখা হয় না ?lang=enএখানে একটি উদাহরণও নেই) অথবা ইনপুট প্যারামিটার করার আলগোরিদিমিক সম্পদ ( /search?q=dogs, /dogs?code=1)। আবার স্বতন্ত্র সংস্থান নয়।

HTTP ক্রিয়াগুলির (পদ্ধতি) বৈশিষ্ট্য:

আর একটি পরিষ্কার পয়েন্ট যা ?action=somethingইউআরআইতে দেখায় এটি বিশ্রামযোগ্য নয়, এটি এইচটিটিপি ক্রিয়াগুলির বৈশিষ্ট্য:

  • GETএবং HEADনিরাপদ (এবং আদর্শবান);
  • PUTএবং DELETEকেবল আদর্শবান;
  • POST না হয়।

সুরক্ষা : একটি GETবা HEADঅনুরোধটি কোনও ডেটা পড়ার অনুরোধ , কোনও সার্ভারের স্থিতি পরিবর্তন করার অনুরোধ নয়। ক্লায়েন্টটি 10 বার একটি আবেদন করতে GETবা HEADঅনুরোধ করতে পারে এবং এটি একবারে তৈরি করা বা এটি কখনই তৈরি করার মতো নয় ।

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

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

এই দুটি বৈশিষ্ট্যই এইচটিটিপি প্রোটোকলের সাফল্যের জন্য গুরুত্বপূর্ণ ছিল (অবিশ্বস্ত নেটওয়ার্কের ওপরে!): GETপৃষ্ঠাটি সম্পূর্ণ লোড না হওয়া পর্যন্ত আপনি কতবার আপডেট করেছেন ( )?

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

— acdcjunior
সূত্র
আমি এই ধারণার সাথে মতামত নিয়েছি যে ইউআরএলটিতে অ্যাকশন হিসাবে মনোনীত কোনও সার্ভারে অ্যাকশন আহ্বান করা শান্ত নয়। "ডেটা-হ্যান্ডলিং প্রক্রিয়াতে ... একটি ব্লক ডেটা সরবরাহPOST করার জন্য " ডিজাইন করা হয়েছিল । মনে হয় প্রচুর ভাবেন লোকেরা ক্রিয়াকলাপ থেকে সংস্থানকে পৃথক করে তবে সত্যই ক্রিয়াগুলি কেবল এক ধরণের সংস্থান।
— জ্যাকব স্টিভেন্স
1
@ জ্যাকবস্টেভেনস ওপিতে প্রশ্নটি কিছুটা পরিবর্তিত হয়েছে সুতরাং আমি আরও উত্তর দেওয়ার জন্য আমার উত্তর আপডেট করতে চাই ( মূল প্রশ্নটি দেখুন , সম্ভবত আপনি আমার অর্থটি দেখতে পাবে)। আমি POST"ডেটা-হ্যান্ডলিং প্রক্রিয়াতে ... একটি ডেটা ব্লক সরবরাহ" এর সাথে একমত নই , তবে পার্থক্যটি হ'ল ডেটা ব্লক, ডেটা-র ব্লক নয় এবং পদ্ধতি (ক্রিয়া, পদ্ধতি, কমান্ড) হতে হবে মৃত্যুদণ্ড কার্যকর করা হয়। এটি POSTওভারলোডিং, এবং POSTওভারলোডিং আরপিসি-স্টাইল ডিজাইন, আরএসটিফুল নয়।
— acdcjunior
আমি অনুমান করছি যে ক্রিয়া / পদ্ধতি যুক্তিটি সার্ভারে রাখা হবে, অন্যথায় কলটির উদ্দেশ্য কী হবে? আপনি যে ক্ষেত্রে বর্ণনা করেছেন তাতে আমি সম্মতি জানাই, এটি ভাল নকশা হবে না। তবে কর্মটি সম্পাদনকারী পদ্ধতি বা সাবরুটিনটি ইউআরআই দ্বারা নির্দিষ্ট করা হবে (এটি অন্য কারণ যা ইউআরএল শেষে ক্রিয়া হিসাবে মনোনীত একটি ক্রিয়াকলাপ হিসাবে দরকারী এবং বিশুদ্ধ, যদিও অনেকে এর বিরুদ্ধে পরামর্শ দেয়)।
— জ্যাকব স্টিভেনস
6
আমাদের উত্তর আপডেট। এটি বেশ দীর্ঘ কারণ একটি বিশদ ব্যাখ্যার প্রয়োজন বলে মনে হয়েছে ("মনে রাখবেন আমার কাছে REST সম্পর্কে প্রাথমিক ধারণা রয়েছে" ")। এটি যথাসম্ভব পরিস্কার পরিপূর্ণ করার জন্য এটি এক ধরণের লড়াই ছিল। আশা করি এটি কোনওভাবে কাজে আসবে।
— acdcjunior
2
দুর্দান্ত ব্যাখ্যা, আমি ভোট দিয়েছি তবে 202 স্বীকৃত প্রতিক্রিয়াতে অবস্থানের শিরোনামটি ব্যবহার করা উচিত নয়। এটি একটি ভুল ব্যাখ্যা বলে মনে হচ্ছে যা অনেক লোক আরএফসি থেকে করে। এই স্ট্যাকওভারফ্লো.com
— জিজ্ঞাসা /
6

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

এটি REST সীমাবদ্ধতাগুলি, তারপরে HTTP- র উপাদানগুলি, তারপরে একটি সম্ভাব্য সমাধানের মধ্য দিয়ে যায়।

বিশ্রাম

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

তবে আরআরইএসটি চিন্তার এক আকর্ষণীয় উপায় এবং প্রশ্নের উদাহরণটি একটি রেস্টস্টুল ইন্টারফেসের সাথে মডেল করা সহজ বলে মনে হয়, তাই আসুন মজা করার জন্য এবং শিক্ষার জন্য চ্যালেঞ্জটি গ্রহণ করি।

REST চারটি ইন্টারফেস সীমাবদ্ধতা দ্বারা সংজ্ঞায়িত করা হয়:

সম্পদের সনাক্তকরণ; উপস্থাপনের মাধ্যমে সম্পদের হেরফের; স্ব-বর্ণনামূলক বার্তা; এবং, অ্যাপ্লিকেশন স্টেটের ইঞ্জিন হিসাবে হাইপারমিডিয়া।

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

প্রথম সীমাবদ্ধতা দিয়ে শুরু করা যাক: সংস্থানসমূহ সনাক্তকরণ ।

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

সুতরাং একটি কুকুর একটি সম্পদ। এটি চিহ্নিত করা দরকার।

আরো সঠিকভাবে, একটি সম্পদ আর একটি temporally তারতম্য সদস্যপদ ফাংশন এম আর ( T ), যা সময় জন্য টি সত্ত্বা, বা মান, যা হয় সমতুল্য একটি সেট থেকে মানচিত্র তৈরী করে। সেটের মানগুলি সম্পদ উপস্থাপনা এবং / অথবা সংস্থান সনাক্তকারী হতে পারে ।

আপনি শনাক্তকারীদের উপস্থাপনা এবং উপস্থাপনাগুলির সেট নিয়ে এবং একটি নির্দিষ্ট সময়ে তারা সকলেই একে অপরের সাথে যুক্ত বলে একটি কুকুরকে মডেল করেন। আপাতত, আইডেন্টিফায়ারটি "কুকুর # 1" ব্যবহার করি। এটি আমাদের দ্বিতীয় এবং তৃতীয় সীমাবদ্ধতায় নিয়ে আসে: সংস্থানসমূহের উপস্থাপনা এবং স্ব-বিবরণ ।

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

নীচে কুকুরের উদ্দেশ্যযুক্ত রাজ্য ক্যাপচার করার ক্রম রয়েছে, অর্থাত্ চিহ্নিতকরণ "কুকুর # 1" এর সাথে আমরা যুক্ত হতে চাই এমন প্রতিনিধিত্ব (নোট করুন যে এটি কুকুরের নাম, স্বাস্থ্যকে বিবেচনা করে না বলে এটি কেবলমাত্র রাজ্যের অংশকে উপস্থাপন করে) , বা এমনকি অতীত ছাল):

এই রাষ্ট্র পরিবর্তনটি কার্যকর হওয়ার সময় থেকে এটি প্রতি 10 মিনিটের মধ্যেই ঘুরছে এবং অনির্দিষ্টকালের জন্য অব্যাহত থাকবে।

এটি মেটাডেটার সাথে সংযুক্ত থাকার কথা যা এটি বর্ণনা করে। এই মেটাডেটা দরকারী হতে পারে:

এটি একটি ইংরেজি বিবৃতি। এটি উদ্দেশ্যযুক্ত রাষ্ট্রের অংশ বর্ণনা করে। যদি এটি একাধিকবার গৃহীত হয় তবে কেবল প্রথমটিকে প্রভাবিত হওয়ার অনুমতি দিন।

অবশেষে, চতুর্থ প্রতিবন্ধকতাটি দেখুন: HATEOAS ।

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

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

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

HTTP- র

HTTP নীচে REST সীমাবদ্ধতা প্রয়োগ করে:

সংস্থান সনাক্তকরণ : ইউআরআই

সংস্থার প্রতিনিধিত্ব : সত্তা-শরীর

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

HATEOAS : হাইপারলিঙ্কস

আপনি http://api.animals.com/v1/dogs/1ইউআরআই হিসাবে সিদ্ধান্ত নিয়েছেন । ধরে নেওয়া যাক ক্লায়েন্টটি সাইটের কোনও পৃষ্ঠা থেকে এটি পেয়েছে।

আসুন এই সত্তা-দেহটি ব্যবহার করুন (এর মান nextএকটি টাইমস্ট্যাম্প; 0'যখন এই অনুরোধটি প্রাপ্ত হয় তখন' এর একটি অর্থ)):

{"barks": {"next": 0, "frequency": 10}}

এখন আমাদের একটি পদ্ধতি দরকার। PATCH "উদ্দিষ্ট রাষ্ট্রের অংশ" বিবরণটি ফিট করে যা আমরা সিদ্ধান্ত নিয়েছিলাম:

প্যাচ পদ্ধতিটি অনুরোধ করে যে অনুরোধ সত্তায় বর্ণিত পরিবর্তনের একটি সেট অনুরোধ-ইউআরআই দ্বারা চিহ্নিত সংস্থানটিতে প্রয়োগ করা হবে।

এবং কিছু শিরোনাম:

সত্তা-দেহের ভাষা নির্দেশ করতে: Content-Type: application/json

এটি একবারে ঘটেছিল তা নিশ্চিত করার জন্য: If-Unmodified-Since: <date/time this was first sent>

এবং আমাদের একটি অনুরোধ আছে:

PATCH /v1/dogs/1/ HTTP/1.1
Host: api.animals.com
Content-Type: application/json
If-Unmodified-Since: <date/time this was first sent>
[other headers]

{"barks": {"next": 0, "frequency": 10}}

সাফল্যের সাথে, ক্লায়েন্টটির 204প্রতিক্রিয়া হিসাবে একটি স্ট্যাটাস কোড পাওয়া উচিত , বা 205যদি /v1/dogs/1/নতুন বার্কিংয়ের সময়সূচী প্রতিবিম্বিত করতে প্রতিনিধিত্ব পরিবর্তিত হয়।

ব্যর্থতায়, এটির জন্য একটি 403এবং একটি সহায়ক বার্তা পাওয়া উচিত ।

প্রতিক্রিয়া হিসাবে একটি উপস্থাপনায় ছালার সময়সূচী প্রতিফলিত করার জন্য পরিষেবাটির জন্য বিশ্রাম নেওয়া অপরিহার্য নয় GET /v1/dogs/1/, তবে কোনও জেএসওএন প্রতিনিধিত্বের মধ্যে অন্তর্ভুক্ত করা সর্বাধিক তাৎপর্যপূর্ণ হবে:

"barks": {
    "previous": [x_1, x_2, ..., x_n],
    "next": x_n,
    "frequency": 10
}

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

— জর্ডন
সূত্র
3

বেশিরভাগ লোক এই উদ্দেশ্যে POST ব্যবহার করে। "অন্য কোনও এইচটিটিপি পদ্ধতি যথাযথ মনে না হলে" কোনও অনিরাপদ বা ননডেম্পোটেন্ট অপারেশন করার জন্য এটি উপযুক্ত।

যেমন Apis XMLRPC ব্যবহার পোষ্ট ট্রিগার যে সমস্ত কর্ম নির্বিচারে কোড রান করতে পারেন হবে। "ক্রিয়া" পোস্টের ডেটাতে অন্তর্ভুক্ত করা হয়েছে:

POST /RPC2 HTTP/1.0
User-Agent: Frontier/5.1.2 (WinNT)
Host: betty.userland.com
Content-Type: text/xml
Content-length: 181

<?xml version="1.0"?>
<methodCall>
   <methodName>examples.getStateName</methodName>
   <params>
      <param>
         <value><i4>41</i4></value>
         </param>
      </params>
   </methodCall>

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

মনে রাখবেন যে RPC নিজেই খুব বিশ্রামের নয় কারণ এটি সংস্থান ভিত্তিক নয়। তবে আপনার যদি রাষ্ট্রহীনতা, ক্যাশিং বা লেয়ারিং দরকার হয় তবে উপযুক্ত রূপান্তর করা শক্ত নয়। উদাহরণের জন্য http://blog.perfectapi.com/2012/opinionated-rpc-apis-vs-restful-apis/ দেখুন ।

— রেমন্ড হেট্টিংগার
সূত্র
আমি মনে করি আপনি ইউআরএলনকোড করুন যা পরমগুলি কোয়েরি স্ট্রিংয়ে
— রাখবে না
@ কির্ক হ্যাঁ, তবে একটি ছোটখাট পরিবর্তন করে চূড়ান্ত ফরোয়ার্ড স্ল্যাশটি ফেলে দিন: POST api.animals.com/v1/dogs1?action=bark
— রেমন্ড হেটিঙ্গার
আপনি যদি এই উত্তরের পরামর্শটি অনুসরণ করেন তবে মনে রাখবেন যে ফলপ্রাপ্ত এপিআই টি বিশ্রামযোগ্য হবে না।
— নিকোলাস শ্যাঙ্কস
2
এটি শান্ত না কারণ এইচটিটিপি একটি সংস্থার সনাক্তকারী হিসাবে ইউআরএল প্রতিষ্ঠিত করে এবং একটি URL /RPC2কোনও উত্স সনাক্ত করতে কিছুই করে না - এটি একটি সার্ভার প্রযুক্তি সনাক্ত করে। পরিবর্তে, methodNameএটি 'উত্স' সনাক্ত করতে চেষ্টা করে - তবে তারপরেও, এটি বিশেষ্য / ক্রিয়া পার্থক্য থেকে কোনও লাভ করে না; এখানে কেবল 'ক্রিয়াপদ'-জাতীয় জিনিস methodCall। এটি 'রাষ্ট্র-নাম পুনরুদ্ধার করুন' এর পরিবর্তে 'রাষ্ট্রীয় নাম-পুনরুদ্ধার করুন' - এর মতো আরও অনেক কিছু বোঝায় sense
— জর্দান
লিঙ্কগুলির জন্য +1; খুব তথ্যপূর্ণ এবং "মতামতযুক্ত আরপিসি" পরীক্ষাটি উদ্ভাবক tive
— জর্দান
2

POSTহয় HTTP- র পদ্ধতি পরিকল্পিত জন্য

ডেটা হ্যান্ডলিংয়ের প্রক্রিয়াটিতে ডেটা ব্লক সরবরাহ করা হচ্ছে

নন-সিআরইউডি-ম্যাপযুক্ত ক্রিয়াকলাপ পরিচালনা করার জন্য সার্ভার-সাইড পদ্ধতি হ'ল রয় ফিল্ডিং আরএসটি-র সাথে POST। POSTতথ্য প্রসেস করার জন্য সার্ভার-সাইড পদ্ধতিতে ডেটার সর্বাধিক পোস্টিং পরিচালনা করবে।

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

— জ্যাকব স্টিভেন্স
সূত্র
1
পুট বনাম পোস্ট সবই ইউআরএল সম্পর্কে। .6..6 পুট-এর পরে তৃতীয় অনুচ্ছেদে বলা হয়েছে যে দুটি পদ্ধতির উদ্দেশ্য তাই PUTইউআরএল বলতে ক্লায়েন্টের সামগ্রীর দ্বারা প্রতিস্থাপন করা উচিত এবং POSTইউআরএল বলতে বোঝায় যে ক্লায়েন্টের সামগ্রীটি কী চায় তা প্রক্রিয়াকরণ করা উচিত ।
— জর্দান
1

যদি আমরা ধরে নিই যে বার্কিং একটি অভ্যন্তরীণ / নির্ভর / উপ-উত্স যা গ্রাহক এতে কাজ করতে পারে তবে আমরা বলতে পারি: 

POST http://api.animals.com/v1/dogs/1/bark

কুকুর সংখ্যা 1 ছাল

GET http://api.animals.com/v1/dogs/1/bark

শেষ ছাল টাইমস্ট্যাম্প ফেরত

DELETE http://api.animals.com/v1/dogs/1/bark

প্রয়োগ হয় না! সুতরাং এটি উপেক্ষা করুন।

— bolbol
সূত্র
এটি কেবলমাত্র শান্ত যদি আপনি প্রতি সেউকে/v1/dogs/1/bark কোনও সংস্থান হিসাবে বিবেচনা করেন এবং কীভাবে সেই সংস্থার অভ্যন্তরীণ অবস্থার পরিবর্তন হওয়া উচিত তার একটি বর্ণনা হতে পারে। আমি দেখতে পেয়েছি যে এটি কেবল একটি উত্স হিসাবে বিবেচনা করা এবং সত্তা-শরীরে এটি ছাঁটাই হওয়া উচিত তা বোঝাতে আরও বেশি অর্থবোধ করে। POST/v1/dogs/1/
— জর্দান
মিমি .. ঠিক আছে, এটি এমন একটি সংস্থান যা আপনি এর অবস্থা পরিবর্তন করতে পারবেন। কারণ তার রাজ্যের পরিবর্তনের ফলাফলটি শব্দ করছে, কম সংস্থান তৈরি করে না! আপনি বার্ককে ক্রিয়াপদ হিসাবে দেখছেন (এটি হ'ল) ​​এ কারণেই আপনি এটিকে কোনও সংস্থান হিসাবে বিবেচনা করতে পারবেন না। আমি এটিকে নির্ভরশীল সংস্থান হিসাবে দেখছি যার রাজ্যটি পরিবর্তিত হতে পারে এবং যেহেতু এর রাজ্য বুলিয়ান, তাই সত্তা-দেহে এটি উল্লেখ করার কোনও কারণ আমি দেখতে পাচ্ছি না। এটাই আমার মতামত।
— বলবোল
1

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

প্রথমত, URL- এ অ্যাকশন পরামিতিগুলি রাখবেন না। Url সংজ্ঞায়িত কি আপনাকে কর্ম প্রয়োগ করা হয়, এবং কোয়েরি পরামিতি URL এর অংশ। এটি পুরোপুরি একটি বিশেষ্য হিসাবে চিন্তা করা উচিত । http://api.animals.com/v1/dogs/1/?action=barkএকটি আলাদা সংস্থান - একটি পৃথক বিশেষ্য - থেকে http://api.animals.com/v1/dogs/1/। [এনবি অ্যাশার ?action=barkপ্রশ্নটি থেকে ইউআরআই সরিয়ে ফেলেছে ]] উদাহরণস্বরূপ, তুলনা http://api.animals.com/v1/dogs/?id=1করুন http://api.animals.com/v1/dogs/?id=2। বিভিন্ন উত্স, কেবল ক্যোয়ারী স্ট্রিং দ্বারা পৃথক। সুতরাং আপনার অনুরোধের ক্রিয়াটি যদি না সরাসরি দেহহীন বিদ্যমান পদ্ধতি ধরণের (ট্র্যাক, অপশনস, হেড, জিইটি, ডিলেট, ইত্যাদি) সাথে অনুরোধ করে তবে অবশ্যই অনুরোধ সংস্থায় সংজ্ঞায়িত করা উচিত।

এরপরে, সিদ্ধান্ত নিন যে ক্রিয়াটি " আদর্শশক্তি " কিনা , যার অর্থ এটি প্রতিকূল প্রভাব ছাড়াই পুনরাবৃত্তি করা যেতে পারে (আরও ব্যাখ্যাের জন্য পরবর্তী অনুচ্ছেদ দেখুন)। উদাহরণস্বরূপ, ক্লায়েন্টটি পছন্দসই প্রভাবটি ঘটেছে কিনা তা নিশ্চিত না হলে সত্যের কাছে মান সেট করা পুনরাবৃত্তি হতে পারে। তারা আবার অনুরোধটি প্রেরণ করে এবং মানটি সত্য থাকে। একটি সংখ্যায় 1 যুক্ত করা আদর্শবান নয়। ক্লায়েন্ট যদি Add1 কমান্ডটি প্রেরণ করে তবে নিশ্চিত যে এটি কাজ করেছে এবং এটি আবার প্রেরণ করে, সার্ভারটি কি এক বা দুটি যুক্ত করেছিল? একবার আপনি এটি নির্ধারণ করে নিলে, আপনি নিজের পদ্ধতির মধ্যে PUTএবং তার থেকে বেছে নিতে আরও ভাল অবস্থানে রয়েছেন POST।

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

শেষ অবধি, আপনি যে ক্রিয়াটি সম্পাদন করতে চান তা অবিলম্বে সফল হওয়ার আশা করা যায় কিনা তা নির্ধারণ করুন। বার্কডগ একটি দ্রুত সমাপ্ত ক্রিয়া। রানমারাথন নেই। যদি আপনার ক্রিয়াটি ধীর গতিতে 202 Acceptedথাকে তবে ক্রিয়াটি সম্পূর্ণ হয়েছে কিনা তা দেখার জন্য কোনও ব্যবহারকারীকে পোল দেওয়ার জন্য প্রতিক্রিয়া সংস্থার URL সহ একটি ফেরত বিবেচনা করুন । বিকল্পভাবে, ব্যবহারকারীদের একটি তালিকার মতো ইউআরএল পোস্ট করুন /marathons-in-progress/এবং তারপরে যখন ক্রিয়াটি করা হয়, তখন তাদের অগ্রগতি আইডি URL থেকে URL এ পুনঃনির্দেশ করুন /marathons-complete/।
সুনির্দিষ্ট ক্ষেত্রে # 1 এবং # 2 এর জন্য, আমার কাছে সার্ভারটি একটি সারি হোস্ট করবে এবং ক্লায়েন্টটি এতে ঠিকানাগুলির ব্যাচ পোস্ট করবে। ক্রিয়াটি সেন্ডইমেলস নয়, তবে অ্যাডটোডিসপ্যাচকিউয়ের মতো কিছু। সার্ভারটি সেখানে কোনও ইমেল ঠিকানা অপেক্ষা করছে কিনা তা দেখার জন্য কাতারে পোল করতে পারে এবং ইমেলগুলি যদি এটি খুঁজে পায় তবে তা প্রেরণ করতে পারে। এরপরে এটি মুলতুবি আপডেট করে ইঙ্গিত দেয় যে মুলতুবি থাকা কর্মটি এখন সম্পাদিত হয়েছে। আপনার কাছে আরও একটি ইউআরআই আছে যা ক্লায়েন্টকে সারির বর্তমান অবস্থা দেখাচ্ছে। ইমেলগুলি দ্বিগুণ প্রেরণ এড়ানোর জন্য, সার্ভারটি এই ইমেলটি কার কাছে পাঠিয়েছে তার একটি লগ রাখতে পারে এবং প্রতিটি ঠিকানায় এটি একই ঠিকানাতে দু'বার প্রেরণ করে না তা নিশ্চিত করার জন্য প্রতিটি ঠিকানা পরীক্ষা করে রাখতে পারে, এমনকি আপনি একই তালিকাটিতে দু'বার পোস্ট করেছেন এমনকি to কিউ।

কোনও কিছুর জন্য ইউআরআই চয়ন করার সময়, এটি কোনও ক্রিয়া নয়, ফলস্বরূপ এটি ভাবার চেষ্টা করুন। উদাহরণস্বরূপ "কুকুর" শব্দটির সন্ধানের ফলাফলগুলিgoogle.com/search?q=dogs দেখায় । এটি অনুসন্ধান করার প্রয়োজন হয় না।

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

— নিকোলাস শ্যাঙ্কস
সূত্র
আসুন বলি যে পদক্ষেপটি একটি বিশাল ইমেল সারির মাধ্যমে মন্থন করা এবং একগুচ্ছ লোককে একটি বার্তা প্রেরণ করা। এটা কি আদর্শবান? পুট বা পোষ্টের জন্য আদর্শ পদক্ষেপগুলি কী?
— ওউইমেট
@ কির্ক আমি আমার উত্তরটি প্রসারিত করেছি।
— নিকোলাস শ্যাঙ্কস
0

আমার নতুন উত্তরটি দেখুন - এটির সাথে একটিটির বিরোধিতা করে এবং REST এবং এইচটিটিপি আরও স্পষ্ট এবং নির্ভুলভাবে ব্যাখ্যা করে।

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

POST /v1/dogs/1/bark-schedule HTTP/1.1
...
{"token": 12345, "next": 0, "frequency": 10}

token এটি একটি স্বেচ্ছাসেবী সংখ্যা যা এই অনুরোধটি যতবারই প্রেরণ করা হয় তা অনর্থক ছালাকে প্রতিরোধ করে।

nextপরবর্তী ছালের সময়কে নির্দেশ করে; 0'ASAP' এর অর্থ একটি মান ।

যখনই আপনি GET /v1/dogs/1/bark-schedule, আপনি ভালো কিছু পাওয়া উচিত, যেখানে T গত বাকল সময় এবং তোমার দর্শন লগ করা হয় T + + 10 মিনিট:

{"last": t, "next": u}

আমি আপনাকে সুপারিশ করছি যে কুকুরের বর্তমানের দৌড়ঝাঁপ অবস্থা সম্পর্কে জানতে আপনি যে ছালটি ব্যবহার করেন তা অনুরোধ করার জন্য একই URL টি ব্যবহার করুন। এটি বিশ্রামের পক্ষে অত্যাবশ্যক নয়, তবে সময়সূচীটি সংশোধন করার বিষয়টিতে এটি জোর দেয়।

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

ব্যাখ্যা

বিশ্রাম

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

ধরা যাক আর একটি কুকুর। আপনি আর হিসাবে চিহ্নিত করতে হবে /v1/dogs/1। (অর্থাত /v1/dogs/1একজন সদস্য আর ।) যে শুধু অনেক উপায়ে আপনি সনাক্ত করতে পারেন এক আর । আপনি আর হিসাবে /v1/dogs/1/x-raysএবং হিসাবে সনাক্ত করতে পারে /v1/rufus।

আপনি আর কে উপস্থাপন করবেন ? একটি ছবি সহ হতে পারে। এক্স-রেয়ের সেট দিয়েও হতে পারে। অথবা হয়ত তারিখ এবং সময় একটি ইঙ্গিত যখন আর গত barked। তবে মনে রাখবেন যে এগুলি সমস্ত একই উত্সের উপস্থাপনা । /v1/dogs/1/x-raysএকই সংস্থানটির একটি সনাক্তকারী যা প্রশ্নের উত্তর দিয়ে প্রতিনিধিত্ব করা হয় " আর শেষ বার্কটি কখন ছড়িয়েছিল?"

HTTP- র

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

কমপক্ষে, এটি কি GETকরে। PUTমূলত বিপরীত হয় GETআপনি: PUTএকটি উপস্থাপনা R যদি আপনি ভবিষ্যতে কামনা URL- এ GETযে URL অনুরোধ ফিরতে দ , HTML এ তাদেরকে JSON মত কিছু সম্ভব অনুবাদের সঙ্গে।

POSTউপস্থাপনা পরিবর্তন করার একটি আলগা উপায়। ডিসপ্লে লজিক এবং মডিফিকেশন লজিক রয়েছে যা একে অপরের প্রতিযোগী - উভয়ই একই ইউআরএলের সাথে সম্পর্কিত Think পোস্টটি অনুরোধ হ'ল পরিষেবাটি যথাযথ দেখায় তথ্য প্রক্রিয়াকরণ করতে এবং কোনও উপস্থাপনা (একই ইউআরএল দ্বারা চিহ্নিত প্রতিনিধিত্ব কেবল নয়) পরিবর্তনের জন্য যুক্তিযুক্ত যুক্তিটির অনুরোধ। 9.6 পুটের পরে তৃতীয় অনুচ্ছেদে মনোযোগ দিন : আপনি URL এ জিনিসটি নতুন সামগ্রী দিয়ে প্রতিস্থাপন করছেন না; আপনি কিছু তথ্য প্রক্রিয়া করতে এবং তথ্যবহুল উপস্থাপনের আকারে বুদ্ধিদীপ্তভাবে প্রতিক্রিয়া জানাতে URL এ জিনিসটি জিজ্ঞাসা করছেন।

আমাদের ক্ষেত্রে, আমরা আমাদের সংশোধন যুক্তিকে /v1/dogs/1/bark-schedule(এটি প্রদর্শন যুক্তির প্রতিপক্ষ যা আমাদের জানায় এটি কখন শেষ হয়েছিল এবং কখন এটি ছালবে) আমাদের তথ্য প্রক্রিয়া করতে এবং সেই অনুসারে কিছু উপস্থাপনা পরিবর্তন করতে বলি। ভবিষ্যতের প্রতিক্রিয়া হিসাবে GET, একই ইউআরএলের সাথে সম্পর্কিত ডিসপ্লে লজিক আমাদের বলবে যে কুকুরটি এখন আমাদের ইচ্ছামতো ঝাঁকুনি দিচ্ছে।

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

— জর্ডন
সূত্র
-1

আরআরইএসটি একটি রিসোর্স ওরিয়েন্টেড স্ট্যান্ডার্ড, এটি আরপিসি হিসাবে চালিত কোনও পদক্ষেপ নয়।

আপনি যদি চান যে আপনার সার্ভারটি বার্ক করে , আপনার বিভিন্ন মতামত যেমন JSON-RPC , বা ওয়েবসকেট যোগাযোগের মধ্যে নেওয়া উচিত।

এটিকে রেস্টস্টুল রাখার প্রতিটি চেষ্টা আমার মতে ব্যর্থ হবে: আপনি প্যারামিটার POSTদিয়ে একটি ইস্যু করতে পারবেন action, আপনি কোনও নতুন সংস্থান তৈরি করছেন না তবে আপনার পার্শ্ব প্রতিক্রিয়া থাকতে পারে, তাই আপনি নিরাপদ।

— moonwave99
সূত্র
POST জন্য ডিজাইন করা হয়েছিল "ডেটা-হ্যান্ডলিং প্রক্রিয়াতে ... একটি ব্লক ডেটা সরবরাহ "। মনে হয় প্রচুর ভাবেন লোকেরা ক্রিয়াকলাপ থেকে সংস্থানকে পৃথক করে তবে সত্যই ক্রিয়াগুলি কেবল এক ধরণের সংস্থান। সার্ভারে অ্যাকশন রিসোর্সকে কল করা এখনও একটি অভিন্ন ইন্টারফেস, ক্যাশেবল, মডিউলার এবং স্কেলযোগ্য। এটি রাষ্ট্রহীনও, তবে ক্লায়েন্ট কোনও প্রতিক্রিয়া আশা করার জন্য ডিজাইন করা থাকলে তা লঙ্ঘন হতে পারে। তবে সার্ভারে একটি "অকার্যকর পদ্ধতি" কল করা রয় ফিল্ডিং আরএসটি-র সাথে ।
— জ্যাকব স্টিভেন্স
আমি আমার উত্তরে যেমন বর্ণনা করেছি , আপনি অবধি স্পষ্টভাবে সার্ভারকে এটি বলার অনুরোধ করে একটি ক্রিয়া সম্পাদন করতে পারেন, এখন থেকে "আপনার ক্রিয়াটি সম্পন্ন হয়েছে", আরপিসি কেবল সার্ভারকে সম্পাদন করতে বলার ধারণার উপর ভিত্তি করে কর্ম। উভয়ই নিখুঁত জ্ঞান তৈরি করে, যেমন অপরিহার্য এবং ঘোষিত প্রোগ্রামিং উভয়ই বোধগম্য হয়।
— জর্দান
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.