রেস্ট এবং হেটোয়াস কি ওয়েব পরিষেবার জন্য একটি ভাল আর্কিটেকচার?


15

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

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

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


2
যেহেতু ওয়েবটি HTTP ব্যবহারের উপর ভিত্তি করে, এবং REST হল HTTP, তাই আমি মনে করি এটি ব্যবহারের জন্য একটি দুর্দান্ত জিনিস।
রব

1
@ রব: এইচটিটিপি-র চেয়ে বেশি বিশ্রাম দিন। উদাহরণস্বরূপ SOAP এবং এক্সএমএল-আরপিসি এইচটিটিপি ব্যবহার করে তবে বিশ্রামের সাথে মানায় না।
জ্যাকসবি

দুটিই আরএসটি আর্কিটেকচারের ভিত্তিতে নয়। সুতরাং পার্থক্য।
রব

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

এটি অনেক কিছুর উপর নির্ভর করে। এগুলির সবগুলিই প্রযুক্তিগত সমস্যা নয়। প্রবেশন জড়িত এবং কার্যকর করার বিষয়টি জড়িত context
লাইভ

উত্তর:


15

আফাইক ফিল্ডিং দাবি করেনি REST কোনও ভাল ছিল, তিনি কেবল ওয়েবটির ডি-ফ্যাক্টো আর্কিটেকচারের বর্ণনা দিচ্ছিলেন।

এটি কিছুটা আন্ডারলাইস করে, আমি ভাবব। REST, সর্বোপরি, স্থাপত্য শৈলীর একটি গণনা যা ফিল্ডিং এইচটিটিপি / ১.১ অনুমানের প্রধান স্থপতি হিসাবে ব্যবহার করছিল

তবে আসলেই এই ডোমেনটির জন্য REST একটি কাঙ্ক্ষিত স্থাপত্য হিসাবে ভাবার কোনও কারণ আছে? মেশিন-টু-মেশিন যোগাযোগের জন্য HATEOAS একটি উপকারী ডিজাইনের নীতি বলে কোন প্রমাণ রয়েছে কি?

"এটা নির্ভর করে". HATEOAS REST এর অভিন্ন ইন্টারফেস সীমাবদ্ধতার অংশ of

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

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

এটা ঠিক কাজ করে

এটি অবশ্যই সর্বজনীন নয়। ফিল্ডিং, ২০০৮ সালে লিখেছেন:

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

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

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

মেশিন পাঠযোগ্য পাঠ্য শব্দভাণ্ডার তৈরির চেষ্টার একটি অংশ স্কিমা.অর্গ ; মেশিন এজেন্টরা ক্লায়েন্টকে শব্দার্থক ইঙ্গিতগুলি খুঁজে পেতে ব্যবহার করে এবং সঠিক ক্রিয়াগুলি গ্রহণ করতে বেছে নিতে অর্থটির নিজস্ব বোঝার প্রয়োগ করে।

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

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


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

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

6

না, 'পূর্ণ REST' তেমন দুর্দান্ত নয়।

যারা তৃতীয় এপিআইগুলিতে HATEOS বাস্তবায়িত করে এবং এমন কোনও অন্তর্নিহিত যুক্তি দ্বারা কোনও HTTP জন্য কোন HTTP ক্রিয়াকলাপ ব্যবহার করা উচিত তার অন্তর্ভুক্তির প্রমাণ হিসাবে।

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

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

তারপরে দ্বিতীয় সমস্যাটি ছিল এক্সএমএল, জাভাস্ক্রিপ্ট এটি বুঝতে পারল না, স্কিমার গাধাটির মধ্যে ব্যথা ছিল এবং আপনি বেশিরভাগ টিএসটিএইচ ফাইল দিয়ে শেষ করবেন <MyLongObjectName>। সুতরাং লোকেরা পরিবর্তে জেএসএন ব্যবহার শুরু করে।

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


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

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

2
আমি মনে করি REST সম্পর্কে কথা বলার সময় আমাদের মানকটি কী এবং লোকেরা বাস্তবে কী বাস্তবায়ন করে তা উভয়কেই চিনতে হবে এবং তারপরে 'রেস্ট' কল করুন
ইওয়ান

2

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

এমনকি রয় ফিল্ডিং আরআরটি-তে তাঁর গবেষণামূলক প্রবন্ধটি লেখার আগেই এইচটিটিপি ইতিমধ্যে নীতিগুলি তৈরি করা হয়েছিল যা পরে REST হিসাবে পরিচিতি লাভ করে। ইন অভিসন্দর্ভের শেষে তিনি লিখেছিলেন:

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

REST এবং HATEOS যে সমস্যার জন্য ডিজাইন করা হয়েছিল তার জন্য এটি বেশ উপযুক্ত:

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

যাইহোক, এটি লক্ষ করা উচিত যে ওয়েব এবং REST প্রতিটি সমস্যার জন্য উপযুক্ত উপযুক্ত নয়:

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

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

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

তবে আসলেই এই ডোমেনটির জন্য REST একটি কাঙ্ক্ষিত স্থাপত্য হিসাবে ভাবার কোনও কারণ আছে? আরও সুনির্দিষ্টভাবে, এমন কোনও প্রমাণ আছে যা বলে যে হাটিয়োস মেশিন থেকে মেশিন যোগাযোগের জন্য একটি উপকারী ডিজাইনের নীতি?

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


2

অ্যাডোব অভিজ্ঞতা পরিচালককে ফিল্ডিংয়ের উপস্থাপনায়:

REST কোনও স্থাপত্য নয়!

বিশ্রাম একটি স্থাপত্য শৈলী, যা ইন্টারনেটে বিদ্যমান বিভিন্ন স্থাপত্যের বিমূর্ততা।

আরআরইএসটি হ'ল স্থাপত্য বৈশিষ্ট্যগুলিকে প্ররোচিত করতে নকশার সীমাবদ্ধতার একটি সংचय

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

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

এমইএম এ বিশ্রাম দিন


0

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


1
জেএসএন কেন এক্সএমএল থেকে নিকৃষ্ট?
মালকি.কিড

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