আমাদের কেন রেস্টস্টুল ওয়েব পরিষেবাদি দরকার?


123

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

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

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

আমার কাছে মনে হয় যে REST হ'ল 'ফ্যাশনের শেষ শব্দ' (বা আমি পুরোপুরি ভুল হতে পারি কারণ আমি আরআরএসটি বাস্তবে কখনও দেখিনি)।

আপনি কি আমাকে কিছু উদাহরণ দিতে পারেন যা ছিল REST টি ব্যবহার করা উচিত এবং কেন আমরা REST ব্যতীত একই কাজ করতে পারি না (বা কেন REST না করে আমাদের আরও বেশি সময় ব্যয় করা উচিত)?

ইউপিডি : দুর্ভাগ্যক্রমে আমি এমন কোনও দৃ concrete যুক্তি দেখতে পাচ্ছি না যা প্রথম মন্তব্যে আমার মনকে উড়িয়ে দিতে পারে। আমাকে ভাবুন যে REST দুর্দান্ত প্রযুক্তি!

আমি এই মত উত্তর দেখতে চাই:

আমি আরেকটি জটিল হ্যালোওয়ার্ল্ড অ্যাপ্লিকেশন বিকাশ করছিলাম এবং আমাদের প্রচুর / ছোট তথ্য স্থানান্তর করতে হবে এবং আমি আমার সহকর্মীর কাছে REST সমাধান প্রস্তাব করেছি:

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


2
এটি কোনও দুর্দান্ত প্রযুক্তি নয় - এটি একটি ভিন্ন প্রযুক্তি। আপনি যদি কাউকে বোঝাতে চান যে এটি দুর্দান্ত and এবং এটি প্রতিবার ব্যবহার করা উচিত, তবে পরামর্শকের চেষ্টা করুন।
কুইলব্রেকার

উত্তর:


133

যদি বিতরণকৃত অ্যাপ্লিকেশনটিতে ক্লায়েন্ট এবং সার্ভারের উপাদানগুলির মধ্যে সংযুক্তি হ্রাস করা আপনার পক্ষে খুব গুরুত্বপূর্ণ হয় তবে REST ব্যবহার করা উচিত ।

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

আমি আপনাকে আশ্বস্ত করতে পারি যে এই নিম্ন স্তরের সংযোগের কাজটি করা সহজ নয় । সফল হওয়ার জন্য REST এর সমস্ত প্রতিবন্ধকতা অনুসরণ করা গুরুত্বপূর্ণ critical খাঁটি স্টেটলেস সংযোগ বজায় রাখা কঠিন। সঠিক মিডিয়া-ধরণের বাছাই করা এবং ফর্ম্যাটগুলিতে আপনার ডেটা সঙ্কুচিত করা জটিল। আপনার নিজস্ব মিডিয়া প্রকারগুলি তৈরি করা আরও শক্ত হতে পারে।

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

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

হাইপারমিডিয়া এবং সেশন রাষ্ট্রের এড়ানো উপকারিতা লোড ভারসাম্য সহজ এবং পরিষেবা বিভাজনকে সম্ভবপর করে তোলে । এইচটিটিপি বিধিগুলির কঠোরতা অনুসারে ডিবাগার এবং ক্যাশে প্রক্সিগুলির মতো সরঞ্জামগুলির সহজলভ্যতা তৈরি করে।

হালনাগাদ

আমার কাছে মনে হয় যে REST হ'ল 'ফ্যাশনের শেষ শব্দ' (বা আমি পুরোপুরি ভুল হতে পারি কারণ আমি আরআরএসটি বাস্তবে কখনও দেখিনি)।

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

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

  • কেউ যখন কোনও ওয়েব সাইটে কিছু এইচটিএমএল পরিবর্তন করে তবে আপনার ব্রাউজার আপডেট করার দরকার নেই কেন?
  • আমি কেন কোনও ওয়েবসাইটে পৃষ্ঠাগুলির সম্পূর্ণ নতুন সেট যুক্ত করতে পারি এবং "ক্লায়েন্ট" এখনও আপডেট ছাড়াই সেই নতুন পৃষ্ঠাগুলি অ্যাক্সেস করতে পারে?
  • Http://example.org/images/cat এ যাওয়ার সময় ওয়েব ব্রাউজারে এটি জানাতে আমার কেন একটি "পরিষেবা-বর্ণন-ভাষা" সরবরাহ করার প্রয়োজন হয় না যে রিটার্নের ধরণটি একটি জেপিগ চিত্র হবে এবং আপনি যখন যাবেন থেকে http://example.org/description/cat রিটার্ন টাইপ পাঠ্য / HTML হবে?
  • ব্রাউজারটি প্রকাশের সময় যখন বিদ্যমান ছিল না এমন সাইটগুলি দেখার জন্য কেন আমি একটি ওয়েব ব্রাউজার ব্যবহার করতে পারি? ক্লায়েন্ট কীভাবে এই সাইটগুলি সম্পর্কে জানতে পারে?

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

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

এগুলি কাজের স্থানে থাকা একটি আর্কিটেকচারের উদাহরণ।

এখন কিছু ওয়েব সাইট / অ্যাপ্লিকেশনগুলি আরএসটি-র বিধিগুলি ভঙ্গ করে এবং তারপরে ব্রাউজারটি প্রত্যাশার মতো কাজ করে না।

  • কুখ্যাত ব্যাক বোতাম সমস্যাটি সার্ভার সাইড সেশন স্থিতি ব্যবহারের কারণে ঘটে।
  • আপনার যখন সার্ভার সাইড সেশন স্থিতি থাকে তখন লোড ব্যালেন্সিং একটি ব্যথা হয়ে উঠতে পারে।
  • ফ্ল্যাশ অ্যাপ্লিকেশনগুলি প্রায়শই নির্দিষ্টভাবে একটি প্রতিনিধিত্ব সনাক্তকরণ থেকে URL টি প্রতিরোধ করে prevent
  • অন্যান্য সমস্যা যা ওয়েব ব্রাউজারগুলিকে ভেঙে দেয় তা হ'ল মিডিয়া ধরণের মানগুলির সাথে দুর্বলতা। কীভাবে আই 6 কে হত্যা করা দরকার সে সম্পর্কে আমরা সমস্ত সময় শুনি। সেখানে সমস্যাটি হ'ল মানগুলি যথাযথভাবে অনুসরণ করা হয়নি, বা যে কোনও কারণেই এড়ানো হয়নি।
  • লগইন সেশনগুলির ব্যবহার অনেকগুলি সুরক্ষা গর্তের উত্স।

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


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

4
@ জন সাধারণতঃ SOAP যেভাবে ব্যবহৃত হয় তা ক্লায়েন্টকে প্রতিটি সার্ভারের পাশের সমাপ্তি বিন্দু, প্রতিটি প্যারামিটার ডেটা টাইপ এবং প্রতিটি রিটার্নের ধরণের জ্ঞান "সংকলিত" করে তোলে। ক্লায়েন্ট এবং সার্ভারের মধ্যে ডেটা পাস করার জন্য মানকযুক্ত প্রকারের চেষ্টা ও ব্যবহার করার জন্য এসওএপি বিশ্বে কোনও গাইডেন্স নেই। এর অর্থ হ'ল ক্লায়েন্ট বিকাশকারী প্রতিটি নতুন পরিষেবা ব্যবহার করতে যায়, তার নিজস্ব প্রকারের, সেটপয়েন্টগুলি এবং মিথস্ক্রিয়া প্রোটোকলগুলির একটি অনন্য সেট রয়েছে। এটা মিলন।
ড্যারেল মিলার

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

@ ড্যারেল: এটি প্রচলিত অর্থে মিলিত হচ্ছে না। ক্লায়েন্টটি মেটাডেটার (ডাব্লুএসডিএল) "সংযুক্ত" হিসাবে বিবেচিত হতে পারে, তবে পরিষেবাতে নয়। এমন একটি পরিষেবা বিবেচনা করুন যা কোনও "কর্মচারী" দেয়: id আইডি; স্ট্রিং ফার্স্ট নেম, লাস্টনেম, স্ট্রিট অ্যাড্রেস 1, স্ট্রিট অ্যাড্রেস 2, শহর, রাজ্য; int জিপ;}। আপনি পরামর্শ দিচ্ছেন বলে মনে হচ্ছে যে আমরা আইএএনএতে "কর্মচারী" নিবন্ধন করি, বা আমরা "কর্মচারী" কে নাম / মান জোড়ার একটি সহযোগী অ্যারে হিসাবে বিবেচনা করি।
জন স্যান্ডার্স

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

11

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

গবেষণার শীর্ষে একটি উদ্ধৃতি:

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

- ক্রিস্টোফার আলেকজান্ডার, বিল্ডিংয়ের সময়হীন উপায় (1979)

এবং এটি সত্যিই এটি এখানে যোগফল। REST বিভিন্ন দিক থেকে আরও মার্জিত।

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


১৯৯৯ সালে এসওএপি সংজ্ঞায়িত হয়েছিল then
জন স্যান্ডার্স

এই w3.org/ প্রোটোকলস / এইচটিটিপি / ১.০ / স্পেক এইচটিএমএল অনুসারে ১৯৯০ সাল থেকে এইচটিটিপি ব্যবহার হচ্ছে? তাই কি? আমরা সকলেই জানি যে এসওএপি এইচটিপি ব্যবহারের একমাত্র কারণ ছিল কারণ পোর্ট 80 সম্ভবত ফায়ারওয়ালে খোলা ছিল। মাইক্রোসফ্ট আবারও ডিসিওএম ভুল করতে যাচ্ছে না।
ড্যারেল মিলার

1
" REST এর উপরে না পরিবর্তে এইচটিটিপি দিয়ে নির্মিত " +1। এই সম্পূর্ণ থ্রেডটি এসওএপি ও তার বিপরীতে রিস্ট ব্যবহারের বৈধতা বুঝতে আমার পক্ষে সত্যিই সহায়ক।
ক্রিস 22

9

থেকে এখানে :

রেস্ট সুবিধা:

  • লাইটওয়েট - অতিরিক্ত এক্সএমএল মার্কআপ খুব বেশি নয়
  • মানব পাঠযোগ্য ফলাফল
  • নির্মাণে সহজ - কোনও সরঞ্জামকিট প্রয়োজন নেই

এছাড়াও পরীক্ষা এই আউট:

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


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

1
@ এমিল - মনে রাখবেন যে এসএসএল সর্বদা উপলব্ধ থাকে না। কিছু লোক বার্তা ভিত্তিক সুরক্ষা চান, না পরিবহন স্তর ভিত্তিক সুরক্ষা। এবং যতক্ষণ না কোনও পোষ্টের বডি ব্যবহার করা হয় ... REST অনুরোধগুলি প্রক্রিয়া করার জন্য ব্যবহৃত একটি ক্রিয়া POST। আপনার প্রয়োজন অনুসারে আপনি এটি সর্বদা পুনরায় ব্যবহার করতে পারবেন না।
জাস্টিন নিসনার 14

1
একটি বড় কন: এসওএপি পরিষেবাদির জন্য ডাব্লুএসডিএলের মতো কোনও প্রমিত "বিবরণ" ভাষা নেই - প্রতিটি আরএসটি পরিষেবা ডকুমেন্টেড হতে পারে বা নাও হতে পারে, এবং ডকুমেন্টেশনের মান
অন্যটিকে

3
@ মার্ক_স যদি আরইএসটি সঠিকভাবে করা হয় তবে ডাব্লুএসডিএলের মতো "বর্ণনামূলক ভাষা" দরকার নেই। ব্যবহৃত মিডিয়া-প্রকারগুলি নথিভুক্ত করা দরকার, তবে দম্পতিরা মিডিয়া-প্রকারের দিকে ইঙ্গিত করে এমন নথি থাকতে পারে না।
ড্যারেল মিলার

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

8

আমি নিরাপদে বলতে পারি যে এটি একটি শিক্ষানবিস হিসাবে বুঝতে অনেক সময় ব্যয় করেছি তবে এটি আরআরএসটি থেকে শুরু থেকে সেরা লিঙ্ক! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

শুধু আপনাকে টানতে,

একটি "traditionalতিহ্যবাহী ওয়েব পরিষেবা" কী তা ভেবে দেখুন। এটি উন্মুক্ত "পদ্ধতি" সহ একটি ইন্টারফেস। ক্লায়েন্টরা পদ্ধতিগুলির নাম, ইনপুট এবং আউটপুট জানেন এবং তাই তাদের কল করতে পারেন।

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

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

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

আপনি নিশ্চয়ই ভাবছেন - ভাল, কীভাবে আপনাকে ক্লায়েন্ট হিসাবে ডালাসের আবহাওয়ায় পৌঁছাতে সহায়তা করে? আমরা কয়েক মুহুর্তের মধ্যে এটি পেতে হবে।

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

সুতরাং, যদি কোনও ওয়েব পরিষেবা কেবলমাত্র অবজেক্টগুলিকেই উদ্ভাসিত করে এবং আপনাকে জিজ্ঞাসা করা হয় - ভাল, এখন আসুন আমরা কয়েকটি মানক ক্রিয়া বা ক্রিয়াগুলি তৈরি করি যা "সমস্ত ক্লায়েন্টরা তাদের দেখানো সমস্ত বস্তুর জন্য প্রয়োগ করতে পারে", ...


সুতরাং পদ্ধতির পরিবর্তে অবজেক্ট থাকার সুবিধা কী?
সৌম্য রাউত

4

এখানে কিছু ধারনা:

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

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


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

1
@ ড্যারেল: আমি দেখতে পাচ্ছি না কীভাবে আরএসটি এটি সমাধান করতে সহায়তা করে। না MakeOrderআউট জন্য URL গুলি দিতে ConfirmOrderএবং CancelOrder? ক্লায়েন্ট কীভাবে পরিষেবাটি কল করতে ইতিমধ্যে জানে না, বরং ডেটা-চালিত হওয়া দরকার?
জন স্যান্ডার্স

1
@ জন ঠিক ক্লায়েন্ট জানে যে কনফার্ম অর্ডার ইউআরএল এবং বাতিলঅর্ডার ইউআরএল সরবরাহ করা যেতে পারে, তবে ur ইউআরএলগুলি দেখতে কেমন তা তা জানে না এবং সরবরাহ করা হলে কেবল সেগুলি অনুসরণ করবে। আপনি এটিকে ডেটা-চালিত বলেছেন, রায় এটিকে অ্যাপ্লিকেশন স্টেটের ইঞ্জিন হিসাবে হাইপারমিডিয়া বলে।
ড্যারেল মিলার

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

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

4

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

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


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

1
জন- একটি বিশ্রামের API এর একটি উদাহরণ হ'ল অ্যামাজন। তাদের একটি @SOAP এবং একটি REST এপিআই উভয়ই রয়েছে। এটি আপনার জন্য দরকারী হতে পারে- ডকসস.আমাজোনওবার্ভিসেসস
আমাজনস

3

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

এর অর্থ এটিও হ'ল অ প্রযুক্তির শেষে আমাদের বিক্রয় লোকেরা সম্পূর্ণ মুপেটের মতো দেখার আশঙ্কা ছাড়াই লোকেদের কাছে আমাদের বহুমুখী এপিআই সম্পর্কে বড়াই করতে পারে।

প্রযুক্তিগত সুবিধাগুলি বাদ দিয়ে কোনও কোনও প্রযুক্তিবিজ্ঞানের পক্ষে এটি ব্যাখ্যা করা, প্রদর্শন করা এবং আত্মবিশ্বাস বোধ করা সহজ একটি ভাল জিনিস। সোপ, যদিও প্রযুক্তিবিদদের পক্ষে ঠিক ততটা অ-প্রযুক্তিবিদদের কাছে পৌঁছনো সহজ এবং এটি "বিক্রয়" তত সহজ নয়।

আমি লক্ষ্য করেছি যে নন-টেকিজীরা যে জিনিসগুলি তাদের মাথার চারিদিকে লেগে থাকতে পারে তা পেতে পারে। সুতরাং আমি সন্দেহ করি যে একটি প্রযুক্তি হিসাবে ফ্যাশনের ঝকঝকে সওপ হিসাবে সংবেদনশীল হতে দায়বদ্ধ RE

তবে কোনও লাস্ট হওয়া উচিত এমন কোনও আরএসটি পরিষেবাদিতে কিছু না রাখার সমস্ত বিষয় দ্বিগুণ সত্য যদি কেবল কারণ প্রযুক্তিগুলি এত সহজে প্রযুক্তিগতভাবে চিন্তাভাবনা করে না এমন লোকেরা বুঝতে পারে।


3

নেটওয়ার্ক অ্যাপ্লিকেশনগুলি ডিজাইনের জন্য REST হ'ল একটি আর্কিটেকচার শৈলী। ধারণাটি হ'ল, মেশিনের মধ্যে সংযোগ স্থাপনের জন্য CORBA, RPC বা SOAP এর মতো জটিল প্রক্রিয়া ব্যবহার না করে, সাধারণ HTTP মেশিনের মধ্যে কল করতে ব্যবহৃত হয়।

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

আরআরসিটি হ'ল আরপিসি (রিমোট প্রক্রিয়া কল) এবং ওয়েব সার্ভিসেস (এসওএপি, ডাব্লুএসডিএল, ইত্যাদি।) এর মতো ব্যবস্থার জন্য একটি হালকা ওজনের বিকল্প। পরে, আমরা দেখতে পাব REST কত সাধারণ।

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


" অনেক উপায়ে, নিজেই HTTP এর উপর ভিত্তি করে ওয়ার্ল্ড ওয়াইড ওয়েবটি একটি REST- ভিত্তিক আর্কিটেকচার হিসাবে দেখা যেতে পারে। বিশ্রামের অ্যাপ্লিকেশনগুলি ডেটা পোস্ট করার জন্য HTTP অনুরোধগুলি ব্যবহার করে (তৈরি এবং / অথবা আপডেট করুন), ডেটা পড়ার জন্য (যেমন, প্রশ্ন তৈরি করা), এবং ডেটা মুছুন Thus সুতরাং, আরএসটি চারটি সিআরইউডি (তৈরি / পড়ুন / আপডেট / মুছুন) ক্রিয়াকলাপের জন্য এইচটিটিপি ব্যবহার করে " ধন্যবাদ.
ক্রিস 22
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.