HTTP এবং REST এর মধ্যে পার্থক্য কী?


303

REST এবং SOAP এর মধ্যে পার্থক্যগুলি সম্পর্কে অনেকগুলি পড়ার পরে, আমি অনুভূতি পেয়েছি যে এইচটিটিপি-র জন্য আরএসটি কেবল একটি শব্দ word কেউ কি ব্যাখ্যা করতে পারে যে REST HTTP- র সাথে কী কার্যকারিতা যুক্ত করে?

দ্রষ্টব্য : আমি আরওএসটি বনাম এসওএপি তুলনা খুঁজছি না।

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

দ্রষ্টব্য : আমি এখন REST এর অর্থটি উপলব্ধি করেছি; এমিল ইভানভ যেমন মন্তব্য করেছেন, আরএসটি-র অর্থ হ'ল HTTP ব্যবহার করা। যাইহোক, আমি নিশ্চিত নই যে এটি তার নিজস্ব একটি শর্তের প্রাপ্য কিনা এবং আমি অবশ্যই এর আশেপাশে হাইপ পাই না।


45
পার্শ্ব নোট হিসাবে, সম্ভবত আপনি আরআরএসটি সম্পর্কে এই দিনে যে হাইপটি শোনেন তার 90% হ'ল এমন লোকদের কাছ থেকে যারা আসলেই রেস্ট সম্পর্কে সম্পূর্ণ ছবি বোঝেন না। দুর্ভাগ্যক্রমে REST বিক্রয় বেজে উঠেছে। আসল সুবিধাগুলি জানতে আপনাকে প্রচুর খাঁজ কাটাতে হবে।
ড্যারেল মিলার

7
REST এর আশেপাশে হাইপটি সম্ভবত লোকেরা এসওএপি-র দ্বারা প্রচণ্ড বিরক্ত হওয়ার কারণে। সকলেই এসওএপি জাহান্নাম থেকে বাঁচতে পেরে খুশি: ডি
এএফএক্সএক্স

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

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

1
@ রোসড্রু দুর্দান্ত উপমা .. এটি বুঝতে আরও সহজ করে তোলে।
অনূপ

উত্তর:


220

না, REST হ'ল এইচটিটিপি ব্যবহার করা উচিত ।

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

উদাহরণস্বরূপ, আরআরইএসটি DELETEকোনও ইউআরআই এর পিছনে একটি দস্তাবেজ (এটি কোনও ফাইল, রাজ্য, ইত্যাদি) মুছতে ব্যবহারের নির্দেশ দেয় , এইচটিটিপি সহ, আপনি কোনও GETবা POSTকোয়েরির মতো ব্যবহার করতে পারবেন না ...product/?delete_id=22


23
এবং এই অন্যান্য পদ্ধতি ব্যবহার করে বড় সুবিধা কি হবে?
দিমিত্রি সি।

7
আমি একটি বাস্তব বিশ্বের উদাহরণে একটি লিঙ্ক পোস্ট করেছি যা আপনাকে সুবিধাগুলি প্রদর্শন করবে। চিয়ার্স।
এফএক্সএক্সএক্স

8
বিশ্রামের ভুল সংজ্ঞা দেওয়ার জন্য -1। বিশ্রাম এক ধরণের আর্কিটেকচার, ওয়েবের মাধ্যমে বার্তা প্রেরণের উপায় নয়। আরও তথ্যের জন্য: এন.ইউইকিপিডিয়া.আর
যুবাল পেরেলম্যান

3
আবার ভুল. REST টি http / 1.0 প্রোটোকলের পিছনে কোনও স্থাপত্য নীতি নয়। RESTful আর্কিটেকচারটি অনেক পরে আবিষ্কার হয়েছিল। HTTP প্রোটোকল প্রদত্ত কার্যকারিতা REST আর্কিটেকচারের সাথে খাপ খায়, তবে 2 একে অপরের উপর নির্ভর করে না। এটি চাকাটিকে পুনর্বহাল করার প্রশ্ন নয়, এটি এই ধারণাগুলি বোঝার প্রশ্ন
যুবল পেরেলম্যান

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

94

HTTP যোগাযোগের জন্য ব্যবহৃত একটি প্রোটোকল যা সাধারণত ইন্টারনেট সংস্থান বা কোনও ওয়েব ব্রাউজার ক্লায়েন্টের সাথে কোনও অ্যাপ্লিকেশনের সাথে যোগাযোগ করতে ব্যবহৃত হয়।

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

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

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

অবশ্যই এটি আরও অনেক কিছু আছে তবে আমার মতে এটি একটি চামচ মূল ধারণাগুলি।


31

এইচটিটিপি একটি অ্যাপ্লিকেশন প্রোটোকল। আরআরইএসটি হ'ল বিধিগুলির একটি সেট, যা অনুসরণ করা হলে, আপনাকে এমন একটি বিতরণ অ্যাপ্লিকেশন তৈরি করতে সক্ষম করে যা নির্দিষ্ট সীমাবদ্ধতার একটি নির্দিষ্ট সেট রাখে।

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

স্ব-বর্ণনার সীমাবদ্ধতার জন্য ব্যবহারকারীদের অভিপ্রায় সম্পূর্ণ স্ব বর্ণনামূলক হতে একটি বিশ্রামের অনুরোধ প্রয়োজন। এটি মধ্যস্থতাকারীদের (প্রক্সি এবং ক্যাশে) বার্তায় নিরাপদে কাজ করতে সহায়তা করে।

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


19

আমি এটি যেভাবে বুঝতে পেরেছি, আরআরইএসটি উপলভ্য এইচটিটিপি কমান্ডগুলির ব্যবহার কার্যকর করে কারণ সেগুলি ব্যবহার করা উচিত ছিল।

উদাহরণস্বরূপ, আমি এটি করতে পারি:

GET
http://example.com?method=delete&item=xxx

তবে বিশ্রামের সাথে আমি "ডিলেট" অনুরোধ পদ্ধতিটি ব্যবহার করব, "পদ্ধতি" ক্যোয়ারী প্যারামের প্রয়োজনীয়তা অপসারণ করে

DELETE
http://example.com?item=xxx

15

বেশ না ...

http://en.wikipedia.org/wiki/Representational_State_Transfer

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

http://www.looselycoupled.com/glossary/SOAP

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


3
কে এসওএপি সম্পর্কে কিছু বলেছে?
ড্যারেল মিলার


8

আরআরইএসটি হ'ল বড় সিস্টেমগুলির ডিজাইনের (ওয়েবের মতো) কাছে যাওয়ার একটি নির্দিষ্ট উপায়।

এটি 'বিধি' (বা 'সীমাবদ্ধতা') এর একটি সেট।

এইচটিটিপি একটি প্রোটোকল যা এই নিয়মগুলি মান্য করার চেষ্টা করে।


আমি বলব যে আপনি যদি এইচটিটিপিটিকে আপনার আরএসটি পরিষেবার জন্য পরিবহণ হিসাবে ব্যবহার করেন তবে এই নিয়মগুলি মেনে চলা সহজ।
abatishchev

7

REST = প্রতিনিধিত্বমূলক রাষ্ট্র স্থানান্তর

আরআরইএসটি হ'ল বিধিগুলির একটি সেট, যা অনুসরণ করা হলে, আপনাকে এমন একটি বিতরণ অ্যাপ্লিকেশন তৈরি করতে সক্ষম করে যা নির্দিষ্ট সীমাবদ্ধতার একটি নির্দিষ্ট সেট রাখে।

REST হ'ল এই বার্তাগুলি পরিবহনের জন্য HTTP ব্যবহার করতে পারে এমন কোনও (এক্সএমএল, জেএসএন ইত্যাদি) বার্তাগুলি বিনিময় করার জন্য একটি প্রোটোকল।

বৈশিষ্ট্য:

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

রাষ্ট্রহীনতার সুবিধা:

  1. ওয়েব পরিষেবাদি প্রতিটি পদ্ধতি কলকে আলাদাভাবে চিকিত্সা করতে পারে।
  2. ওয়েব পরিষেবাদির ক্লায়েন্টের পূর্বের ইন্টারঅ্যাকশন বজায় রাখা দরকার না।
  3. এটি পরিবর্তে অ্যাপ্লিকেশন ডিজাইনকে সহজতর করে।
  4. এইচটিটিপি নিজেই টিসিপির বিপরীতে একটি স্টেটলেস প্রোটোকল এবং তাই এইচটিটিপি প্রোটোকলগুলির সাথে RESTful ওয়েব পরিষেবাদি নির্বিঘ্নে কাজ করে।

রাষ্ট্রহীনতার অসুবিধা:

  1. শিরোনাম আকারে একটি অতিরিক্ত স্তর ক্লায়েন্টের অবস্থা রক্ষার জন্য প্রতিটি অনুরোধে যুক্ত করা প্রয়োজন।
  2. সুরক্ষার জন্য আমাদের প্রতিটি অনুরোধে একটি শিরোনাম তথ্য যুক্ত করা দরকার।

REST দ্বারা সমর্থিত HTTP পদ্ধতিগুলি:

জিইটি: / স্ট্রিং / সামোথারস্ট্রিং এটি আদর্শবান এবং প্রতিবার কোনও কল করার সময় আদর্শভাবে একই ফলাফলটি ফিরে আসা উচিত

পুট: জিইটির মতোই। আইডেম্পোটেন্ট এবং সংস্থানগুলি আপডেট করতে ব্যবহৃত হয়।

পোস্ট: সংস্থান তৈরির জন্য ব্যবহৃত একটি ইউআরএল এবং দেহ থাকা উচিত। একাধিক কল আদর্শভাবে ভিন্ন ফলাফল ফেরত দেয় এবং একাধিক পণ্য তৈরি করা উচিত।

মোছা: সার্ভারে সংস্থানগুলি মুছতে ব্যবহৃত হয়।

প্রধান:

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

বিকল্প:

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

HTTP প্রতিক্রিয়া

সমস্ত প্রতিক্রিয়া জন্য এখানে যান

এখানে কয়েকটি গুরুত্বপূর্ণ বেশী: 200 - ঠিক আছে 3XX - অতিরিক্ত তথ্য ক্লায়েন্ট এবং URL ফেরৎ 400 থেকে প্রয়োজনীয় - ত্রুটিযুক্ত অনুরোধ
401 - অ্যাক্সেস করতে অননুমোদিত
403 - নিষিদ্ধ
অনুরোধ বৈধ ছিল, কিন্তু সার্ভার কর্ম অসম্মতি জানাচ্ছে। ব্যবহারকারীর কোনও সংস্থার জন্য প্রয়োজনীয় অনুমতি থাকতে পারে না, বা কোনও ধরণের অ্যাকাউন্টের প্রয়োজন হতে পারে।

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

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

404 - অনুরোধ পাওয়া যায় নি
500 - অভ্যন্তরীণ সার্ভার ব্যর্থতা
502 - খারাপ গেটওয়ে ত্রুটি


5

এইচটিটিপি একটি যোগাযোগ প্রোটোকল যা কোনও নেটওয়ার্কের মাধ্যমে বার্তা স্থানান্তর করে। এসওএপি হ'ল এক্সএমএল-ভিত্তিক বার্তাগুলি বিনিময় করার জন্য একটি প্রোটোকল যা এই বার্তাগুলি পরিবহনের জন্য এইচটিটিপি ব্যবহার করতে পারে। বিশ্রাম এমন কোনও (এক্সএমএল বা জেএসএন) বার্তাগুলি বিনিময় করার জন্য একটি প্রোটোকল যা এই বার্তাগুলি পরিবহনের জন্য এইচটিটিপি ব্যবহার করতে পারে।


আপনার উত্তর প্রশ্নের উত্তর দেয় না।
আনিস

আপনার এইচটিটিপি এবং এসওএপি সংজ্ঞাটি দুর্দান্ত ছিল এবং আমার জন্য প্রশ্নটি সাফ করেছে। তবে আমি বিশ্বাস করি না বিশ্রাম একটি প্রোটোকল। এটি একটি স্থাপত্য নির্দেশিকা যা এইচটিটিপি পরিবহন প্রোটোকলের সঠিক ব্যবহার কার্যকর করে।
ক্যাপচারড্রি

5

HTTP is a contract, a communication protocol and REST is a concept, an architectural style যা HTTP, FTP বা অন্যান্য যোগাযোগ প্রোটোকল ব্যবহার করতে পারে তবে HTTP- র সাহায্যে বহুল ব্যবহৃত হয়।

REST implies a series of constraints about how Server and Client should interactHTTP is a communication protocol with a given mechanism for server-client data transfer, এটি REST এপিআইতে সর্বাধিক ব্যবহৃত হয় কেবলমাত্র REST was inspired by WWW (world wide web) which largely used HTTPREST সংজ্ঞায়নের আগে, তাই এইচটিটিপি দিয়ে REST এপিআই স্টাইল প্রয়োগ করা আরও সহজ।

There are three major constraints in REST (but there are more):

1. সার্ভার এবং ক্লায়েন্টের মধ্যে মিথস্ক্রিয়া কেবল হাইপারটেক্সটের মাধ্যমে বর্ণনা করা উচিত।

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

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

এবং এইচটিটিপি হ'ল একটি যোগাযোগ প্রোটোকল (একটি সরঞ্জাম) যা এটি অর্জনে সহায়তা করতে পারে।

আরও তথ্যের জন্য এই লিঙ্কগুলি পরীক্ষা করুন:

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven


4

REST অগত্যা HTTP- র সাথে আবদ্ধ নয় । RESTful ওয়েব পরিষেবাদিগুলি কেবলমাত্র একটি ওয়েব পরিষেবা যা একটি RESTful আর্কিটেকচার অনুসরণ করে।

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

HTTP- র হল 1-Client-server, 2-stateless, 3-casheable। তারপরে কি অতিরিক্ত অতিরিক্ত বৈশিষ্ট্য / সীমাবদ্ধতাগুলি HTTP এ লাগিয়েছে? আমরা REST এর সাথে কী করতে পারি যা কেবল এইচটিটিপি দিয়ে করা যায় না?
ওয়াফিক

4

আপনি HTTP এবং REST এর মধ্যে পার্থক্য জানেন না From

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


2

REST এপিআইগুলি অবশ্যই হাইপারটেক্সট-চালিত

রায় ফিল্ডিংয়ের ব্লগ থেকে আপনি HTTP API বা একটি REST এপিআই তৈরি করছেন কিনা তা যাচাই করার জন্য এখানে কয়েকটি উপায়ের সেট রয়েছে:

এপিআই ডিজাইনারগণ, আপনার তৈরিটিকে REST এপিআই বলার আগে দয়া করে নীচের বিধিগুলি নোট করুন:

  • একটি আরএসটি এপিআই কোনও একক যোগাযোগ প্রোটোকলের উপর নির্ভরশীল হওয়া উচিত নয়, যদিও প্রদত্ত প্রোটোকলের সাথে তার সফল ম্যাপিং মেটাডেটার প্রাপ্যতা, পদ্ধতির পছন্দ ইত্যাদির উপর নির্ভরশীল হতে পারে In সাধারণভাবে, সনাক্তকরণের জন্য ইউআরআই ব্যবহার করা কোনও প্রোটোকল উপাদান অবশ্যই অনুমতি দেবে যে সনাক্তকরণের জন্য ব্যবহার করতে হবে কোনও ইউআরআই স্কিম। [এখানে ব্যর্থতা বোঝায় যে সনাক্তকরণ মিথস্ক্রিয়া থেকে পৃথক করা হয় না।]
  • একটি REST এপিআইতে প্রোটোকলগুলির অতিরিক্ত সংক্ষিপ্ত বিবরণগুলি যেমন HTTP এর প্যাচচ পদ্ধতি বা লিঙ্ক শিরোলেখ ক্ষেত্রের ফিল্ড-আউট বা ফিক্সিং বাদ দিয়ে যোগাযোগ প্রোটোকলগুলিতে কোনও পরিবর্তন হওয়া উচিত নয়। ভাঙ্গা বাস্তবায়ন (যেমন ব্রাউজারগুলি এইচটিএমএল এর পদ্ধতি সেটকে সংজ্ঞায়িত করে এমন বিশ্বাসযোগ্য পর্যাপ্ত বুদ্ধিমান) আলাদাভাবে সংজ্ঞায়িত করা উচিত বা কমপক্ষে পরিশিষ্টে, এই প্রত্যাশা সহ যে ওয়ার্কআউন্ডটি শেষ পর্যন্ত অপ্রচলিত হবে। [এখানে ব্যর্থতা বোঝায় যে উত্স ইন্টারফেসটি জেনেরিক নয়, অবজেক্ট-নির্দিষ্ট]
  • একটি REST এপিআই এর প্রায় সমস্ত বর্ণনামূলক প্রচেষ্টাকে সম্পদ উপস্থাপন এবং ড্রাইভিং অ্যাপ্লিকেশন স্থিতির জন্য ব্যবহৃত মিডিয়া ধরণের (গুলি) সংজ্ঞায়িত করতে বা বিদ্যমান স্ট্যান্ডার্ড মিডিয়া প্রকারের জন্য প্রসারিত সম্পর্কের নাম এবং / অথবা হাইপারটেক্সট-সক্ষম মার্ক-আপ সংজ্ঞায়িত করতে ব্যয় করা উচিত। কোন আগ্রহের ইউআরআই কীভাবে কোন মিডিয়া টাইপ (এবং বেশিরভাগ ক্ষেত্রে ইতিমধ্যে বিদ্যমান মিডিয়া টাইপগুলি দ্বারা সংজ্ঞায়িত) প্রসেসিং নিয়মের পরিধি অনুযায়ী পুরোপুরি সংজ্ঞায়িত করা উচিত সে সম্পর্কে কী কী পদ্ধতিগুলি ব্যবহার করতে হবে তা বর্ণনা করতে ব্যয় করা কোনও প্রচেষ্টা ব্যয় করা হয়নি। [এখানে ব্যর্থতা বোঝায় যে আউট-অফ-ব্যান্ডের তথ্য হাইপারটেক্সটের পরিবর্তে ইন্টারঅ্যাকশন চালাচ্ছে]]
  • একটি REST এপিআই অবশ্যই স্থির সংস্থানগুলির নাম বা স্তরক্রম (ক্লায়েন্ট এবং সার্ভারের একটি সুস্পষ্ট মিলন) সংজ্ঞায়িত করবে না। সার্ভারের অবশ্যই নিজের নাম স্থান নিয়ন্ত্রণ করার স্বাধীনতা থাকতে হবে। পরিবর্তে, সার্ভারগুলিকে মিডিয়া প্রকার এবং লিঙ্ক সম্পর্কের মধ্যে সেই নির্দেশাবলী সংজ্ঞায়িত করে যথাযথ ইউআরআই, যেমন এইচটিএমএল ফর্ম এবং ইউআরআই টেম্পলেটগুলিতে করা যায় সে সম্পর্কে ক্লায়েন্টদের নির্দেশ দেওয়ার অনুমতি দিন। [এখানে ব্যর্থতা থেকেই বোঝা যায় যে ক্লায়েন্টরা ব্যান্ডের তথ্যের বাইরে যেমন একটি ডোমেন-নির্দিষ্ট মান, যা আরপিসির কার্যকরী সংযোগের সমতুল্য ডেটা-ভিত্তিক সমতুল্যের কারণে একটি সংস্থান সংস্থান গ্রহণ করছে)।
  • একটি REST এপিআই'র কখনই "টাইপ করা" সংস্থান থাকা উচিত নয় যা ক্লায়েন্টের পক্ষে তাৎপর্যপূর্ণ। স্পেসিফিকেশন লেখকরা ইন্টারফেসের পিছনে সার্ভার বাস্তবায়ন বর্ণনা করার জন্য সংস্থানগুলির ধরণ ব্যবহার করতে পারে তবে এই ধরণেরগুলি অবশ্যই ক্লায়েন্টের কাছে অপ্রাসঙ্গিক এবং অদৃশ্য হতে হবে। একমাত্র প্রকার যা ক্লায়েন্টের কাছে তাৎপর্যপূর্ণ তা হ'ল বর্তমান প্রতিনিধিত্বের মিডিয়া টাইপ এবং মানসম্পন্ন সম্পর্কের নাম। [Ditto]
  • আরআরএসআইপি প্রাথমিক ইউআরআই (বুকমার্ক) এর বাইরে কোনও পূর্ব জ্ঞান ছাড়াই প্রবেশ করাতে হবে এবং মানকৃত মিডিয়া টাইপের সেট করতে হবে যা উদ্দেশ্যে দর্শকদের জন্য উপযুক্ত (যেমন, কোনও ক্লায়েন্টের দ্বারা বোঝা প্রত্যাশিত যা এপিআই ব্যবহার করতে পারে)। সেদিক থেকে সমস্ত অ্যাপ্লিকেশন রাষ্ট্রের রূপান্তরগুলি অবশ্যই প্রাপ্ত উপস্থাপনাগুলিতে উপস্থিত থাকা বা সেই উপস্থাপনাগুলির ব্যবহারকারীর দ্বারা পরিচালিত ক্লায়েন্ট সার্ভার-সরবরাহিত পছন্দগুলির ক্লায়েন্ট নির্বাচনের দ্বারা চালিত হতে হবে। স্থানান্তরগুলি মিডিয়া ধরণ এবং সংস্থান যোগাযোগ ব্যবস্থার ক্লায়েন্টের জ্ঞান (বা এর দ্বারা সীমাবদ্ধ) নির্ধারিত হতে পারে, উভয়টিই ফ্লাই-এ উন্নত হতে পারে (উদাহরণস্বরূপ, কোড অন অন ডিমান্ড)। [এখানে ব্যর্থতা বোঝায় যে আউট-অফ-ব্যান্ডের তথ্য হাইপারটেক্সটের পরিবর্তে ইন্টারঅ্যাকশন চালাচ্ছে]]
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.