REST বনাম JSON-RPC? [বন্ধ]

251

বন্ধ । এই প্রশ্নটি মতামত ভিত্তিক । এটি বর্তমানে উত্তর গ্রহণ করছে না।

এই প্রশ্নটি উন্নত করতে চান? প্রশ্নটি আপডেট করুন যাতে পোস্টটি সম্পাদনা করে সত্য এবং উদ্ধৃতি দিয়ে উত্তর দেওয়া যায় ।

8 মাস আগে বন্ধ ছিল ।

এই প্রশ্নটি উন্নত করুন

ওয়েব অ্যাপ্লিকেশনের জন্য একটি এপিআই বিকাশের জন্য আমি আরইএসটি এবং জেএসএন-আরপিসির মধ্যে নির্বাচন করার চেষ্টা করছি। তারা কীভাবে তুলনা করবে?

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

rest rpc json-rpc

— আলী শাকিবা
সূত্র

29

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

— ল্যান্ডন পোচ

27

JSON-RPC সহজ এবং সামঞ্জস্যপূর্ণ, ব্যবহার করার জন্য একটি আনন্দ।

— dnault

1

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

— মনোহর রেড্ডি পোরেডি

6

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

— স্ট্যাথিস অ্যান্ড্রোনিকোস 28:11

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

— আলী শাকিবা

221

আরপিসির মূল সমস্যাটি হচ্ছে সংমিশ্রণ। আরপিসি ক্লায়েন্টরা বেশ কয়েকটি উপায়ে পরিষেবা বাস্তবায়নের জন্য দৃly়ভাবে মিলিত হয় এবং ক্লায়েন্টকে না ভেঙে পরিষেবা বাস্তবায়ন পরিবর্তন করা খুব কঠিন হয়ে পড়ে:

পদ্ধতিগুলির নাম জানতে ক্লায়েন্টদের প্রয়োজন;
পদ্ধতি প্যারামিটারগুলি অর্ডার, প্রকার এবং গণনা সম্পর্কিত বিষয়গুলি। ক্লায়েন্ট বাস্তবায়ন ভঙ্গ না করে সার্ভার সাইডে প্রক্রিয়া স্বাক্ষরগুলি (আর্গুমেন্টের সংখ্যা, আর্গুমেন্টের ক্রম, যুক্তির ধরণের ইত্যাদি ...) পরিবর্তন করা এত সহজ নয়;
আরপিসি শৈলী প্রক্রিয়া সমাপ্তি + প্রক্রিয়া যুক্তি ছাড়া কিছুই প্রকাশ করে না exp ক্লায়েন্টের পক্ষে পরবর্তী কী করা যায় তা নির্ধারণ করা অসম্ভব।

অন্যদিকে REST শৈলীতে উপস্থাপনাগুলিতে নিয়ন্ত্রণ সম্পর্কিত তথ্য (HTTP শিরোনাম + উপস্থাপনা) অন্তর্ভুক্ত করে ক্লায়েন্টদের গাইড করা খুব সহজ। উদাহরণ স্বরূপ:

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

বিশ্রামের দিকে আরও অনেক পার্থক্য এবং সুবিধা রয়েছে।

— ioseb
সূত্র

20

"লিঙ্ক রিলেশন টাইপগুলি যার সাথে অর্থ বোঝায় তা লিখিতগুলি এম্বেড করা বাধ্যতামূলক" বলতে কী বোঝায়? "?

— pjz

129

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

— সেঞ্চুরিয়ান

44

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

— সেঞ্চুরিয়ান

64

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

— সেঞ্চুরিয়ান

15

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

— সেঞ্চুরিয়ান

163

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

আপনি আরপিসির বিষয়ে সিদ্ধান্ত নিলে একমাত্র পার্থক্য হ'ল আপনি স্পষ্টভাবে ইউআরআই এর অংশ হিসাবে ক্রিয়াটি নির্দিষ্ট করে দিচ্ছেন, যা পরিষ্কার, ধারাবাহিক, কম বগি, এবং সত্যিই কোনও সমস্যা নয়। বিশেষত আপনি যদি এমন একটি অ্যাপ তৈরি করেন যা সাধারণ সিআরইউডি ছাড়িয়ে যায়, আরপিসি হ'ল একমাত্র উপায়। RESTful purists এর সাথে আমার আর একটি সমস্যা রয়েছে: HTTP পোষ্ট, GET, পুট, ডিলিটের এইচটিটিপিতে সুনির্দিষ্ট অর্থ রয়েছে যা REST দ্বারা অন্য অর্থগুলিতে রূপান্তরিত হয়েছে, কেবল কারণ তারা বেশিরভাগ সময় ফিট করে - তবে সমস্ত সময় নয়।

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

— ব্রুস প্যাটিন
সূত্র

30

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

— নেপদেব

68

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

— ব্রুস প্যাটিন

4

সুতরাং @ ব্রুসপ্যাটিন, আপনার সংস্করণ "REST" তে আপনার চারটি সার্বজনীন পদ্ধতি সহ একটি নিয়ামক রয়েছে যা GET | পুট | পোস্ট | মুছে ফেলতে 1 থেকে 1 ম্যাপ করে? কিছু ফ্রেমওয়ার্কগুলি এটি করে তবে এটি বিশ্রাম নয়। এইচটিটিপি ক্রিয়াগুলি প্রদত্ত অনুরোধের শব্দার্থক সম্পর্কে অস্পষ্ট বিমূর্ত ধারণা তৈরি করে। আপনাকে সেই ক্লাসগুলিতে আপনার শেষ পয়েন্টগুলি যথাযথভাবে ম্যাপ করতে হবে। জিইটি বিভিন্ন প্রান্তের মানচিত্র করতে পারে, অন্যরাও পারে। বাস্তবে কোনও কারণ নেই যে আপনি HTTP- র মাধ্যমে REST -ULL JSON-RPC প্রয়োগ করতে পারবেন না।

— স্পিঙ্কাস

5

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

— ব্রুস প্যাটিন

22

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

— চটপটে জেদী 22'15

29

প্রথমত, HTTP-REST হ'ল "প্রতিনিধিত্বমূলক রাষ্ট্র স্থানান্তর" আর্কিটেকচার। এটি অনেকগুলি আকর্ষণীয় জিনিস বোঝায়:

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

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

তবে শেষ কথা নয়, এইচটিটিপি কে আরপিসি প্রোটোকল হিসাবে ব্যবহার করা এইচটিটিপি ১.১ এর ডিজাইনার (এবং আরইএসটি-র উদ্ভাবক) অনুসারে একটি বিশাল ত্রুটি: http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation। পেজটি # sec_6_5_2

— Aurélien
সূত্র

1

প্রামাণিক, লোক-কে-জানা উচিত রেফারেন্সের জন্য +1 .... এইচটিটিপি নিয়ে

— আরপিসির

9

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

— চটজলদি জেদী

অরলিয়েন, আপনি কি ন্যায়সঙ্গত প্রমাণ করতে পারেন, স্বাধীন সফ্টওয়্যার অংশগুলির সাথে কেন বিশ্রাম নেওয়া সহজ? আমার কাছে, আপনি RESTful API বা RPC ব্যবহার না করেই, ক্লায়েন্ট সফ্টওয়্যারটির আপনার এপিআই কথা বলে ফর্ম্যাটটি জানতে হবে।

— আলেক্সি

1

@ আলেক্সি এই যুক্তি রাষ্ট্রহীনতার সাথে আপেক্ষিক ছিল। এটা একটা কফি মেশিন যার এপিআই সংহত করার সহজ CREATE CUP, অন্য যেগুলিতে হবে চেয়ে INSERT COIN, SELECT COFFEE, SELECT SUGAR, এবং START। দ্বিতীয় এপিআইতে, কারণ এটি মেশিনের অবস্থার উপর নির্ভর করে, আপনাকে প্রক্রিয়া কলগুলির ক্রমগুলির সাথে খুব সতর্কতা অবলম্বন করতে হবে।

— অরুলিয়ান

1

আরপিসি প্রোটোকল হিসাবে এইচটিটিপি হ'ল রিস্ট। সুতরাং আপনার ভুল ব্যাখ্যাটি অন্যরকমভাবে হতবাকভাবে is

— টিবেরিউ-আয়নু স্টান

24

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

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

এটি আপনাকে নতুন সামগ্রীর ধরণের বা ক্লায়েন্টের প্রয়োজনীয়তা সমর্থন করার জন্য আপনার এপিআইকে যথেষ্ট নমনীয় রাখতে দেয়।

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

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

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

সাধারণভাবে, আমি বলব যে আপনি দীর্ঘস্থায়ী হবে এমন একটি এক্সটেনসিবল, নমনীয় এপিআই বানাতে চাইলে REST হ'ল উপায়। যে কারণে, আমি বলব এটি সময়ের 99% যাওয়ার পথ।

শুভকামনা, মাইক

— মাইক স্টো
সূত্র

3

এটি সামান্য কঠিন নয়, বরং অত্যন্ত বেশি কঠিন। আমি এটি 4 মাস বা তার বেশি সময় ধরে বোঝার চেষ্টা করেছি, এবং এখনও কোনও পরিষেবা কীভাবে লিখতে হবে তার জন্য একটি ভাল হ্যান্ডেল নেই যা জেসসন ব্যবহার করে HTTP- র মাধ্যমে রাষ্ট্রবিহীন আরপিসিতে বিভক্ত হয় না, এবং আমি এখনও নিশ্চিত নই "REST" এবং আমি যা বলেছিলাম তার মধ্যে একটি সত্য পার্থক্য আছে

— অস্টিন_এন্ডারসন

19

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

নিঃসন্দেহে আরইএসটি আরও জনপ্রিয়, এটি যদি আপনি কোনও তৃতীয় পক্ষের কাছে প্রকাশ করতে চান তবে এটি অবশ্যই কিছু পয়েন্ট যুক্ত করবে।

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

জেএসএন-আরপিসি একটি সাধারণ এবং মার্জিত স্পেসিফিকেশন যা সিঙ্ক্রোনাস বা অ্যাসিঙ্ক্রোনাস আরপিসিতে ব্যবহারের জন্য অনুরোধ এবং প্রতিক্রিয়া জেএসএন পে-লোড সংজ্ঞা দেয়।

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

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

এখন অবধি এটি সম্পর্কে আমার ব্যক্তিগত মতামত খুব বেশি, তবে এখন যা কিছু এই জাভা বিকাশকারীদের এই লাইনগুলি পড়ার জন্য সত্যই সহায়ক হতে পারে, গত বছরের সময়কালে আমি যে কাঠামোর উপর কাজ করেছিলাম, একই প্রশ্ন থেকে জন্ম নিয়ে আপনি এখন ভাবছেন? :

http://rpc.brutusin.org

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

http://demo.rpc.brutusin.org

আশা করি এটি সাথিকে সাহায্য করবে!

nacho

— idelvall
সূত্র

একটি আত্মীয় আত্মা খুঁজে পাওয়া দুর্দান্ত! আমি এখানেও অনুরূপ কিছু নিয়ে কাজ করছি: github.com/dnault/therapi-json-rpc

— dnault

:) আমি এটি সন্ধান করব

— idelvall

1

এর সাথে একমত আপনার স্পষ্ট পোষ্ট / জিইটি / পুট / ডিলেট / পিওজিপিডি হওয়ায় আরআরইএসটি CRUD এপিআইয়ের জন্য ভাল কাজ করে? ;)] ম্যাপিং. যাইহোক, যদি আপনার এপিআই নেই সেই ক্রিয়ার মধ্যে আরামে মাপসই, JSON-RPC একটি ভাল বিকল্প হতে পারে যেহেতু ক্রিয়া মাত্র দ্বিধায় পরে বিষয়গুলো করতে যাচ্ছি। হ্যাঁ, এটি কে ব্যবহার করছে এবং কেন এটি একটি বড় কারণ।

— অ্যালজি টেলর

1

ঠিক - REST হ'ল বিশেষ্যগুলির রাজ্য, JSON-RPC ক্রিয়াপদ।

— রব গ্রান্ট

16

যদি আপনার পরিষেবাটি কেবলমাত্র মডেল এবং GET / POST / PUT / DELETE প্যাটার্ন দিয়ে ভাল কাজ করে তবে বিশুদ্ধ REST ব্যবহার করুন।

আমি সম্মত হই যে এইচটিটিপি মূলত রাষ্ট্রবিহীন অ্যাপ্লিকেশনগুলির জন্য ডিজাইন করা হয়েছে।

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

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

যেমন আপনি কেবল সার্ভার সাইড এপিআই ডিজাইন করছেন, আরইএসটি মডেলগুলি সংজ্ঞায়িত করে শুরু করুন এবং পরে প্রয়োজন অনুযায়ী জেএসওএন-আরপিসি সমর্থন যুক্ত করুন, আরপিসি কলগুলির সংখ্যা সর্বনিম্ন রেখে to

(এবং প্রথম বন্ধনী অতিরিক্ত ব্যবহারের জন্য দুঃখিত)

— cbix
সূত্র

15

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

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

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

এই কারণে, আরপিসি আমার কাছে আজ অনেক সহজ এবং প্রাকৃতিক বোধ করে। যদিও আমি সত্যিই মিস করছি তা একটি ধারাবাহিক কাঠামো যা RPC পরিষেবাগুলি স্ব-বর্ণনামূলক এবং আন্তঃব্যক্তিকরূপে লিখতে সহজ করে তোলে। অতএব আমি নিজের জন্য আরপিসি সহজতর করার জন্য নতুন উপায়ে পরীক্ষা করার জন্য আমার নিজস্ব প্রকল্প তৈরি করেছি এবং অন্য কারও কাছে এটি দরকারীও বলে মনে হয়েছে: https://github.com/aheck/reflectrpc

— Ahe
সূত্র

ওপেনআরপিসি পরীক্ষা করে দেখুন, "স্ব-বর্ণনামূলক এবং আন্তঃব্যবহারযোগ্য আরপিসি পরিষেবাগুলি সহজেই লেখার জন্য" আপনার প্রয়োজনীয়তার সমাধান করা উচিত

— বেলফোর্ডজ

11

রিচার্ডসন পরিপক্কতা মডেল অনুসারে , প্রশ্নটি আরইএসটি বনাম আরপিসি নয় , তবে আরএসইএসটি কত ?

এই দৃষ্টিতে, আরইএসটি স্ট্যান্ডার্ডের সম্মতি 4 স্তরে শ্রেণিবদ্ধ করা যেতে পারে।

স্তর 0: ক্রিয়া এবং পরামিতিগুলির শর্তাবলী বিবেচনা করুন। নিবন্ধটি যেমন ব্যাখ্যা করে, এটি মূলত জেএসওএন-আরপিসির সমতুল্য (নিবন্ধটি এটি এক্সএমএল-আরপিসির জন্য ব্যাখ্যা করে, তবে একই যুক্তি উভয়ের পক্ষে রয়েছে)।
স্তর 1: সংস্থান সম্পর্কে বিবেচনা করুন। কোনও উত্সের সাথে প্রাসঙ্গিক সবকিছু একই URL এর অন্তর্গত
স্তর 2: HTTP ক্রিয়া ব্যবহার করুন
স্তর 3: HATEOAS

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

— blue_note
সূত্র

1

0, 1 এবং 2 স্তরের জন্য +1 যাইহোক আমি কখনও HATEOS এর সফল বাস্তবায়ন দেখিনি, তবে দুটি মারাত্মক ব্যর্থ প্রচেষ্টা দেখেছি।

— mjhm

8

কেন JSON আরপিসি:

আরএসটি এপিআইয়ের ক্ষেত্রে, আমাদের প্রয়োজন প্রতিটি কার্যকারিতা / পদ্ধতির জন্য আমাদের একটি নিয়ামক নির্ধারণ করতে হবে। ফলস্বরূপ যদি আমাদের কাছে 10 টি পদ্ধতি থাকে যা আমরা ক্লায়েন্টের কাছে অ্যাক্সেসযোগ্য চাই, আমাদের ক্লায়েন্টের অনুরোধটিকে একটি নির্দিষ্ট পদ্ধতিতে ইন্টারফেস করতে 10 টি নিয়ামক লিখতে হবে।

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

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

সার্ভার ক্লায়েন্টের কাছে প্রকাশ করতে চায় এমন বিভিন্ন পদ্ধতি / ক্রিয়াকলাপগুলির জন্য আলাদা আলাদা নিয়ামক তৈরি করতে হবে না।

বিশ্রাম কেন:

সার্ভারের ক্লায়েন্টের পক্ষ থেকে এক্সপোজ করতে চায় এমন বিভিন্ন কার্যকারিতার জন্য আপনার পৃথক URL আছে s ফলস্বরূপ, আপনি এই url এম্বেড করতে পারেন।

এই পয়েন্টগুলির বেশিরভাগ বিতর্কযোগ্য এবং সম্পূর্ণরূপে একজন ব্যক্তির প্রয়োজনের উপর নির্ভর করে।

— উমর ফারুক
সূত্র

3

আমি মনে করি, বরাবরের মতো এটি নির্ভর করে ...

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

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

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

একটি মাঝারি জটিল সাইটের জন্য সোয়াগার / ওপেনপিআই ফাইল তৈরি করার চেষ্টা করুন এবং এটি একটি একক জাভা ইন্টারফেসের সাথে তুলনা করুন যা সেই ফাইলের দূরবর্তী প্রক্রিয়াগুলি বর্ণনা করে। জটিলতা বৃদ্ধি বিস্ময়কর।

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

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

— পিটার ক্রিয়েন্স
সূত্র

1

এই উত্তরটি আমাকে গ্রাফকিউএল এবং জেএসওন-আরপিসির মধ্যে মিল খুঁজে পেয়েছিল এবং গ্রাফকিউএল এসপিএগুলির জন্য কেন একটি জনপ্রিয় পছন্দ হয়ে উঠছে realize

— ডেনিস

ওপেনআরপিসি ওপেনপিআই / সোয়াগারের সমতুল্য, তবে

— জেএসএন

1

REST টি এইচটিটিপি এর সাথে দৃ tight়ভাবে একত্রিত, সুতরাং আপনি যদি কেবলমাত্র এইচটিটিপি-র মাধ্যমে আপনার এপিআই প্রকাশ করেন তবে বেশিরভাগ (তবে সমস্ত নয়) পরিস্থিতির জন্য REST আরও উপযুক্ত। তবে, যদি আপনাকে অন্য ট্রান্সপোর্টের মতো বার্তা বা ওয়েব সকেটের উপরে আপনার API প্রকাশ করতে হয় তবে কেবলমাত্র REST প্রযোজ্য নয়।

— dtoux
সূত্র

2

REST হ'ল একটি স্থাপত্য শৈলী এবং প্রোটোকল নির্ভর নয়।

— মার্ক সিডেড

4

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

— dtoux

1

বুঝতে সহজতর যে ওয়েব অ্যাপ্লিকেশনটির জন্য একটি API বিকাশ করতে REST এবং JSON-RPC এর মধ্যে JSON-RPC চয়ন করা ভাল। জেএসএন-আরপিসি পছন্দ করা হয় কারণ এর পদ্ধতি কল এবং যোগাযোগগুলিতে এর ম্যাপিংটি সহজেই বোঝা যায়।

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

আসলে যা JSON-RPC থেকে REST কে বিভক্ত করে তোলে তা হ'ল এটি যত্ন সহকারে চিন্তাভাবনাগুলির একটি সিরিজ অনুসরণ করে - স্থাপত্যের নমনীয়তার নিশ্চয়তা দেয়। সীমাবদ্ধতাগুলি নিশ্চিত করে যে ক্লায়েন্ট পাশাপাশি সার্ভার একে অপরের থেকে স্বাধীনভাবে বৃদ্ধি পেতে সক্ষম হয়েছে (ক্লায়েন্টের প্রয়োগের সাথে গোলযোগ ছাড়াই পরিবর্তনগুলি করা যেতে পারে), কলগুলি স্টেটহীন (রাষ্ট্রকে হাইপারমিডিয়া হিসাবে বিবেচনা করা হয়), একটি ইউনিফর্ম ইন্টারফেস ইন্টারঅ্যাকশন জন্য উপলব্ধ করা হয়, API একটি স্তরযুক্ত সিস্টেম (হল, 2010) এ উন্নত। জেএসএন-আরপিসি দ্রুত এবং সহজেই গ্রাস করা সহজ, তবে উল্লিখিত সংস্থানগুলি পাশাপাশি পরামিতিগুলি শক্তভাবে একত্রিত হয়েছে এবং এটি জিইটি / পোস্ট ব্যবহার করে ক্রিয়া (অ্যাপিআই / অ্যাডউজার, এপিআই / ডিলিটউজার) এর উপর নির্ভর করবে যেখানে আরইএসটি আলগাভাবে সংযুক্ত সংস্থানগুলি সরবরাহ করে (এপিআই) / ব্যবহারকারীগণ) একটি HTTP এ। REST এআইপিটি বেশ কয়েকটি HTTP পদ্ধতি যেমন GET, PUT, POST, DELETE, PATCH এর উপর নির্ভর করে।

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

— SinghKunal
সূত্র

"যন্ত্রগুলি পার্স করা ঝামেলা মুক্ত" - আমি প্রচুর ভাঙা জেএসওএন দেখেছি (উদাঃ

— পে

1

ভুল প্রশ্ন: একটি ম্যানিশিয়ান চাপিয়ে দেয় যা বিদ্যমান নেই!

আপনি JSON-RPC "কম ক্রিয়াপদ" (কোনও পদ্ধতি নয় ) দিয়ে ব্যবহার করতে পারেন এবং সেন্ডো আইডি, পরামিতি, ত্রুটি কোড এবং সতর্কতা বার্তাগুলির জন্য প্রয়োজনীয় ন্যূনতম মানকতা সংরক্ষণ করতে পারেন। জেএসএন-আরপিসি স্ট্যান্ডার্ডটি "আপনি বিশ্রাম নিতে পারবেন না" বলে না, কেবল মৌলিক তথ্য কীভাবে প্যাক করবেন তা বলুন।

"REST JSON-RPC" বিদ্যমান ! সহজ এবং কঠিন চুক্তি সহ ন্যূনতম তথ্য প্যাকিংয়ের জন্য, "সেরা অনুশীলনগুলি" সহ বিশ্রাম।

উদাহরণ

( এই উত্তর এবং তর্কাত্মক প্রসঙ্গ থেকে)

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

JSON অনুরোধের সাথে REST আমানত । JSON প্রতিক্রিয়া হিসাবে কিছু হতে পারেPOST /Bank/Account/John/Transaction{"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}
{"jsonrpc": "2.0", "result": "sucess", "id": 12}
বিশ্রাম প্রত্যাহার সঙ্গে POST /Bank/Account/John/Transaction... অনুরূপ।
... GET /Bank/Account/John/Transaction/12345@13... এটি সেই সঠিক লেনদেনের একটি JSON রেকর্ড ফিরিয়ে দিতে পারে (যেমন আপনার ব্যবহারকারীরা সাধারণত তাদের অ্যাকাউন্টে ডেবিট এবং ক্রেডিট রেকর্ড চান)। কিছু হিসাবে {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}। (আরইএসটি) জিইটি অনুরোধ সম্পর্কে কনভেনশনে "@id" দ্বারা আইডির এনকোড অন্তর্ভুক্ত থাকতে পারে, সুতরাং কোনও জেএসওএন প্রেরণের দরকার নেই, তবে এখনও প্রতিক্রিয়া প্যাকটিতে জেএসএন-আরপিসি ব্যবহার করছেন।

— পিটার ক্রাউস
সূত্র

এছাড়াও দেখুন স্ট্যাকওভারফ্লো.com

— পিটার ক্রাউস

0

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

— অ্যাড্রিয়ান লিউ
সূত্র

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

— বেলফোর্ডজ

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

— অ্যাড্রিয়ান লিউ

-1

আমি আরপিসি প্রোটোকলের জন্য vdata ব্যবহার করি: http://vdata.dekuan.org/

1, পিএইচপি এবং জাভাস্ক্রিপ্ট উভয়ই ঠিক আছে। 2, ক্রস-অরিজিন রিসোর্স শেয়ারিং (সিওআরএস) কল এখনও ঠিক আছে।

— লিউ কিক্সিং
সূত্র