REST এপিআই ধারণাগুলি

Question

REST এপিআই ডিজাইন সম্পর্কে আমার তিনটি প্রশ্ন রয়েছে যা আমি আশা করছি যে কেউ কিছুটা আলোকপাত করতে পারে। আমি বেশ কয়েক ঘন্টা নিরলসভাবে অনুসন্ধান করেছি কিন্তু আমার প্রশ্নের উত্তর কোথাও পাইনি (সম্ভবত আমি কী সন্ধান করব তা আমি জানি না?)।

প্রশ্ন 1

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

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

কোনও উত্সের ইউআরআই (যেমন /collection/123?action=resendEmail) এর সাথে কোনও ধরণের অ্যাকশন কল মিশ্রিত করা কি উপযুক্ত ? ক্রিয়াটি নির্দিষ্ট করে এটিতে উত্স আইডি পাস করা ভাল (উদাহরণস্বরূপ /collection/resendEmail?id=123)? এটি কি ভুল পথে চলতে চলেছে? Ditionতিহ্যগতভাবে (কমপক্ষে HTTP সহ) ক্রিয়াটি করা হচ্ছে অনুরোধ পদ্ধতি (জিইটি, পোষ্ট, পুট, মুছে ফেলুন), তবে সেগুলি সত্যিকার অর্থে কোনও সংস্থান দিয়ে কাস্টম ক্রিয়াকলাপের অনুমতি দেয় না।

প্রশ্ন 2

আমি URL এর querystring অংশ ব্যবহার করলে একটি সংগ্রহ (যেমন অনুসন্ধান ফিরে সম্পদের সেট ফিল্টার করতে /collection?someField=someval)। আমার API কন্ট্রোলারের মধ্যে আমি তখন নির্ধারণ করি যে এটি ক্ষেত্র এবং মানের সাথে কী ধরণের তুলনা করতে চলেছে। আমি পেয়েছি এটি সত্যিই কাজ করে না। এপিআই ব্যবহারকারীকে যে ধরণের তুলনা করতে চান তা নির্ধারণ করার জন্য আমার একটি উপায় প্রয়োজন।

সেরা ধারণা আমি এতদূর সঙ্গে আসা পর্যন্ত করেছি এপিআই ব্যবহারকারী ক্ষেত্র নাম একটি উপাঙ্গ (যেমন যেমন নির্দিষ্ট করার অনুমতি দেওয়া /collection?someField:gte=someval- ইঙ্গিত এটি সম্পদ ফেরত পাঠাবেন যেখানে someFieldচেয়ে বেশী বা সমান (> =) যাই হোক না কেন somevalহয় এটি কি ভাল ধারণা? একটি খারাপ ধারণা? যদি তাই হয় তবে কেন? ব্যবহারকারীকে প্রদত্ত ক্ষেত্র এবং মানটির সাথে পারফর্ম করার জন্য তুলনা প্রকারটি নির্দিষ্ট করার মঞ্জুরি দেওয়ার আরও ভাল উপায় কি?

প্রশ্ন 3

আমি প্রায়ই কোনো URI এর যে চেহারা কিছু দেখতে চাই /person/123/dogsপেতে personগুলি dogs। আমি সাধারণত এরকম কিছু এড়িয়ে চলেছি কারণ শেষ পর্যন্ত আমি বুঝতে পারি যে এর মতো একটি ইউআরআই তৈরি করে আপনি আসলে dogsনির্দিষ্ট personআইডির মাধ্যমে ফিল্টার করা কোনও সংকলন অ্যাক্সেস করছেন । এটি সমান হবে /dogs?person=123। আরআরএসটি ইউআরআই দুই স্তরের গভীর ( /collection/resource_id) বেশি হওয়ার সত্যিকারের কোনও কারণ কি কখনও আছে ?

Comments

আপনার তিনটি প্রশ্ন আছে। এগুলি আলাদা করে পোস্ট করবেন না কেন?

— anaximander

এটিকে 3 টি পৃথক প্রশ্নের মধ্যে বিভক্ত করা ভাল। একটি দর্শক একটি প্রশ্নের উত্তরের উত্তর দিতে সক্ষম হতে পারে তবে সমস্ত প্রশ্নের উত্তর নয়।

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

— অ্যান্ড্রু টি ফিনেল

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

— জাস্টিন ওয়ার্কেন্টিন

Answer 1

কোনও উত্সের ইউআরআই (যেমন /collection/123?action=resendEmail) এর সাথে কোনও ধরণের অ্যাকশন কল মিশ্রিত করা কি উপযুক্ত ? ক্রিয়াটি নির্দিষ্ট করে এটিতে উত্স আইডি পাস করা ভাল (উদাহরণস্বরূপ /collection/resendEmail?id=123)? এটি কি ভুল পথে চলতে চলেছে? Ditionতিহ্যগতভাবে (কমপক্ষে HTTP সহ) ক্রিয়াটি করা হচ্ছে অনুরোধ পদ্ধতি (জিইটি, পোষ্ট, পুট, মুছে ফেলুন), তবে সেগুলি সত্যিকার অর্থে কোনও সংস্থান দিয়ে কাস্টম ক্রিয়াকলাপের অনুমতি দেয় না।

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

আপনি যা করেন না কেন, উত্সের নামে ক্রিয়াগুলি রাখবেন না! এটি বিশেষ্য (এবং ক্যোয়ারী অংশটি বিশেষণের সমষ্টি)। নামকরণ ক্রিয়াগুলি আজব!

আমি URL এর querystring অংশ ব্যবহার করলে একটি সংগ্রহ (যেমন অনুসন্ধান ফিরে সম্পদের সেট ফিল্টার করতে /collection?someField=someval)। আমার API কন্ট্রোলারের মধ্যে আমি তখন নির্ধারণ করি যে এটি ক্ষেত্র এবং মানের সাথে কী ধরণের তুলনা করতে চলেছে। আমি পেয়েছি এটি সত্যিই কাজ করে না। এপিআই ব্যবহারকারীকে যে ধরণের তুলনা করতে চান তা নির্ধারণ করার জন্য আমার একটি উপায় প্রয়োজন।

সেরা ধারণা আমি এতদূর সঙ্গে আসা পর্যন্ত থাকেন এপিআই ব্যবহারকারী ক্ষেত্র নাম (যেমন একটি উপাঙ্গ যেমন নির্দিষ্ট করার অনুমতি দেওয়া /collection?someField:gte=someval(ইঙ্গিত এটি সম্পদ ফেরত পাঠাবেন যেখানে someField চেয়ে বেশী বা সমান - >=) যাই হোক না কেন somevalহয়। এটি কি একটি ভাল ধারণা? একটি খারাপ ধারণা? যদি তাই হয় তবে কেন? ব্যবহারকারীকে প্রদত্ত ক্ষেত্র এবং মানটির সাথে পারফর্ম করার জন্য তুলনা প্রকারটি নির্দিষ্ট করার অনুমতি দেওয়ার কি আরও ভাল উপায় আছে?

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

এই ধরণের আবিষ্কারযোগ্যতা হ'ল আমি REST এর সাথে কমপক্ষে দৃ strong় মনে করি।

আমি প্রায়শই ইউআরআই দেখতে পাই যা দেখতে /person/123/dogsব্যক্তির কুকুরটিকে পাওয়ার মতো কিছু । আমি সাধারণত এরকম কিছু এড়িয়ে চলেছি কারণ শেষ পর্যন্ত আমি বুঝতে পারি যে এর মতো একটি ইউআরআই তৈরি করে আপনি আসলে নির্দিষ্ট ব্যক্তির আইডি দ্বারা ফিল্টার করা একটি কুকুর সংগ্রহের অ্যাক্সেস করছেন। এটি সমান হবে /dogs?person=123। আরআরএসটি ইউআরআই দুই স্তরের গভীর ( /collection/resource_id) বেশি হওয়ার সত্যিকারের কোনও কারণ কি কখনও আছে ?

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

অন্যান্য ধরণের সংগ্রহকে এইচটিটিপি পুনঃনির্দেশ হিসাবে মডেল করা যেতে পারে; সুতরাং /person/123/dogsপ্রকৃতপক্ষে একটি 307 যা পুনঃনির্দেশ করে তার দ্বারা প্রতিক্রিয়া জানানো যেতে পারে /dogs?person=123। এই ক্ষেত্রে, সংগ্রহটি আসলে ইউএমএল রচনা নয়, বরং ইউএমএল সমষ্টি। পার্থক্য গুরুত্বপূর্ণ; এটা তাৎপর্যপূর্ণ!

Comments

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

— জাস্টিন ওয়ার্কেন্টিন

Answer 2

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

আপনি REST এ সঠিক যে একটি রিসোর্স সংগ্রহ সিস্টেম। এটি রিপ্রেজেনটিভাল স্টেট ট্রান্সফারকে বোঝায়। আপনি যদি আমাকে জিজ্ঞাসা করেন তবে একটি দুর্দান্ত সংজ্ঞা নয়। তবে মূল ধারণাগুলি হ'ল 4 টি এইচটিপি ভিআরবি এবং রাষ্ট্রহীন।

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

প্রশ্ন 1

এটি উপলব্ধি করা জরুরী যে আপনার REST এপিআইয়ের কলারটি জেনে রাখা উচিত নয় যে PUTআপনার সংগ্রহে কোনও কাজ করার ফলে কোনও ইমেল তৈরি হতে পারে generated আমার কাছে এই ফুটো গন্ধ। তারা যা জানতে পারে তা হ'ল একটি সম্পাদন করার PUTফলে তারা আরও কাজ করতে পারে যা তারা পরে জিজ্ঞাসা করতে পারে। তারা GETসম্প্রতি তৈরি হওয়া উত্সটিতে একটি সম্পাদন করে এটি জানবে । যে GETসম্পদ ও সব ফিরে আসবে Taskরিসোর্স আইডি তা এর সাথে সংশ্লিষ্ট। এরপরে আপনি সেগুলির স্থিতি নির্ধারণ করতে এবং একটি নতুন জমা দেওয়ার জন্য পরে সেগুলি সম্পর্কে জিজ্ঞাসা করতে পারেন Task।

আপনার স্বল্প কিছু সু্যোগ আছে।

রেস্ট - টাস্ক রিসোর্স ভিত্তিক পদ্ধতির

এমন একটি tasksসংস্থান তৈরি করুন যাতে আপনি ক্রিয়া সম্পাদন করতে আপনার সিস্টেমে নির্দিষ্ট কাজ জমা দিতে পারেন। তারপরে আপনি এটির স্থিতি নির্ধারণ করতে এর GETউপর ভিত্তি করে কাজটি করতে পারেন ID।

অথবা আপনি SOAP over HTTPআপনার আর্কিটেকচারে কিছু আরপিসি যুক্ত করতে কোনও ওয়েব পরিষেবাতে মিশ্রিত করতে পারেন ।

একটি নির্দিষ্ট উত্স জন্য সমস্ত কাজ জিজ্ঞাসা

GET http://server/api/myCollection/123/tasks

{ "tasks" :
    [ { "22333" : "http://server/api/tasks/223333" } ] 
}

টাস্ক রিসোর্স উদাহরণ

PUT http://server/api/tasks

{ 
    "type" : "send-email" , 
    "parameters" : 
    { 
         "collection-type" : "foo" , 
         "collection-id" : "123" 
    } 
}

==> টাস্কের আইডি প্রদান করে

223334

GET http://server/api/tasks/223334

{ 
    "status" : "complete" , 
    "date" : "whenever" 
}

REST- ক্রিয়াকলাপগুলিতে পোষ্ট ব্যবহার করে

আপনি সর্বদা POSTকোনও উত্সে অতিরিক্ত ডেটা করতে পারেন । আমার মতে এটি বিশ্রামের চেতনা লঙ্ঘন করবে তবে এটি এখনও মেনে চলবে।

আপনি এর মতো একটি পোষ্ট করতে পারেন:

POST http://server/api/collection/123

{ "action" : "send-email" }

আপনি অতিরিক্ত ডেটা সহ সংগ্রহ থেকে 123 রিসোর্স আপডেট করবেন। অতিরিক্ত তথ্যটি মূলত সেই উত্সটির জন্য ইমেল প্রেরণে ব্যাকএন্ডকে বলা একটি ক্রিয়া।

আমার এটির সাথে সমস্যাটি হ'ল GETসংস্থানটিতে থাকা একটি এই আপডেট হওয়া ডেটা ফেরত দেবে। তবে এটি আপনার প্রয়োজনীয়তা সমাধান করবে এবং এখনও বিশ্রামে থাকবে।

SOAP - ওয়েব পরিষেবা যা REST থেকে প্রাপ্ত সংস্থান গ্রহণ করে

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

প্রশ্ন 2

আপনার এখানে কয়েকটি বিকল্প রয়েছে:

এটি অনেক বড় বড় সংস্থাগুলি উপস্থিত হয় যা REST এপিআই প্রকাশ করে এমন একটি searchসংগ্রহ প্রকাশ করে যা সম্পদ ফেরত দেওয়ার জন্য ক্যোয়ারী প্যারামিটারগুলিতে পাস করার সত্যিই এক উপায়।

GET http://server/api/search?q="type = myCollection & someField >= someval"

যা সম্পূর্ণরূপে যোগ্য REST সংস্থার যেমন:

{
    "results" : 
       { [ 
             "location" : "http://server/api/myCollection/1",
             "location" : "http://server/api/myCollection/9",
             "location" : "http://server/api/myCollection/56"
         ]
       }
}

অথবা আপনি কোয়েরি প্যারামিটার হিসাবে এমভিএল এর মতো কিছুতে অনুমতি দিতে পারেন ।

প্রশ্ন 3

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

মন্তব্য

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

আরআরইএসটির সাথে অন্য প্রধান জিনিসটি হ'ল আপনার API এর যে কোনও বিন্দুতে শুরু করতে সক্ষম হওয়া উচিত এবং সময়ের আগে অন্যান্য সংস্থাগুলির সঠিক URL জানতে ব্যতীত অন্যান্য সমস্ত সংস্থানীয় সংস্থানগুলিতে নেভিগেট করতে সক্ষম হওয়া উচিত। GETREST এ VERB- এর ফলাফলগুলির উল্লেখ করা সংস্থানগুলির সম্পূর্ণ REST ইউআরএল ফিরিয়ে দেওয়া উচিত। সুতরাং একটি আইডি ফিরে একটি ক্যোয়ারী পরিবর্তে Personবস্তু, এটা যেমন সম্পূর্ণরূপে বৈধ URL ফিরে আসবে http://server/api/people/13। তারপরে আপনি ইউআরএল পরিবর্তিত হয়ে গেলেও প্রোগ্রামগুলিতে সর্বদা ফলাফলগুলিতে নেভিগেট করতে পারেন।

প্রতিক্রিয়া মন্তব্য

বাস্তব বিশ্বে বাস্তবে এমন কিছু জিনিস ঘটে থাকে যা কোনও সংস্থান তৈরি করে না, পড়ে, আপডেট করে না অথবা মুছে দেয় না (CRUD)।

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

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

আপনার স্বল্প কিছু সু্যোগ আছে:

• একটি টাস্ক রিসোর্স তৈরি করুন
• POSTকোনও ক্রিয়া সম্পাদন করতে রিসোর্সে অতিরিক্ত ডেটা আইং সমর্থন করে ।
• একটি এসওএপি ওয়েব পরিষেবার মাধ্যমে অতিরিক্ত কমান্ড যুক্ত করুন।

আপনি যদি ইমেলটি পুনরায় পাঠাতে কোন HTTP VERB ব্যবহার করবেন এমন কোনও কোয়েরি প্যারামিটার ব্যবহার করেন?

• GET- এটি কি ইমেলটি পুনরায় পাঠায় এবং সংস্থানটির ডেটা ফেরত দেয়? যদি কোনও সিস্টেম সেই URL টি ক্যাশে করে এবং সেই সংস্থানটির জন্য এটি অনন্য URL হিসাবে ব্যবহার করে। প্রতিবার তারা ইউআরএল হিট করে এটি ইমেল পুনরায় পাঠাবে।
• POST - আপনি রিসোর্সে কোনও নতুন ডেটা প্রেরণ করেননি, কেবল একটি অতিরিক্ত ক্যোয়ারী প্যারামিটার।

প্রদত্ত সমস্ত প্রয়োজনীয়তার ভিত্তিতে, পোস্টের ডেটা হিসাবে রিসোর্সটিতে POSTএকটি action fieldকরা সমস্যার সমাধান করবে will

Comments

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

— জাস্টিন ওয়ার্কেন্টিন

@ জাস্টিন ওয়ার্কেন্টিন আমি আপনার চাহিদা কী তা বুঝতে পারি। তবে এটি রেস্টকে এমন কিছু করে না যা এটি নয়। ইউআরএলটিতে একটি নতুন ক্রিয়া যুক্ত করা REST আর্কিটেকচারের পরিপন্থী। আমি অন্য একটি বিকল্প প্রস্তাব দেওয়ার জন্য আমার উত্তরটি আপডেট করব যা বিশ্রামযোগ্য হবে।

— অ্যান্ড্রু টি ফিনেল

আমার জাস্টিন ওয়ার্কেন্টিন আমার উত্তরে 'আরএসটি - পোস্টগুলি ব্যবহার করে ক্রিয়া শুরু করতে' পরীক্ষা করে দেখুন।

— অ্যান্ড্রু টি ফিনেল

Answer 3

প্রশ্ন 1: কোনও উত্সের ইউআরআইয়ের সাথে কোনও ধরণের অ্যাকশন কল মিশ্রিত করা কি উপযুক্ত [বা] অ্যাকশনটি নির্দিষ্ট করে এটিতে সংস্থান আইডি পাস করা ভাল better

ভাল প্রশ্ন. এই ক্ষেত্রে আমি আপনাকে পরবর্তী পদ্ধতিটি ব্যবহার করার পরামর্শ দেব, যথাটি ক্রিয়াটি নির্দিষ্ট করুন এবং এটিতে কোনও সংস্থান আইডি দিন। এইভাবে, যখন আপনার সংস্থানটি প্রথমে সংশোধন করা হবে, তখন এটি ক্রমকে কল করে /sendEmail(পাশের নোট: এটিকে "পুনরায় পাঠাতে" বলার দরকার নেই) আলাদা আলাদা RESTful অনুরোধ হিসাবে (যা পরে আপনি পুনরায় বার বার কল করতে পারেন, সংস্থান থেকে সংশোধিত স্বাধীনভাবে )।

প্রশ্ন 2: এরকম তুলনা অপারেটর ব্যবহার সম্পর্কে:/collection?someField:gte=someval

যদিও এটি প্রযুক্তিগতভাবে ঠিক আছে, এটি সম্ভবত একটি খারাপ ধারণা। আরআরইএসটির অন্যতম মূল নীতি হ'ল পাঠযোগ্যতা। আমি আপনাকে কেবল তুলনামূলক অপারেটরটিকে অন্য একটি প্যারামিটার হিসাবে পাস করার পরামর্শ দিই, উদাহরণস্বরূপ: /collection?someField=someval&operator=gteএবং অবশ্যই আপনার এপিআই ডিজাইন করুন যাতে এটি কোনও ডিফল্ট কেসটি পূরণ করে (এমন পরিস্থিতিতে যে operatorপ্যারামিটারটি ইউআরআই থেকে বেরিয়ে যায়)।

প্রশ্ন 3: আরআরএসটি ইউআরআই দুই স্তরের গভীর হওয়ার সত্যিকারের কোনও কারণ কি কখনও আছে?

হা; বিমূর্ততা জন্য। আমি বেশ কয়েকটি ইউএসআরআইপি এপিআই দেখেছি যা একাধিক ইউআরআই স্তরের মাধ্যমে বিমূর্ততার স্তরগুলি ব্যবহার করে: উদাহরণস্বরূপ: /vehicles/cars/123বা /vehicles/bikes/123যার ফলে আপনি উভয় /vehiclesএবং /vehicles/bikesসংগ্রহ উভয় সম্পর্কিতই দরকারী তথ্য নিয়ে কাজ করতে পারবেন । এই বলে যে, আমি এই পদ্ধতির কোনও বড় অনুরাগী নই; আপনাকে খুব কমই অনুশীলনে এটি করতে হবে এবং সম্ভাবনা হ'ল আপনি মাত্র ২ টি স্তর ব্যবহার করার জন্য এপিআই'র নতুন ডিজাইন করতে পারেন।

এবং হ্যাঁ, উপরের মতামত অনুসারে, ভবিষ্যতে আপনার প্রশ্নগুলি পৃথক পোস্টে ভাগ করে নেওয়া ভাল))

Comments

আমি মনে করি প্রশ্ন # 2 এর জন্য আমার উদাহরণটি অতি সরল ছিল। সংগ্রহটি ফিল্টার করতে প্রতিটি ক্ষেত্রের জন্য একটি তুলনামূলক অপারেটর নির্দিষ্ট করা দরকার, কেবল একটি নয়, তাই আপনার উদাহরণে এটির মতো হতে হবে /collection?field1=someval&field1Operator=gte&field2=someval&field2Operator=eq।

— জাস্টিন ওয়ার্কেন্টিন

Answer 4

প্রশ্ন 2 এর জন্য, একটি ভিন্ন বিকল্প আরও নমনীয় হতে পারে: প্রতিটি অনুসন্ধানকে ব্যবহারের আগে ব্যবহারকারী যে উত্স তৈরি করে তা বিবেচনা করুন।

আপনাকে "অনুসন্ধান" ধারক বলতে দিন, সেখানে আপনার POST /api/searches/সামগ্রীতে ক্যোয়ারির বিশদ বিবরণ দিয়ে একটি করুন। এটি আপনার জন্য সহজতর যা জাসন, এক্সএমএল বা এসকিউএল ডকুমেন্ট হতে পারে। যদি ক্যোয়ারীটি সঠিকভাবে বিশ্লেষণ করে, তবে তার নিজস্ব ইউআরআই দিয়ে একটি নতুন সংস্থান হিসাবে একটি নতুন অনুসন্ধান তৈরি হবে let's/api/searches/q123/

তারপরে, ক্লায়েন্ট কেবল GET /api/searches/q123/অনুসন্ধানের ফলাফলগুলি পুনরুদ্ধার করতে পারে।

শেষ অবধি, আপনি হয় ক্লায়েন্টকে জিজ্ঞাসাটি মুছতে, বা সেশনটি বন্ধ করার পরে এটি পরিষ্কার করতে পারেন।

Answer 5

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

না, এটি যথাযথ নয়, যেহেতু আইআরআইগুলি সম্পদ চিহ্নিতকরণ এবং অপারেশনগুলির জন্য নয় (তবে পিপিএল এবং জিইটি পদ্ধতিগুলি সমর্থন না করা ক্ষেত্রে, কিছু সময়ের জন্য এই পদ্ধতিটি ওভাররাইড পদ্ধতির ব্যবহার করে)। আপনি যা করতে পারেন তা হ'ল উপযুক্ত HTTP পদ্ধতি অনুসন্ধান করা বা একটি নতুন তৈরি করা create পোস্টগুলি এই ক্ষেত্রে আপনার বন্ধু হতে পারে (পিপিএল এটি ব্যবহার করে যদি তারা কোনও উপযুক্ত পদ্ধতি খুঁজে না পায় এবং অনুরোধটি পুনরুদ্ধার না হয়)। ইমেল প্রেরণ থেকে রিসোর্স তৈরির জন্য অন্য পদ্ধতি এবং POST /emailsপ্রকৃত সংস্থান তৈরি না করেই মেলগুলি প্রেরণ করতে পারে। BTW। ইউআরআই কাঠামো শব্দার্থবিজ্ঞান বহন করে না, তাই কোনও REST দৃষ্টিকোণ থেকে এটি বোঝা যায় না যে আপনি কোন ধরণের ইউআরআই ব্যবহার করেন। যা গুরুত্বপূর্ণ তা হ'ল মেটা ডেটা (যেমন লিংক সম্পর্ক ) আপনি ক্লায়েন্টদের কাছে যে লিঙ্কগুলি প্রেরণ করেছেন সেগুলিতে নির্ধারিত।

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

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

এটি / কুকুরের সমতুল্য হবে? ব্যক্তি = 123 আরআরএসটি ইউআরআই দুই স্তরের (/ সংগ্রহ / সংস্থান_আইডি) বেশি হওয়ার সত্যিকারের কোনও কারণ আছে?

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

আমি বেশ কয়েক ঘন্টা নিরলসভাবে অনুসন্ধান করেছি কিন্তু আমার প্রশ্নের উত্তর কোথাও পাইনি (সম্ভবত আমি কী সন্ধান করব তা আমি জানি না?)।

ফিল্ডিং প্রবন্ধ , HTTP মান এবং মার্কাস থেকে সম্ভবত তৃতীয় প্রজন্মের ওয়েব API গুলি থেকে কমপক্ষে REST সীমাবদ্ধতাগুলি পড়তে হবে ।