পুট এবং ডিলিট এইচটিটিপি অনুরোধ পদ্ধতিগুলির কী কী কার্যকারিতা?


91

আমি এ সম্পর্কে প্রচুর স্টাফ পড়েছি তবে এই বিষয়টিতে উপসংহার পেতে সক্ষম হয়েছি।

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


4
PUT / DELETE কোড করা সহজ, তবে সেটআপ করা শক্ত (সুরক্ষা অনুসারে - vhost / apache ডিরেক্টরি)। আমার নম্র মতামত ... আপনি এগুলি ছাড়া বাঁচতে পারেন।
নাজেজারো

4
@ নাজ্জারো হ্যাঁ আমি এগুলি ব্যতীত অত্যন্ত খুশি :) তবে তারা কেন সেখানে রয়েছে তার কিছু উত্তর দরকার ?? কিছু স্টাফ পড়েছে তবে তা
কপি

উত্তর:


89

মোছা হ'ল অনুরোধের উত্স মুছে ফেলার জন্য:

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

PUT সার্ভারে একটি সংস্থান স্থাপন বা আপডেট করার জন্য:

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

সম্পূর্ণ স্পেসিফিকেশন দর্শন জন্য:

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

POST http://example.com/order/1/delete

বা আরও খারাপ

POST http://example.com/deleteOrder/id/1

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

সুতরাং ওয়েব সার্ভারে কোনও রিসোর্স মুছতে আপনি কল করবেন

DELETE http://example.com/order/1

এবং এটি আপডেট করার জন্য আপনি কল করবেন

PUT http://example.com/order/1

এবং ওয়েবসারভার প্রয়োগ করার জন্য পিটি বডি-তে আপডেট হওয়া রিসোর্স রিপ্রেজেন্টেশন সরবরাহ করুন।

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

আরও কিছু বিশদ জানতে এখানে যান:


7
ব্রাউজারগুলি জাভাস্ক্রিপ্টের সাথে পুট এবং ডিলেট পাঠাতে পারে !
জো

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

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

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

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

26

এইচটিটিপি অনুরোধ ক্রিয়া যেমন জিইটি, পোস্ট, ডিলেট, পুট ইত্যাদি ব্যবহার করে আপনাকে বিশ্রামের ওয়েব অ্যাপ্লিকেশন তৈরি করতে সক্ষম করে। এটি সম্পর্কে এখানে পড়ুন: http://en.wikedia.org/wiki/RepLiveational_state_transfer

এর থেকে সুবিধাগুলি দেখার সহজ উপায় হ'ল এই উদাহরণটি দেখুন। প্রতিটি এমভিসি ফ্রেমওয়ার্কের একটি রয়েছে Router/Dispatcherযা অ্যাকশনকন্ট্রোলারগুলিতে ইউআরএল-গুলি ম্যাপ করে। সুতরাং এর মতো ইউআরএল: /blog/article/1প্রার্থনা করবে blogController::articleAction($id); এখন এই রাউটারটি কেবল URL বা সচেতন of/blog/article/1/

তবে যদি রাউটারটি কেবল URL টির পরিবর্তে পুরো এইচটিটিপি রিকোয়েস্টের অবজেক্ট সম্পর্কে সচেতন থাকে তবে তার বর্তমান এইচটিটিপি অনুরোধ সম্পর্কে HTTP রিকোয়েস্ট ক্রিয়া (GET, POST, PUT, DELETE ...) এবং আরও অনেক দরকারী স্টাফ অ্যাক্সেস থাকতে পারে।

এটি আপনাকে অ্যাপ্লিকেশনটি কনফিগার করতে সক্ষম করবে যাতে এটি একই URL টি গ্রহণ করে এবং এটি HTTP অনুরোধ ক্রিয়াটির উপর নির্ভর করে বিভিন্ন ক্রিয়াকলাপগুলিতে ম্যাপ করতে পারে।

উদাহরণ স্বরূপ:

আপনি যদি নিবন্ধ 1 পুনরুদ্ধার করতে চান তবে আপনি এটি করতে পারেন:

GET /blog/article/1 HTTP/1.1

তবে আপনি যদি নিবন্ধ 1 মুছতে চান তবে আপনি এটি করবেন:

DELETE /blog/article/1 HTTP/1.1

লক্ষ্য করুন যে উভয়ই HTTP অনুরোধের একই ইউআরআই, / ব্লগ / নিবন্ধ / 1 রয়েছে, কেবলমাত্র পার্থক্যটি এইচটিটিপি অনুরোধ ক্রিয়া। এবং সেই ক্রিয়াটির উপর ভিত্তি করে আপনার রাউটার বিভিন্ন অ্যাকশনকন্ট্রোলারকে কল করতে পারে। এটি আপনাকে পরিষ্কার URL- গুলি তৈরি করতে সক্ষম করে ables

এই দুটি নিবন্ধ পড়ুন, তারা আপনাকে সহায়তা করতে পারে:

সিমফনি 2 - এইচটিটিপি ফান্ডামেন্টাল

সিমফনি 2 - রাউটিং

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

আশাকরি এটা সাহায্য করবে!


6
যদিও আমি তাদের বন্ধু নই, সুন্দরভাবে +1 ;-) ব্যাখ্যা করেছেন
নাজ্জারো

4
এই উত্তরটি HTTP ক্রিয়াগুলির সত্যতা এবং সত্যিকারের RESTful পরিষেবাদি এবং তাদের সুবিধার সাথে সামঞ্জস্য রেখে তার গুরুত্ব বর্ণনা করার পক্ষে সর্বোত্তম ব্যাখ্যা করে। আপনি যদি কোনও HTTP মোছা ব্যবহার না করেন, তবে আপনার কাছে একটি নিয়ামকটিতে (2) পোস্ট পদক্ষেপ থাকতে পারে: 1 এর জন্য Createএবং 1 এর জন্য Delete। আপনি যদি এটি করেন তবে আপনার পরবর্তী অনুসন্ধানটি হবে " একক নিয়ামকটিতে একাধিক পোস্ট ক্রিয়াকলাপ কীভাবে থাকবে ": পি। এটি ভয়াবহ নয়, তবে আপনি ইউআরআই-তে ক্রিয়া নামটি স্পষ্টরূপে সরবরাহ করার বিপরীতে ক্রিয়া ক্রিয়াটির মাধ্যমে একটি অনন্য সংস্থান প্রয়োগের ক্ষমতাটি ছেড়ে দিয়েছেন।
এটকনওয়ে

4

যদিও আমি জনপ্রিয় না হওয়ার ঝুঁকি নিয়েছি আমি বলি সেগুলি আজকাল কার্যকর হয় না

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

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

একটি উদাহরণ নেওয়া যাক:

  • / এপিআই / সত্তা / তালিকা / {আইডি} বনাম জিইটি / এপিআই / সত্তা / {আইডি
  • / এপিআই / সত্তা / যোগ / {আইডি} বনাম পোস্ট / এপিআই / সত্তা
  • / এপিআই / সত্তা / সম্পাদনা / {আইডি} বনাম পিইটি / এপিআই / সত্তা / {আইডি
  • / এপিআই / সত্তা / মুছুন / {আইডি} বনাম DELETE / এপিআই / সত্তা / {আইডি

বাম দিকে HTTP পদ্ধতি লেখা হয় না, মূলত এটি কোনও ব্যাপার নয় (POST এবং GET যথেষ্ট) এবং ডানদিকে যথাযথ HTTP পদ্ধতি ব্যবহার করা হয়।

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

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

পদ্ধতিগুলির পুরো HTTP অ্যারে ছাড়াই একটি API তৈরি করা সেবন করা এবং পরে রক্ষণাবেক্ষণ করা আরও সহজ করে


1

নিরাপদ পদ্ধতি: রিসোর্স পান / রিসোর্সে কোনও পরিবর্তন হয়নি
Idempotent: বহুবার অনুরোধ করা হলে রিসোর্সের স্ট্যাটাসে কোনও পরিবর্তন করা হয়নি
অনিরাপদ পদ্ধতি: রিসোর্সে রিসোর্স / আপডেট করুন
অ-আইডেম্পোটেন্ট: বহুবার অনুরোধ করা হলে রিসোর্স স্ট্যাটাসে পরিবর্তন

আপনার প্রয়োজন অনুযায়ী:

1) নিরাপদ এবং আদর্শশালী অপারেশনের জন্য (রিসোর্স সংগ্রহ করুন) ------- পদ্ধতিটি পান
2) অনিরাপদ এবং আদর্শহীন অপারেশন (সন্নিবেশ রিসোর্স) ব্যবহারের জন্য --------- পোস্ট মেথড
3) অনিরাপদ এবং আদর্শহীন অপারেশনের জন্য (আপডেট রিসোর্স) ব্যবহার করুন --------- পুড মেথড
3) অনিরাপদ এবং আইডেম্পোটেন্ট অপারেশনের জন্য (রিসোর্স মুছুন) ব্যবহার করুন --------- পদ্ধতিটি মুছে দিন

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.