এইচটিটিপি প্রোটোকলে জিইটি এবং পোষ্টের মতো পদ্ধতির কী প্রয়োজন?


17

আমরা কি কেবল একটি অনুরোধ সংস্থা এবং একটি প্রতিক্রিয়া সংস্থা ব্যবহার করে এইচটিটিপি প্রোটোকলটি প্রয়োগ করতে পারি না?

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

এইচটিটিপি প্রোটোকলের কেন পদ্ধতির ধারণা রয়েছে?

উত্তরগুলি থেকে, আমি কেন পদ্ধতিগুলির ধারণা আছে সে সম্পর্কে কিছুটা ধারণা পেয়েছি his এটি অন্য একটি সম্পর্কিত প্রশ্নের দিকে নিয়ে যায়:

উদাহরণস্বরূপ জিমেইল রচনা লিঙ্কে, পুট / পোস্ট অনুরোধ এবং ডেটা প্রেরণ করা হবে। কীভাবে ব্রাউজারটি জানবে যে কোন পদ্ধতিটি ব্যবহার করতে হবে? সার্ভারের মাধ্যমে প্রেরিত জিমেইল পৃষ্ঠায় জিমেইল রচনা অনুরোধটি কল করার সময় ব্যবহারের পদ্ধতিটির নাম অন্তর্ভুক্ত রয়েছে? আমরা যখন www.gmail.com কল করি তখন অবশ্যই এটি জিইটি পদ্ধতি ব্যবহার করা উচিত, ব্রাউজার কীভাবে জানতে পারে যে এই পদ্ধতিটি ব্যবহার করা উচিত?

পিএস : আমার কাছে উত্তরের বিষয়ে মন্তব্য করার মতো ক্রেডিট নেই, সুতরাং এই প্রশ্নের পিছনে উদ্দেশ্য সম্পর্কিত লোকেরা উত্থাপিত অনেক প্রশ্নের বিষয়ে আমি মন্তব্য করতে পারছি না।

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


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

4
আমি অবাক, আপনি কি জিজ্ঞাসা করছেন যে এইচটিটিপি পদ্ধতি ছাড়াই সংজ্ঞায়িত করা যেতে পারে, অর্থাত্ তাদের জন্য rationতিহাসিক যুক্তি; বা যদি বর্তমানে প্রোটোকলটি এগুলি ছাড়া ব্যবহার করা যেতে পারে, তবে কী ড্রপিং পদ্ধতি বিদ্যমান স্পেসিফিকেশনের মধ্যে থাকতে পারে?
ilkkachu

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

1
@ ব্যবহারকারী ১০৪6566, যদি এটি আমার প্রশ্নের উত্তর হয় তবে আপনি এখনও মূল নকশা বা বর্তমান পরিস্থিতিটি বোঝাচ্ছেন কিনা তা নিশ্চিত নই। (আমি এটি বলার দরকার নেই বা দরকার নেই তা
বলিনি

@ মার্স এবং অন্যান্য: উদাহরণস্বরূপ জিমেইল রচনা লিঙ্কে, পুট / পোস্ট অনুরোধ এবং ডেটা প্রেরণ করা হবে। কীভাবে ব্রাউজারটি জানবে যে কোন পদ্ধতিটি ব্যবহার করতে হবে? সার্ভারের মাধ্যমে প্রেরিত জিমেইল পৃষ্ঠায় জিমেইল রচনা অনুরোধটি কল করার সময় ব্যবহারের পদ্ধতিটির নাম অন্তর্ভুক্ত রয়েছে? আমরা যখন www.gmail.com কল করি তখন অবশ্যই এটি জিইটি পদ্ধতি ব্যবহার করা উচিত, ব্রাউজার কীভাবে জানতে পারে যে এই পদ্ধতিটি ব্যবহার করা উচিত?
বায়োলজিক

উত্তর:


33

দয়া করে নোট করুন যে উত্তরটি প্রথম লেখা হয়েছিল বলে প্রশ্নটি পরিবর্তন হয়েছে / স্পষ্ট হয়েছে ied প্রশ্নের সর্বশেষ পুনরাবৃত্তির আরও উত্তর দ্বিতীয় অনুভূমিক নিয়মের পরে after

এইচটিটিপি প্রোটোকলে জিইটি এবং পোষ্টের মতো পদ্ধতির কী প্রয়োজন?

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

আমরা কি কেবল একটি অনুরোধ সংস্থা এবং একটি প্রতিক্রিয়া সংস্থা ব্যবহার করে এইচটিটিপি প্রোটোকলটি প্রয়োগ করতে পারি না?

না, কারণ তারপরে যা কিছু আপনি তৈরি করেছেন তা HTTP প্রোটোকল নয়

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

অভিনন্দন, আপনি কেবল একটি নতুন প্রোটোকল আবিষ্কার করেছেন! এখন, যদি আপনি এটি চালনা এবং পরিচালনা করতে মানক সংস্থা স্থাপন করতে চান তবে এটি বিকাশ করুন ইত্যাদি, এটি একদিন এইচটিটিপি ছাড়িয়ে যেতে পারে

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

ইন্টারনেটে ফিরে যান, আপনি যদি এইচটিটিপি অনুগত একটি ওয়েব সার্ভারে কোনও সকেট খোলেন এবং নিম্নলিখিতগুলি প্রেরণ করুন:

EHLO
AUTH LOGIN

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

এই কারণেই আপনি এইচটিটিপি প্রোটোকল প্রয়োগ না করে এইচটিটিপি প্রোটোকল প্রয়োগ করতে পারবেন না; আপনি যা লিখেছেন তা যদি প্রোটোকলের সাথে সামঞ্জস্য না হয় তবে তা কেবল প্রোটোকল নয় - এটি অন্য কিছু, এবং এটি প্রোটোকলে বর্ণিত হিসাবে কাজ করবে না

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

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


বিভিন্ন HTTP পদ্ধতি বাস্তবায়নের কি সত্যিই প্রয়োজন?

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

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

VERB URL VERSION
header: value

maybe_body

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


হালনাগাদ

আপনার প্রশ্নটি কিছুটা বিকশিত হয়েছে, আপনি যা জিজ্ঞাসা করছেন তার এখানে কিছু প্রতিক্রিয়া রয়েছে:

এইচটিটিপি প্রোটোকলের কেন পদ্ধতির ধারণা রয়েছে?

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

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

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

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

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

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

উত্তরগুলি থেকে, আমি কেন পদ্ধতিগুলির ধারণা আছে সে সম্পর্কে কিছুটা ধারণা পেয়েছি his এটি অন্য একটি সম্পর্কিত প্রশ্নের দিকে নিয়ে যায়:

উদাহরণস্বরূপ জিমেইল রচনা লিঙ্কে, পুট / পোস্ট অনুরোধ এবং ডেটা প্রেরণ করা হবে। কীভাবে ব্রাউজারটি জানবে যে কোন পদ্ধতিটি ব্যবহার করতে হবে?

এটি ডিফল্টরূপে, কনভেনশন / স্পেস অনুসারে জিইটি ব্যবহার করে যখন আপনি ইউআরএল টাইপ করবেন এবং রিটার্ন টিপুন তখনই ডিক্রিডমেন্ট হবে

সার্ভারের মাধ্যমে প্রেরিত জিমেইল পৃষ্ঠায় জিমেইল রচনা অনুরোধটি কল করার সময় ব্যবহারের পদ্ধতিটির নাম অন্তর্ভুক্ত রয়েছে?

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

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

আমরা যখন www.gmail.com কল করি তখন অবশ্যই এটি জিইটি পদ্ধতি ব্যবহার করা উচিত, ব্রাউজার কীভাবে জানতে পারে যে এই পদ্ধতিটি ব্যবহার করা উচিত?

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

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

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

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


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

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

1
"কীভাবে" পদ্ধতিগুলি কী তা আমাকে বলার দরকার নেই? তার জন্য একটি স্পষ্ট নথি আছে। এইচটিটিপি কোনও ম্যাজিক নয়, এফটিপি বা এসএমটিপি বা আরটিএমপিও নয় - এগুলি সকলেই কেবল একটি সকেটের নীচে যাচ্ছে বাইট, তবে এটি অর্ডার, উপস্থাপনা, নিয়ম (প্রোটোকল) যা বাইটস অনুসারে প্রোটোকলকে কী তৈরি করে হয়। আমি যে প্রশ্নটি করি নি সেটিতে আপনি কিছু পড়েছেন, তবে আপনার প্রশ্নের উত্তরটিও আমার আপত্তি নেই: পদ্ধতি ছাড়াই কি প্রোটোকল তৈরি করা যায়? - সত্যই নয়, তবে এটি পদ্ধতিগুলির দ্বারা আপনি কী বোঝাতে চাইছেন তা নির্ভর করে। এইচটিটিপি পদ্ধতিগুলি সহ এইচটিটিপি হ'ল একমাত্র প্রোটোকল তবে আমি যে সমস্ত প্রোটোকলগুলি ভাবতে পারি তার মধ্যে রয়েছে ..
Caius Jard

.. মিথস্ক্রিয়তার পূর্বনির্ধারিত নিদর্শনগুলি যা আমি পদ্ধতি হিসাবে উল্লেখ করব; এগুলি ছাড়া তারা প্রোটোকল হবে না এবং তারা নির্ভরযোগ্য আন্ত-প্রক্রিয়া / আন্তঃব্যবস্থা যোগাযোগ অর্জন করতে সক্ষম হবে না।
Caius Jard

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

12

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

আপনি প্রস্তাব করছেন ঠিক তার বিপরীতে REST করেছেন, উল্লেখ করে যে HTTP পদ্ধতিগুলি বেশিরভাগ অ্যাপ্লিকেশনগুলির সাধারণ CRUD ব্যবহারের ক্ষেত্রে পরিবেশন করে যদি পুট এবং ডিলেট পুনরায় ফিরিয়ে আনা হয়।

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

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


4
"পুট এবং মোছা বিশ্রামের আগে মরিবন্ড ছিল" সত্য নয়। আপনি কীভাবে ওয়েবডিএভি কাজ করেছেন বলে মনে করেন?
প্যাট্রিক মেভজেক

3
@ পেট্রিকম্যাভিজাক হ্যাঁ, তবে কি ওয়েবডাভ কি কোমায় থাকার পরিবর্তে পর্যাপ্ত লোকেরা তাদের জীবিত বিবেচনা করার জন্য ব্যবহার করেছিলেন? ^^
ফ্রাঙ্ক হপকিন্স

1
@ পেট্রিকমেভিজেক ওয়েবডিএভি কার্যত HTTP থেকে পৃথক প্রোটোকল।
সন্ধ্যাশয়

@duskwuff tools.ietf.org/html/rfc4918 "HTTP- র এক্সটেনশানগুলি জন্য ওয়েব অথারিং এবং ভারশনিং (অম্রো) বন্টিত"। এত আলাদা নয়, এটি পরিষ্কারভাবে এটির উপরে রয়েছে।
প্যাট্রিক মেভিজেক

1
আঞ্চলিক পরিবর্তন (ওরফে আপডেট) ইঙ্গিত করতে PATCH টি REST দ্বারা ব্যবহৃত হয়।
jmoreno

7

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

উদাহরণ:

GET https://example.com/api/products/1234

এটি 1234 পণ্যের বিবরণ আনবে।


POST https://example.com/api/products/1234

এটি অনুরোধের বডিটিতে ডেটা ব্যবহার করে 1234 আইডি সহ একটি পণ্য তৈরি করবে।


PUT https://example.com/api/products/1234

এটি অনুরোধের বডিতে থাকা ডেটা সহ 1234 পণ্য আপডেট করবে।


DELETE https://example.com/api/products/1234

এটি 1234 আইডি সহ একটি পণ্য মুছবে।


আমি প্রতিটি অপারেশনের জন্য বিভিন্ন প্রান্তপয়েন্ট তৈরি করতে পারতাম তবে এটি প্রক্রিয়াটিকে জটিল করে তুলবে এবং অন্যান্য বিকাশকারীদের জন্য এটি কম বোধগম্য করে তুলবে।


1
এটি অন্য কারও মতো সঠিক (বা সম্ভবত পাশাপাশি) সঠিক প্রশ্নের উত্তর দেয় না, তবে স্বতন্ত্র পদ্ধতিগুলির অবিচ্ছিন্ন ব্যবহারের জন্য এটি একটি আধুনিক যুক্তি। +1
টিকোপার

6

এইচটিটিপি প্রোটোকলে জিইটি এবং পোষ্টের মতো পদ্ধতির কী প্রয়োজন?

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

অনুরোধ পদ্ধতি মৌলিক হয় প্রমিত উপর ক্রিয়ার সেট কি করতে ঐ ফাইল সঙ্গে ...

  • জিইটি মানে ডাউনলোড করা
  • হেড মানে তথ্য প্রাপ্ত
  • পুট মানেই আপলোড
  • মুছে ফেলা মানে সরান
  • পোস্টের অর্থ ডেটা প্রেরণ
  • বিকল্পগুলির অর্থ আমাকে বলুন আমি কী করতে পারি

HTTP- র / 0.9 এর দিনে, অনুরোধ লাইন প্রোটোকলের অনুরোধ পা একমাত্র জিনিস; কোনও অনুরোধ শিরোনাম নেই, কোনও প্রতিক্রিয়া শিরোনাম নেই। আপনি কেবল টাইপ করুন , টিপুন , সার্ভার প্রতিক্রিয়া বডিটি (যেমন এইচটিএমএল বিষয়বস্তু) ফিরিয়ে দেবে, এবং ঠিক আছে ধন্যবাদ বাই (যেমন সংযোগটি বন্ধ করুন)।GET /somefileEnter

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

তবে, আপনি যদি আধুনিক অ্যাপ্লিকেশন সার্ভারে এই শব্দার্থকগুলি কীভাবে আচরণ করবেন সে সম্পর্কে জিজ্ঞাসা করার অর্থ যদি ...

আমরা কি কেবল একটি অনুরোধ সংস্থা এবং একটি প্রতিক্রিয়া সংস্থা ব্যবহার করে এইচটিটিপি প্রোটোকলটি প্রয়োগ করতে পারি না?

বিভিন্ন HTTP পদ্ধতি বাস্তবায়নের কি সত্যিই প্রয়োজন?

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

আপনি যদি এর প্রভাবগুলি সাবধানতার সাথে বিবেচনা না করে প্রত্যাশার বিরুদ্ধে যান তবে বিভিন্ন অপ্রীতিকর ঘটনা ঘটবে, যেমন ...

  • আপনি যখন ডেটা জমা দেওয়ার ব্যবহারের জন্য জিইটি পদ্ধতিটি জুতা রাখেন, তখন সার্ভারটি আপনার মুখে 414 " ইউআরআই খুব দীর্ঘ " ত্রুটি থুথুতে পারে ।
  • আপনি যখন জিইটি পদ্ধতিটি ডেটা সংশোধন করার জন্য ব্যবহার করবেন তখন আপনি দেখতে পাবেন যে ব্যবহারকারী যখন কোনও ক্যাচিং প্রক্সি রেখে থাকে বা অপ্রত্যাশিত পরিবর্তন ঘটে যখন ব্যবহারকারী বুকমার্ক থেকে ইউআরএল প্রত্যাহার করে (বা ওয়েব ক্রলারগুলি এটি পৌঁছায়) ।
  • আপনি যখন হেড পদ্ধতিতে ভুলভাবে প্রতিক্রিয়া জানান, আপনি দেখতে পাবেন যে আপনার স্বয়ংক্রিয় সাইট চেক সরঞ্জামগুলি (যেমন wget --spider) আপনার সাইটে জামিন।
  • আপনি যখন সামগ্রী পোস্টে পোষ্ট পদ্ধতি পোষন করেন, আপনি দেখতে পাবেন যে বুকমার্কিং বা ব্রাউজারে ইউআরএল প্রবেশ করাও কাজ করবে না।
  • এবং আরো অনেক...

" শিক্ষানবিশরা নিয়ম জানেন, তবে অভিজ্ঞরা ব্যতিক্রমগুলি জানেন " "

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

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

অযত্নে স্ট্যান্ডার্ডটি ভাঙার অর্থ হ'ল আপনি আপনার ব্যবহারকারীদের উপর বৈষম্য প্রয়োগ করছেন ।


3

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

সর্বাধিক গুরুত্বপূর্ণ কারণ বিভিন্ন পদ্ধতির বিভিন্ন শব্দার্থবিজ্ঞান রয়েছে। কিছু নিরাপদ, কেউ আদর্শবান। কেউ কেউ দুজন। কোনটি দেখুন

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

আপনি জিইটি ব্যবহার করেন যেখানে আপনার পোষ্ট ব্যবহার করা উচিত ছিল তা দেখুন


1
একটি বডি সহ GET আসলে অনুমান অনুসারে হয়।
ট্রিপ

মজাদার. দেখে মনে হচ্ছে এটি 2014 সালে পরিবর্তিত হয়েছিল
এসবেন স্কোভ পেডারসেন

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

2

আপনি জিইটি, পোস্ট, ইত্যাদি একই ফাংশনের ওভারলোড হিসাবে, এমনকি গেটর এবং সেটটার হিসাবেও ভাবতে পারেন।

GET_MyVar() কোনও ইনপুট প্যারাম (ওরফে দ্য রিকোয়েস্ট বডি) নেবে না, তবে কিছু ফিরিয়ে দেয়।

POST_MyVar(string blah)ইনপুট দিয়ে কিছু করে (আবার অনুরোধের বডি) এবং কিছু ফিরিয়ে দিতে পারে। (এটির জন্য কমপক্ষে একটি প্রতিক্রিয়া কোডও ফিরিয়ে নেওয়া দরকার, যাতে আমরা জানতে পারি যে ফাংশনটি রান হয়েছে !!)

DELETE_MyVar() এছাড়াও সম্ভবত কিছু নেয় না এবং প্রত্যাশিত কিছু মুছে ফেলা হয়।

হ্যাঁ, আমরা এগুলি সহ সমস্ত বাস্তবায়ন করতে পারি:
MyVar(string Action, string? blah)

এইভাবে আমরা কেবল একটি কল গ্রহণ করতে পারি এবং তারপরে অন্য কোনও প্যারামিটারের ভিত্তিতে কী করতে হবে তা বেছে নিতে পারি।

তবে এই পদ্ধতির সুবিধাগুলির মধ্যে একটি হ'ল এটি ব্রাউজার এবং সার্ভারগুলিকে এই জিনিসগুলির কাজ করার উপায়টিকে অনুকূল করে তোলার অনুমতি দেয়। উদাহরণস্বরূপ, সম্ভবত সার্ভার যেখানে সমস্ত অনুরোধগুলি ব্লক করতে চাইবে Action==DELETE। হতে পারে ব্রাউজারগুলি এমন জিনিসগুলিকে ক্যাশে করতে চায় যেখানে Action==GET.না থাকলে প্রতিটি ফাংশনে আমাদের লিখতে হবেif (Action==Delete) {return AngryFace}

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


1

এইচটিটিপি পদ্ধতি বিভিন্ন উদ্দেশ্যে পরিবেশন করে। সাধারণভাবে, GETডাউনলোডগুলির POSTজন্য এবং আপলোডগুলির জন্য।

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

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

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

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


আমি মনে করি এই ওয়েবসাইটটি একটি ওয়েবসাইটের তুলনায় গ্রেড স্তরে। "আমাকে জিইটি এবং পোস্ট প্রয়োগ করতে হবে না," তবে "ব্রাউজারগুলি জিইটি এবং পোষ্ট কেন প্রয়োগ করে"?
মঙ্গলবার

@ মারস যদি এটি হয় তবে প্রশ্নটি এই সাইটের জন্য বিষয়বস্তু নয়।
স্টিফেন অসটারমিলার

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

0

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


1
"জিইটি, পোষ্ট, পুট ইত্যাদি কেবল historicalতিহাসিক সম্মেলন" - এগুলি কোনও সম্মেলন নয়। তাদের স্পষ্টভাবে নির্দিষ্ট আচরণ রয়েছে এবং ততোধিক, তারা বিভিন্ন আচরণের স্পষ্টভাবে নির্দিষ্ট করে দিয়েছে।
Jörg ডব্লু মিট্টাগ

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

-1

আপনার প্রস্তাবিত প্রোটোকল হ্যাকারদের বিরুদ্ধে উল্লেখযোগ্যভাবে কম সুরক্ষিত হবে।

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


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