ভূমিকা ভিত্তিক REST এপিআই?

Question

আমি একটি REST এপিআই তৈরি করছি যার জন্য বিভিন্ন ভূমিকা সহ বেশ কয়েকটি ব্যবহারকারী এতে থাকা সংস্থানগুলিতে অ্যাক্সেস পাবেন।

সুযোগ সহজ রাখার জন্য আসুন "ছাত্র / শিক্ষক / শ্রেণি" ডোমেন নিই:

GET /students অ্যাক্সেস করার সম্পদ।

ব্যবহারকারীদের শিক্ষার্থী এবং / অথবা শিক্ষকের মতো ভূমিকা থাকতে পারে

শিক্ষার্থীদের কেবল তাদের ক্লাসের শিক্ষার্থীদের অ্যাক্সেস থাকবে। শিক্ষকরা যে পাঠদান করেন তাদের শিক্ষার্থীদের অ্যাক্সেস থাকবে। কিছু ব্যবহার শিক্ষার্থী হতে পারে এবং অন্যান্য ক্লাসগুলিও পড়ায়। তাদের অবশ্যই তাদের ক্লাসের শিক্ষার্থীদের এবং তাদের শেখানো ক্লাসগুলির শিক্ষার্থীদের অ্যাক্সেস থাকতে হবে।

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

আমার প্রশ্ন: এটি প্রয়োগের জন্য আমার কোন প্যাটার্নটি ব্যবহার করা উচিত?

বাহ্যিকভাবে

• আমি কি ভূমিকা হিসাবে আমার এপিআই বিভক্ত করা উচিত? GET /teacher/studentsএবং GET /student/studentsএটা আমার কাছে ঠিক মনে হচ্ছে না।
• এগুলি সবই রাখুন আমি এক উত্স (পছন্দসই)

অন্ত

এটি কীভাবে অভ্যন্তরীণভাবে প্রয়োগ করা উচিত?

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

পার্শ্ব প্রতিক্রিয়া হিসাবে: আমি এএসপি.নেট ওয়েব এপিআই এবং সত্ত্বা ফ্রেমওয়ার্ক using ব্যবহার করছি , তবে ধারণাগত বাস্তবায়নের জন্য এটি আসলেই গুরুত্বপূর্ণ নয় doesn't

Comments

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

— ক্লিটন on

Answer 1

আপনার ভূমিকার আশেপাশে নয়, উত্সের আশেপাশে এপিআই স্থপতি করা উচিত:

/rest/students

এমন একটি ভূমিকার সাথে যে কারও কাছে তাদের শিক্ষার্থীদের দেখতে দেয় এমন অ্যাক্সেসযোগ্য হওয়া উচিত।

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

• শিক্ষার্থীরা তাদের নেওয়া ক্লাসগুলিতে শিক্ষার্থীদের অ্যাক্সেস করতে পারে
• শিক্ষকরা যে ক্লাসে পড়ান তারা শিক্ষার্থীদের অ্যাক্সেস করতে পারে

সুতরাং যখন কোনও ব্যক্তি ফোন করে:

/rest/students

আপনি এমন একটি পদ্ধতি কল করেন যা শিক্ষার্থীদের অ্যাক্সেস করে, ব্যক্তির ভূমিকায় অবতীর্ণ হয়। এখানে কয়েকটি সিডো কোড রয়েছে:

roles = person.roles; //array
students = getStudents( roles );
return students;

এবং এই পদ্ধতিতে, আপনি পৃথক কলগুলির সাথে প্রতিটি ভূমিকার জন্য শিক্ষার্থীদের পেতে পারেন, যেমন:

factory = getFactory();
classes= [];
students = [];
for( role in roles ){
    service = factory.getService( role );
    // implementation details of how you get classes for student/teacher are hidden in the service
    classes = classes.merge( service.getClasses( person ) );
    // classes[] has class.students[]
    // loop on classes and add each student to students, or send back classes with nested students? depends on use case
  }
}

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

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

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

Comments

জবাবের জন্য ধন্যবাদ. আপনার পরামর্শ অনুসারে আমি কিছু করতে পেরেছি। লিনিকিউ 2 এসকিউএল (সি #) ব্যবহার করে আমি প্রতিটি "ভূমিকার জন্য" কোয়েরিটি পাস করতে পারি এবং ব্যবহারকারীর প্রতিটি ভূমিকার জন্য একটি আবেদন করতে পারি। ফলাফলটি ব্যবহারকারীর অ্যাক্সেসের প্রতিটি ভূমিকার জন্য "OR" শর্ত সহ একটি বর্ধিত বিবৃতি হবে। যদি কোনও ব্যবহারকারীর জন্য কোনও ভূমিকা নির্ধারিত না হয় তবে আমি কেবল অনুমানযোগ্য return

— ক্যাস্পার জেনসেন

Answer 2

একটি কলম এবং একটি কাগজ সন্ধান করুন এবং আপনার সিস্টেমের মডেলিং শুরু করুন।

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

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

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

আপনি উচিত আপনার আবেদন testable এবং মডুলার করতে আপনার সম্পদ বিভক্ত।

যাইহোক, আসলে আমি যা বোঝাতে চাইছি তার সর্বোত্তম উপায় হ'ল কোড সহ এটি দেখানো :) এখানে একটি গিটহাব পৃষ্ঠা: https://github.com/thomasandersen77/rol-based-rest-api

শুভকামনা :)

Comments

আপনার লিঙ্কটি চলে গেছে ...

— ক্লিটন