অনুরোধ বডি সহ HTTP পান

Question

আমি আমাদের অ্যাপ্লিকেশনটির জন্য একটি নতুন RESTful ওয়েবসার্ভিস বিকাশ করছি।

নির্দিষ্ট সত্তাগুলিতে জিইটি করার সময়, ক্লায়েন্টরা সত্তার সামগ্রীর জন্য অনুরোধ করতে পারে can যদি তারা কিছু প্যারামিটার যুক্ত করতে চান (উদাহরণস্বরূপ একটি তালিকা বাছাই করা) তারা ক্যোয়ারী স্ট্রিংয়ে এই পরামিতিগুলি যুক্ত করতে পারেন।

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

আমার প্রশ্নগুলো:

• এটি কি পুরোপুরি একটি ভাল ধারণা?
• এইচটিটিপি ক্লায়েন্টদের জিইটি অনুরোধের মধ্যে অনুরোধ সংস্থা ব্যবহারে সমস্যা হবে?

http://tools.ietf.org/html/rfc2616

Comments

সুবিধাটি হ'ল সহজেই এক্সএমএল বা জেএসএন অনুরোধ সংস্থা প্রেরণ করতে দেয়, এটির দৈর্ঘ্যের কোনও সীমাবদ্ধতা নেই এবং এনকোড করা সহজ (ইউটিএফ -8)।

— এভারট

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

— জুলিয়ান রেসকে

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

— Evert

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

— এভার্ট

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

— কায়রান রায়ান

Answer 1

জিইটি অনুরোধ সহ একটি বডি অন্তর্ভুক্ত করার বিষয়ে রয় ফিল্ডিংয়ের মন্তব্য ।

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

সুতরাং, হ্যাঁ, আপনি জিইটি দিয়ে কোনও দেহ পাঠাতে পারেন, এবং না, এটি করা কখনই কার্যকর নয়।

এটি এইচটিটিপি / ১.১ এর স্তরযুক্ত নকশার অংশ যা স্পেকটি ভাগ হয়ে যাওয়ার পরে আবার স্পষ্ট হয়ে উঠবে (কাজ চলছে)।

.... রায়

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

[...] যদি অনুরোধ পদ্ধতিতে কোনও সত্তা-দেহের জন্য সংজ্ঞায়িত শব্দার্থকে অন্তর্ভুক্ত না করা হয়, তবে অনুরোধটি পরিচালনা করার সময় বার্তা-বডিটি উপেক্ষা করা উচিত ।

এবং এইচটিটিপি / ১.১ অনুচ্ছেদে জিইটি পদ্ধতির বিবরণ , বিভাগ 9.3 :

জিইটি পদ্ধতিটির অর্থ অনুরোধ-ইউআরআই দ্বারা সনাক্ত করা সমস্ত তথ্য ([...]) পুনরুদ্ধার করুন।

যা জানিয়েছে যে অনুরোধ-সংস্থা কোনও জিইটি অনুরোধে সংস্থানটির সনাক্তকরণের অংশ নয়, কেবল অনুরোধ ইউআরআই।

আপডেট করুন আরএফসি 2616 "HTTP / 1.1 spec" হিসাবে উল্লেখ করা এখন অপ্রচলিত। 2014 সালে এটি আরএফসি 7230-7237 দ্বারা প্রতিস্থাপিত হয়েছিল। "অনুরোধটি পরিচালনা করার সময় বার্তাটির প্রধান অংশটি উপেক্ষা করা উচিত" মুছে ফেলা হয়েছে। এটি এখন কেবল "অনুরোধ বার্তা প্রণয়ন পদ্ধতি শব্দার্থবিজ্ঞানের তুলনায় স্বতন্ত্র, এমনকি পদ্ধতিটি কোনও বার্তার মূল অংশের জন্য কোনও ব্যবহার সংজ্ঞায়িত না করে" ২ য় উদ্ধৃতি "জিইটি পদ্ধতি মানে যা কিছু তথ্য পুনরুদ্ধার করা ... অনুরোধ-ইউআরআই দ্বারা চিহ্নিত" মুছে ফেলা হয়েছে। - একটি মন্তব্য থেকে

Comments

হ্যাঁ, আপনার দুটি ভাঙার সবচেয়ে বেশি সম্ভাবনা যা ক্যাচিং / প্রক্সিং। "শব্দার্থবিজ্ঞান" বলার আরও একটি উপায় যা "অন্যান্য উপাদানগুলি তৈরি করে এমন লোকেরা যেভাবে অন্যান্য উপাদানগুলি পরিচালনা করার আশা করে"। আপনি যদি শব্দার্থবিজ্ঞান লঙ্ঘন করেন তবে আপনি এমন জায়গাগুলিতে জিনিসপত্র ভাঙ্গার সম্ভাবনা বেশি পাবেন যেখানে লোকেরা এমন জিনিস লিখেছিল যা প্রত্যাশা করে যে আপনি সে শব্দার্থিকদের সম্মান করছেন।

— স্টুয়ার্ট পি। বেন্টলে

ইলাস্টিকসার্ক মোটামুটি বড় পণ্য যা জিইটি-তে এইচটিটিপি অনুরোধ সংস্থা ব্যবহার করে। তাদের ম্যানুয়াল অনুসারে কোনও এইচটিটিপি অনুরোধে কোনও দেহ থাকার বিষয়ে সমর্থন করা উচিত কিনা তা অপরিজ্ঞাত। আমি জিইটি অনুরোধের বডিটি জনসাধারণের সাথে ব্যক্তিগতভাবে স্বাচ্ছন্দ্যবোধ করি না তবে তাদের মতামত আলাদা বলে মনে হয় এবং তারা কী করছে তা তাদের অবশ্যই জেনে রাখা উচিত। elastic.co/guide/en/elasticsearch/guide/current/…

— গর্ডনএম

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

— এমিল লুন্ডবার্গ

"HTTP / 1.1 spec" হিসাবে উল্লেখ করা আরএফসি 2616 এখন অপ্রচলিত। 2014 সালে এটি আরএফসি 7230-7237 দ্বারা প্রতিস্থাপিত হয়েছিল। " অনুরোধটি পরিচালনা করার সময় বার্তাটির প্রধান অংশটি উপেক্ষা করা উচিত " মুছে ফেলা হয়েছে । এটি এখন কেবল " অনুরোধ বার্তা প্রণয়ন পদ্ধতি শব্দার্থবিজ্ঞানের তুলনায় স্বতন্ত্র, এমনকি পদ্ধতিটি কোনও বার্তার মূল অংশের জন্য কোনও ব্যবহার সংজ্ঞায়িত না করে " ২ য় উদ্ধৃতি " জিইটি পদ্ধতি মানে যা কিছু তথ্য পুনরুদ্ধার করা ... অনুরোধ-ইউআরআই দ্বারা চিহ্নিত " ছিল মোছা । সুতরাং, আমি @ জার্ল

— আর্টেম নাকনটেকেনি

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

— 39

Answer 2

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

দৃust়তা নীতির পিছনে এই মনোভাবটি মোটামুটি "আপনি যা গ্রহণ করেন তাতে উদার হন, এবং আপনি যা প্রেরণ করেন তাতে রক্ষণশীল", আপনি কোনও কারণ ছাড়াই কোনও নির্দিষ্টকরণের সীমানাকে ঠেলাতে চান না।

তবে, আপনার যদি কোনও ভাল কারণ থাকে তবে এটির জন্য যান।

Comments

দৃust়তা নীতি ত্রুটিযুক্ত। আপনি যা গ্রহণ করেন তাতে যদি উদার হন তবে আপনি বাজেয়াপ্ত গ্রহণের কারণেই গ্রহণযোগ্যতার ক্ষেত্রে যদি আপনার কোনও সাফল্য পান তবে আপনি বকাবকি পাবেন। এটি আপনার ইন্টারফেসটি বিকশিত করা আরও শক্ত করে তুলবে। শুধু এইচটিএমএল তাকান। এটি কার্যত প্রত্যাখ্যান নীতি principle

— ইউজিন বেরেসভস্কি

আমি মনে করি প্রোটোকলগুলির গ্রহণ (এবং অপব্যবহার) এর সাফল্য এবং প্রস্থতা দৃ rob়তা নীতির মানকে বোঝায়।

— ক্যাসকি

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

— ইউজিন বেরেসভস্কি

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

— ক্রিশ্চান পাইটশ

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

— ক্যাসকি 21

Answer 3

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

Comments

ইটাগ / সর্বশেষ-সংশোধিত শিরোলেখ ক্ষেত্রগুলি এই উপায়ে সহায়তা করে: যখন "শর্তসাপেক্ষে জিইটি" ব্যবহার করা হয়, তখন প্রক্সি / ক্যাশে এই তথ্যটিতে কাজ করতে পারে।

— jldupont

@ jldupont ক্যাশেগুলি বাসি প্রতিক্রিয়াটিকে পুনরায় যাচাই করা যেতে পারে কিনা তা জানতে বৈধদের উপস্থিতি ব্যবহার করে, তবে সেগুলি প্রাথমিক বা গৌণ ক্যাশে কী এর অংশ হিসাবে ব্যবহৃত হয় না।

— ড্যারেল মিলার

আপনি কোনও ক্যোয়ারী প্যারামিটারে শরীরের চেকসাম দিয়ে এটি ঠিক করতে পারেন

— অ্যাড্রিয়ান মে

Answer 4

আমরাও restclient কিংবা বিশ্রাম কনসোল এই সমর্থন কিন্তু কার্ল করে।

HTTP- র স্পেসিফিকেশন অধ্যায় 4.3 বলেছেন

অনুরোধ পদ্ধতির স্পেসিফিকেশন (বিভাগ 5.1.1) অনুরোধে কোনও সত্তা-দেহ প্রেরণের অনুমতি না দিলে একটি বার্তা-বডি একটি অনুরোধে অন্তর্ভুক্ত করা উচিত নয়।

বিভাগ 5.1.1 বিভিন্ন পদ্ধতির জন্য আমাদের বিভাগ 9.x এ পুনঃনির্দেশ করে। এর মধ্যে কোনও স্পষ্টভাবে কোনও বার্তার বডির অন্তর্ভুক্তিকে নিষিদ্ধ করে। যাহোক...

বিভাগ 5.2 বলছে

একটি ইন্টারনেট অনুরোধ দ্বারা চিহ্নিত সঠিক সংস্থানটি অনুরোধ-ইউআরআই এবং হোস্ট শিরোনাম ক্ষেত্র উভয়ই পরীক্ষা করে নির্ধারিত হয়।

এবং বিভাগ 9.3 বলছে

জিইটি পদ্ধতিটির অর্থ অনুরোধ-ইউআরআই দ্বারা চিহ্নিত যে কোনও তথ্য (সত্তার আকারে) সনাক্ত করা।

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

সংক্ষেপে, এইচটিটিপি অনুমান আপনাকে জিইটি-র সাথে মেসেজ-বডি পাঠাতে বাধা দেয় না তবে পর্যাপ্ত অস্পষ্টতা রয়েছে যে এটি যদি সমস্ত সার্ভার দ্বারা সমর্থন না করে তবে আমাকে অবাক করে না।

Comments

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

— এস ডানিয়েল

"জিইটি পদ্ধতিটির অর্থ অনুরোধ-ইউআরআই দ্বারা চিহ্নিত যে কোনও তথ্য (সত্তার আকারে) সনাক্ত করা।" তাহলে, সমস্ত সত্তা প্রাপ্ত জিইটি শেষ পয়েন্টটি কি প্রযুক্তিগতভাবে অবৈধ / ভুল? যেমন GET /contacts/100/addressesব্যক্তির জন্য ঠিকানাগুলির সংকলন প্রদান করে id=100।

— জোশ এম।

REST API গুলি পরীক্ষার জন্য বিশ্রামিত জাভা গ্রন্থাগার কোনও বডি সহ জিইটি অনুরোধ সমর্থন করে না। অ্যাপাচি এইচটিটিপি ক্লায়েন্ট এটি সমর্থন করে না।

— পাওলো মেরসন

জাজানোও জিইটি বডি পার্সিং সমর্থন করে

— ব্রুনো ফিঙ্গার

Answer 5

ইলাস্টিকসার্ক একটি বডি সহ জিইটি অনুরোধ গ্রহণ করে। এমনকি এটি মনে হয় যে এটি পছন্দসই উপায়: ইলাস্টিকসার্ক গাইড

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

Comments

ইলাস্টিকসার্ক কেন এটি অনুমতি দেয় তা ভাবছিল। তার মানে এই প্রশ্নের সাথে একটি GET অনুরোধ পে লোড সঙ্গে সব কাগজপত্র গণনা curl -XGET 'http://localhost:9200/_count?pretty' -d ' { "query": { "match_all": {} } }' যেমন পে লোড সহ সমতূল্য sourcePARAM: curl -XGET 'http://localhost:9200/_count?pretty&source=%7B%22query%22%3A%7B%22match_all%22%3A%7B%7D%7D%7D'

— অরুণ

জটিল প্রশ্নগুলি http শিরোনাম সর্বাধিক দৈর্ঘ্যে হিট করতে পারে।

— s.Daniel

এটি স্থিতিস্থাপক ডকুমেন্টেশন পড়ছিল যা আমাকে এই প্রশ্নে নিয়ে গিয়েছিল কারণ আমি ভেবেছিলাম কোনও শরীরকে অন্তর্ভুক্ত করা খারাপ অভ্যাস হিসাবে বিবেচিত হয়েছিল

— প্যাট্রিকওয়াকার

এটি একটি জটিল ক্যোয়ারী করা প্রয়োজন হয় না। এমনকি একটি সাধারণ স্ক্রোল খুব দীর্ঘ স্ক্রোল_আইডি (অনেকগুলি শারড সহ একটি ক্লাস্টারে) ফিরিয়ে দিতে পারে, যা সেখানে যুক্ত হলে সর্বোচ্চ url দৈর্ঘ্যকে ছাড়িয়ে যাবে।

— ব্রেন্ট হ্রোনিক

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

— ডিএসও

Answer 6

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

আপনি কেবল আপনার নির্দিষ্ট অনুসন্ধানের মিডিয়াটাইপ তৈরি করতে পারেন, বা আপনি যদি আরও বিশ্রামপ্রাপ্ত হতে চান তবে ওপেন সন্ধানের মতো কিছু ব্যবহার করুন এবং সার্ভারের নির্দেশিত ইউআরআই-এর কাছে অনুরোধটি পোস্ট করুন / বলুন search সার্ভারটি অনুসন্ধানের ফলাফল তৈরি করতে পারে বা চূড়ান্ত ইউআরআই তৈরি করতে পারে এবং 303 ব্যবহার করে পুনর্নির্দেশ করতে পারে।

তিহ্যবাহী পিআরজি পদ্ধতি অনুসরণ করার সুবিধা রয়েছে, মধ্যস্থতাকারীদের ফলাফল ক্যাশে করতে সহায়তা করে ইত্যাদি has

এটি বলেছিল যে, ইউএসআইগুলি যে কোনও কিছুতেই ASCII নয় এর জন্য এনকোড করা আছে এবং তাই অ্যাপ্লিকেশন / এক্স-www-ফর্ম-urlncoded এবং মাল্টিপার্ট / ফর্ম-ডেটা রয়েছে। আপনার উদ্দেশ্যটি যদি বিশ্রামের পরিস্থিতিতে সমর্থন করার উদ্দেশ্যে থাকে তবে আমি আর একটি কাস্টম জসন ফর্ম্যাট তৈরি না করে এটি ব্যবহার করার পরামর্শ দেব।

Comments

আপনি কেবল আপনার নির্দিষ্ট অনুসন্ধানের মিডিয়াটাইপ তৈরি করতে পারেন আপনি কী আরও বিস্তারিত বলতে পারবেন?

— পাইওটর ডব্রোগস্ট

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

— সিরিয়ালসেব

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

— ফিজিয়াআরন

Answer 7

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

উভয়ই দুর্দান্ত সিদ্ধান্ত নয়, তবে একটি জিইটি বডি পাঠানো কিছু ক্লায়েন্ট - এবং কিছু সার্ভারগুলির জন্য সমস্যা প্রতিরোধ করতে পারে।

একটি পোস্ট করতে কিছু রিস্টিশ ফ্রেমওয়ার্কগুলিতে বাধা থাকতে পারে।

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

এটি এমন ক্লায়েন্টদের তালিকাবদ্ধ করা সবচেয়ে উত্পাদনশীল হতে পারে যা উপরের প্রতিটিটি করতে পারে এবং করতে পারে না।

ক্লায়েন্টগুলি যা শরীরের সাথে একটি জিইটি পাঠাতে পারে না (যা আমি জানি):

• এক্সএমএলএইচটিপিআরকিউস্ট ফিডলার

শরীরের সাথে একটি জিইটি পাঠাতে পারে এমন ক্লায়েন্টগুলি:

• সর্বাধিক ব্রাউজার

জিইটি থেকে কোনও দেহ পুনরুদ্ধার করতে পারে এমন সার্ভারস এবং লাইব্রেরি:

• এ্যাপাচি
• পিএইচপি

জিইটি থেকে কোনও শরীরে ফেলা সার্ভারগুলি (এবং প্রক্সিগুলি):

• ?

Comments

স্কোয়াড ৩.১..6 এছাড়াও সামগ্রী-দৈর্ঘ্য 0 সেট করা না থাকলে সেট করে

— দেহগুলি জিট করে

ফিডলারের ইচ্ছা, তবে এটি আপনাকে সতর্ক করে।

— টুডমো

আপনি কি বলছেন যে কোনও SEARCHপদ্ধতি সম্ভবত সেই পথেই ভেঙে যাবে? প্রক্সীরা যদি কোনও পদ্ধতি বুঝতে না পারে, তবে তারা এটি যেমনটি পাস করবে বলে আশা করা হচ্ছে, তাই আপনি কেন এটি কিছু ভেঙে ফেলবেন বলে আমি খুব বেশি নিশ্চিত নই ...

— অ্যালেক্সিস উইলক

Answer 8

আমি এই প্রশ্নটি আইইটিএফ এইচটিটিপি ডব্লিউজির কাছে রেখেছি। রায় ফিল্ডিংয়ের মন্তব্য (1998 সালে http / 1.1 নথির লেখক) তা ছিল

"... একটি বাস্তবায়ন ভেঙে দেওয়া ছাড়া আর কিছু করার ব্যর্থ হবে এবং যদি সেই শরীরটি পেয়ে যায় তবে তা বাতিল করতে হবে"

আরএফসি 7213 (এইচটিটিপিবিস) বলেছেন:

"একটি জিইটি অনুরোধ বার্তার মধ্যে পে-লোডের কোনও নির্ধারিত শব্দার্থবিজ্ঞান নেই;"

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

সেখানে প্রক্সি রয়েছে যা আপনি জিইটি-তে কোনও দেহ অন্তর্ভুক্ত করলে অবশ্যই বিভিন্নভাবে আপনার অনুরোধটি ভেঙে দেবে ।

সুতরাং সংক্ষেপে, এটি করবেন না।

Answer 9

কোন সার্ভার এটিকে উপেক্ষা করবে? - ফিজিয়ারাওন 30 আগস্ট '12 এ 21:27 এ

উদাহরণস্বরূপ গুগল এটিকে উপেক্ষা করার চেয়ে খারাপ করছে, এটি এটিকে ত্রুটি হিসাবে বিবেচনা করবে !

একটি সাধারণ নেটকেট দিয়ে নিজে চেষ্টা করে দেখুন:

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

(1234 সামগ্রীটি সিআর-এলএফ দ্বারা অনুসরণ করা হয়, সুতরাং এটি মোট 6 বাইট)

এবং আপনি পাবেন:

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

আপনি বিং, অ্যাপল ইত্যাদির কাছ থেকেও 400 টি বাজে অনুরোধ পাবেন ... যা আকামাইগোস্ট দ্বারা পরিবেশিত হয়।

সুতরাং আমি কোনও দেহ সত্তার সাথে জিইটি অনুরোধগুলি ব্যবহার করার পরামর্শ দেব না।

Comments

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

— পেসারিয়ার

এটি একটি খারাপ অনুরোধ, কারণ আপনার GET নির্দিষ্ট পরিমাণের জন্য নির্দিষ্ট পরিমাণের জন্য আপনার পেডলোড প্রত্যাশিত নয় (বা বুদ্ধিমানের) - GETসাধারণ ক্ষেত্রে এটির ব্যবহারের সাথে কোনও সম্পর্ক নেই । কোনও এলোমেলো পে-লোড POSTঠিক তত সহজেই ভেঙে দিতে পারে এবং একই জিনিসটি ফিরে আসতে পারে, 400 Bad Requestযদি বিষয়বস্তু নির্দিষ্ট অনুরোধের প্রসঙ্গে বিন্যাসে না আসে।

— নোটার

এবং শুধুমাত্র সামগ্রিকভাবে এই শেষ পয়েন্টে নয়, বরং সেই নির্দিষ্ট ইউআরএলটিতে ।

— লরেন্স ডল

এটি অপ্রাসঙ্গিক কারণ এটি কেবলমাত্র URL- এ গুগলের সার্ভার প্রয়োগকরণ। সুতরাং প্রশ্নটির কোনও অর্থ নেই

— জোয়েল ডাকওয়ার্থ

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

— স্ক্রিমাউ

Answer 10

থেকে বোঝায় যা RFC 2616, বিভাগ 4.3 , "বার্তা দেহ":

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

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

এটি উপরের ফিল্ডিংয়ের উদ্ধৃতি অনুসারে।

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

Comments

বিভাগ 9.5 , "পোস্ট"-তে অনুরোধ সংস্থাগুলিরও উল্লেখ করা হয়নি, সুতরাং এই যুক্তিটি ত্রুটিযুক্ত।

— কার্লুভা

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

— ফ্রেডেরিক্ফ

Answer 11

এক্সএমএলএইচটিপিআরকিউস্টের মতে, এটি বৈধ নয়। মান থেকে :

4.5.6 send()পদ্ধতি

client . send([body = null])

অনুরোধ শুরু করে। Alচ্ছিক যুক্তি অনুরোধের শরীর সরবরাহ করে। অনুরোধের পদ্ধতিটি থাকলে GETবা যুক্তি উপেক্ষা করা হয় HEAD।

একটি ছোঁড়ার InvalidStateErrorব্যতিক্রম যদি হয় রাষ্ট্র নয় খোলা বা send()পতাকা সেট করা হয়।

পদ্ধতি ধাপগুলি চালানো হবে:send(body)

1. যদি রাষ্ট্র না খোলা থাকে তবে একটি InvalidStateErrorব্যতিক্রম নিক্ষেপ করুন ।
2. তাহলে send()পতাকা সেট করা থাকে, একটি নিক্ষেপ InvalidStateErrorব্যতিক্রম।
3. যদি অনুরোধের পদ্ধতিটি হয় GETবা হয় তবে বডিটি শুল্কে HEADসেট করুন ।
4. যদি শরীরটি নাল হয় তবে পরবর্তী পদক্ষেপে যান।

যদিও, আমি মনে করি না এটি করা উচিত কারণ জিইটি অনুরোধের জন্য বড় বডি কনটেন্টের প্রয়োজন হতে পারে।

সুতরাং, আপনি যদি কোনও ব্রাউজারের এক্সএমএলএইচটিএইচপিটার উপর নির্ভর করেন তবে সম্ভবত এটি কাজ করবে না।

Comments

এক্সএমএলএইচটিপিআরকোয়েস্ট বাস্তবায়ন হ'ল এই কারণে নিম্নোক্ত। এটি বাস্তবায়ন করার জন্য প্রকৃত স্পেসিফিকেশনটিকে প্রতিফলিত করতে পারে না।

— floum

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

— pjcard

Answer 12

আপনি যদি সত্যিই ক্যাচেবল জেএসএন / এক্সএমএল বডিটি ওয়েব অ্যাপ্লিকেশনটিতে প্রেরণ করতে চান তবে আপনার ডেটা রাখার একমাত্র যুক্তিসঙ্গত জায়গা হল কোয়েরি স্ট্রিং দিয়ে এনকোড করা ক্যাচেবল জেএসএন আরএফসি 4648 এনকোডযুক্ত : ইউএসএল এবং ফাইলের নাম নিরাপদ বর্ণমালা দিয়ে বেস 64 এনকোডিং । অবশ্যই আপনি JSON- কে ইউলিনকোড করতে পারেন এবং ইউআরএল প্যারামের মানতে রেখেছেন তবে বেস 64 কম ফলাফল দেয়। মনে রাখবেন যে ইউআরএল আকারের বিধিনিষেধ রয়েছে, দেখুন বিভিন্ন ব্রাউজারে কোনও URL এর সর্বোচ্চ দৈর্ঘ্য কত? ।

আপনি ভাবতে পারেন যে বেস 64 এর প্যাডিং =চরিত্রটি ইউআরএল এর প্যারাম মানের জন্য খারাপ হতে পারে, তবে এটি মনে হয় না - এই আলোচনাটি দেখুন: http://mail.python.org/pipermail/python-bugs-list/2007-Feb February / 037195.html । তবে আপনাকে প্যারাম নাম ছাড়াই এনকোডড ডেটা রাখা উচিত নয় কারণ প্যাডিং সহ এনকোডড স্ট্রিংটি খালি মান সহ প্যারাম কী হিসাবে ব্যাখ্যা করা হবে। আমি এরকম কিছু ব্যবহার করব ?_b64=<encodeddata>।

Comments

আমি মনে করি এটি একটি খুব খারাপ ধারণা :) তবে আমি যদি এইরকম কিছু করতে চাইতাম তবে আমি পরিবর্তে একটি কাস্টম এইচটিটিপি শিরোনাম ব্যবহার করব (এবং নিশ্চিত করে রাখি যে আমি সর্বদা ভেরিকে ফেরত পাঠিয়েছি: প্রতিক্রিয়াতে)।

— এভার্ট

খারাপ বা না তবে করণীয় :) শিরোলেখের সাথে ডেটা আকারের সাথে একই সমস্যা রয়েছে, দেখুন স্ট্যাকওভারফ্লো / প্রশ্নগুলি / 6686১২7//২ । তবে Varyশিরোনাম উল্লেখ করার জন্য ধন্যবাদ , আমি এর বাস্তব সম্ভাবনা সম্পর্কে সচেতন ছিলাম না।

— জার্মটাস

Answer 13

আমি এটি পরামর্শ দেব না, এটি স্ট্যান্ডার্ড অনুশীলনের বিরুদ্ধে যায় এবং এর বিনিময়ে তেমন প্রস্তাব দেয় না। আপনি বিকল্পগুলি নয়, সামগ্রীতে শরীর রাখতে চান keep

Answer 14

বেস কনফর্মিং বেস 64 এনকোডড শিরোনামগুলি সম্পর্কে কী? "SOMETHINGAPP-প্যারাম: sdfSD45fdg45 / হিসাবে"

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

Comments

x-উপসর্গের সাথে আপনি যে কোনও প্যারামিটারগুলি প্রেরণ করতে পারেন , শিরোনামের দৈর্ঘ্যের কোনও সীমা সম্পূর্ণরূপে একটি সার্ভার স্বেচ্ছাসেবী সীমা হতে পারে।

— ক্রিস মেরিসিক

Answer 15

প্রোটোকল যেমন ওওপি সমর্থন করে না এবং তাই আমি বিরক্ত Get পদ্ধতির প্রমাণ proof সমাধান হিসাবে, আপনি আপনার ডিটিওকে জেএসএনে ক্রমিক করতে পারেন এবং তারপরে একটি কোয়েরি স্ট্রিং তৈরি করতে পারেন। সার্ভারে আপনি কোয়েরি স্ট্রিংটি ডিটিও-তে deserialize করতে সক্ষম হবেন।

একবার দেখুন:

• পরিষেবা স্ট্যাকে বার্তা-ভিত্তিক নকশা design
• WCF- এর সাথে RESTful বার্তা ভিত্তিক ওয়েব পরিষেবাদি তৈরি করা

বার্তা ভিত্তিক পদ্ধতি আপনাকে পদ্ধতির সীমাবদ্ধতা সমাধানে সহায়তা করতে পারে। আপনি অনুরোধ বডি হিসাবে যে কোনও ডিটিও পাঠাতে সক্ষম হবেন

নেলিবার ওয়েব পরিষেবা কাঠামো কার্যকারিতা সরবরাহ করে যা আপনি ব্যবহার করতে পারেন

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

Comments

আপনার কেবল পোস্ট ব্যবহার করা উচিত। Url এ যদি কোনও পদ্ধতির নাম থাকে তবে আপনি মৌলিক বিশ্রামের নকশা লঙ্ঘন করছেন। এটি আরপিসি, পোষ্ট ব্যবহার করুন।

— এভার্ট

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

— জিএসেরজো

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

— shmish111

না, আমি কেবল আরও কিছুটা দেখতে পেলাম না

— GSerjo

Answer 16

উদাহরণস্বরূপ, এটি কার্ল, অ্যাপাচি এবং পিএইচপি সহ কাজ করে।

পিএইচপি ফাইল:

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

কনসোল আদেশ:

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

আউটপুট:

GET
{"the": "body"}

Comments

মজাদার পরীক্ষা! পিএইচপি কেবল তখনই পড়তে পারে $_POSTযখন কোনও পোস্টের অনুরোধের সাথে লাশ প্রেরণ করা হয় এবং application/x-www-form-urlencoded। তার মানে একটি GETঅনুরোধে দেহটিকে উপেক্ষা করা হবে । এই ক্ষেত্রে: $_GETএবং $_POSTএই মুহুর্তে যাইহোক খুব বিভ্রান্তিকর হয়। আরও ভাল ব্যবহারphp://input

— মার্টিন মুজতকো

Answer 17

IMHO আপনি কেবল JSONএনকোডযুক্ত (যেমন। encodeURIComponent) প্রেরণ করতে পারেন URL, এইভাবে আপনি HTTPচশমা লঙ্ঘন করবেন না এবং JSONসার্ভারে নিজের পাবেন।

Comments

হ্যাঁ তবে প্রধান সমস্যাটি দৈর্ঘ্যের সীমাটি, আমরা কীভাবে এটি মোকাবেলা করব?

— সেবাস

Answer 18

আপনার কাছে বিকল্পগুলির একটি তালিকা রয়েছে যা জিইটি সহ একটি অনুরোধ বডি ব্যবহার করার চেয়ে অনেক ভাল।

ধরে নেওয়া যাক প্রতিটি বিভাগের জন্য আপনার কাছে বিভাগ এবং আইটেম রয়েছে। উভয়ই একটি আইডি দ্বারা চিহ্নিত করা ("উদাহরণস্বরূপ" ক্যাটিড "/" আইটেমিড ")। আপনি একটি নির্দিষ্ট "ক্রম" এর মধ্যে অন্য "পরামিতি" পরামিতি অনুসারে বাছাই করতে চান। আপনি "সাজ্টবাই" এবং "অর্ডার" এর জন্য পরামিতিগুলি পাস করতে চান:

আপনি পারেন:

1. ক্যোয়ারী স্ট্রিংগুলি ব্যবহার করুন, যেমন example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc
2. পাথের জন্য মোড_উইরাইট (বা অনুরূপ) ব্যবহার করুন: example.com/category/{catid}/item/{itemid}/{sortby}/{order}
3. আপনি অনুরোধটি সহ স্বতন্ত্র HTTP শিরোনাম ব্যবহার করুন
4. একটি উত্স পুনরুদ্ধার করতে একটি আলাদা পদ্ধতি, যেমন POST ব্যবহার করুন।

সকলেরই ডাউনসাইড রয়েছে তবে শরীরের সাথে জিইটি ব্যবহারের চেয়ে অনেক বেশি ভাল।

Answer 19

এমনকি যদি কোনও জনপ্রিয় সরঞ্জাম এটি ব্যবহার করে, যেমন এই পৃষ্ঠায় প্রায়শই উদ্ধৃত করা হয়, তবে আমি অনুভব করি যে এটি অনুপযুক্ত না থাকা সত্ত্বেও এটি খুব খারাপ ধারণা too

অনেক মধ্যবর্তী অবকাঠামো কেবল এই জাতীয় অনুরোধগুলি প্রত্যাখ্যান করতে পারে।

উদাহরণের মাধ্যমে, আপনার ওয়েব সাইট সামনে প্রাপ্তিসাধ্য যা CDN কয়েকটি ব্যবহার ভালো কথা ভুলে এক :

যদি দর্শকের GETঅনুরোধটিতে কোনও সংস্থা অন্তর্ভুক্ত থাকে তবে ক্লাউডফ্রন্ট দর্শকের কাছে একটি HTTP স্থিতি কোড 403 (নিষিদ্ধ) প্রদান করে।

এবং হ্যাঁ, আপনার ক্লায়েন্টের গ্রন্থাগারগুলিও এই মন্তব্যে যেমন রিপোর্ট করা হয়েছে তেমন অনুরোধ প্রেরণকে সমর্থন করতে পারে না ।

Answer 20

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

কিন্তু, দুঃখের বিষয়, এটি কাজ করছে না! সার্ভার-সাইড নিম্নলিখিত ব্যতিক্রম ছুঁড়ে ফেলেছে:

org.springframework.http.converter.HttpMessageNotReadableException: প্রয়োজনীয় অনুরোধের শরীরটি অনুপস্থিত ...

তবে আমি পুরোপুরি নিশ্চিত যে আমার ক্লায়েন্ট কোড দ্বারা বার্তাটির দেহটি সঠিকভাবে সরবরাহ করা হয়েছে, তবে কী সমস্যা?

আমি রেস্টটেম্পলেট.এক্সচেঞ্জ () পদ্ধতিতে সনাক্ত করে নিম্নলিখিতটি পেয়েছি:

// SimpleClientHttpRequestFactory.class
public class SimpleClientHttpRequestFactory implements ClientHttpRequestFactory, AsyncClientHttpRequestFactory {
    ...
    protected void prepareConnection(HttpURLConnection connection, String httpMethod) throws IOException {
        ...
        if (!"POST".equals(httpMethod) && !"PUT".equals(httpMethod) && !"PATCH".equals(httpMethod) && !"DELETE".equals(httpMethod)) {
            connection.setDoOutput(false);
        } else {
            connection.setDoOutput(true);
        }
        ...
    }
}

// SimpleBufferingClientHttpRequest.class
final class SimpleBufferingClientHttpRequest extends AbstractBufferingClientHttpRequest {
    ...
    protected ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        ...
        if (this.connection.getDoOutput() && this.outputStreaming) {
            this.connection.setFixedLengthStreamingMode(bufferedOutput.length);
        }

        this.connection.connect();
        if (this.connection.getDoOutput()) {
            FileCopyUtils.copy(bufferedOutput, this.connection.getOutputStream());
        } else {
            this.connection.getResponseCode();
        }
        ...
    }
}

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

তবে, রেজিস্ট্রেশন () এর কারণে, এক্সিকিউটিভ ইন্টার্নাল () এ getDoOutput () সর্বদা মিথ্যা দেয় যা ফলস্বরূপ, বাফারড আউটপুটটিকে সম্পূর্ণ উপেক্ষা করে! এটি আউটপুট স্ট্রিমে অনুলিপি করা হয়নি।

ফলস্বরূপ, আমার সার্ভার প্রোগ্রামটি কোনও বার্তা না পেয়ে এই ব্যতিক্রমটি ছুঁড়ে ফেলেছে।

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

Comments

আপনি এখানে অনুমান বা মন্তব্যগুলি সঠিকভাবে পড়ছেন না। ক্লায়েন্ট এবং সার্ভারগুলি অনুরোধের বডি ছাড়ছে তা অনুমানের মধ্যে রয়েছে। জিইটি অনুরোধ সংস্থাটি ব্যবহার করবেন না।

— এভারট

@ এভার আমি মন্তব্যগুলি সঠিকভাবে পড়িনি বা আপনি করেননি? :) আপনি যদি পল মরগানের জবাব (শীর্ষের উত্তরের উত্তর) পর্যন্ত স্ক্রোল করেন এবং মন্তব্যগুলি মনোযোগ সহকারে পড়েন তবে আপনি এটি দেখতে পাবেন: "আরএফসি 2616" HTTP / 1.1 স্পেস "হিসাবে উল্লেখ করা এখন অপ্রচলিত। 2014 সালে এটি প্রতিস্থাপন করা হয়েছিল আরএফসি 7230-7237। "অনুরোধটি পরিচালনা করার সময় বার্তাটির প্রধান অংশটি উপেক্ষা করা উচিত" মুছে ফেলা হয়েছে It's এটি এখন কেবল "অনুরোধ বার্তার ফ্রেমিং পদ্ধতি শব্দার্থবিজ্ঞানের তুলনায় স্বতন্ত্র, এমনকি পদ্ধতিটি কোনও বার্তার বডিটির জন্য কোনও ব্যবহার সংজ্ঞায়িত না করেও mant ... "

— ঝু

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

— চাউ

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

— চাউ

আমি আপনার জবাব হ্রাস করা হয়নি। আমি শুধু সে বিষয়ে পরিষ্কারভাবে বর্ণনা করছি যে কোনো HTTP- র বাস্তবায়ন ড্রপ পেতে অনুরোধ হল বৈশিষ্ট হবে।

— এভার্ট