একটি RESTful এপিআইতে বহু থেকে বহু সম্পর্ক কীভাবে পরিচালনা করবেন?

Question

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

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

/api/team/0:

{
    name: 'Boston Celtics',
    logo: '/img/Celtics.png',
    players: [
        '/api/player/20',
        '/api/player/5',
        '/api/player/34'
    ]
}

/api/player/20:

{
    pk: 20,
    name: 'Ray Allen',
    birth: '1975-07-20T02:00:00Z',
    team: '/api/team/0'
}

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

/api/team/0:

{
    name: 'Boston Celtics',
    logo: '/img/Celtics.png'
}

/api/player/20:

{
    pk: 20,
    name: 'Ray Allen',
    birth: '1975-07-20T02:00:00Z',
    team: '/api/team/0'
}

/api/player/team/0/:

[
    '/api/player/20',
    '/api/player/5',
    '/api/player/34'        
]

এর জন্য সেরা অনুশীলন কী?

Answer 1

একটি বিশ্রামের ইন্টারফেসে, আপনি সেই নথিগুলি ফিরিয়ে দিতে পারেন যা সেই সম্পর্কগুলিকে লিঙ্ক হিসাবে এনকোড করে সংস্থানগুলির মধ্যে সম্পর্কের বর্ণনা দেয়। সুতরাং, কোনও দলের কাছে একটি দলিল সংস্থান ( /team/{id}/players) বলা যেতে পারে যা দলে থাকা খেলোয়াড়দের লিঙ্কের একটি তালিকা ( /player/{id}) এবং কোনও খেলোয়াড়ের নথির সংস্থান থাকতে পারে (/player/{id}/teams) এটি সেই দলের লিঙ্কগুলির একটি তালিকা যা প্লেয়ারের সদস্য। সুন্দর এবং প্রতিসম। আপনি সেই তালিকায় মানচিত্রটি সহজেই অপারেশন করতে পারবেন, এমনকি কোনও সম্পর্কের নিজস্ব আইডিও দিতে পারেন (যুক্তিযুক্ত তাদের দুটি আইডি রয়েছে, আপনি সম্পর্ক টিম-প্রথম বা প্লেয়ার-ফার্স্ট সম্পর্কে চিন্তা করছেন কিনা তার উপর নির্ভর করে) যদি বিষয়গুলি সহজ করে তোলে if । কেবলমাত্র জটিলটি হ'ল আপনি যদি অন্য প্রান্ত থেকে সম্পর্কটি মুছে ফেলতে পারেন তবে আপনি যদি এটি এক প্রান্ত থেকে মুছে ফেলেন তবে কঠোরভাবে একটি অন্তর্নিহিত ডেটা মডেল ব্যবহার করে এবং তারপরেই আরআরএস ইন্টারফেসের দৃষ্টিভঙ্গি হ'ল যে মডেল যে আরও সহজ করতে চলেছে।

টিম এবং খেলোয়াড়দের জন্য আপনি যে জাতীয় আইডি ব্যবহার করেন না কেন, সম্পর্কের আইডি সম্ভবত ইউআইডি বা সমান দীর্ঘ এবং এলোমেলো কিছু ভিত্তিতে হওয়া উচিত। যে (ছোট পূর্ণসংখ্যার তুমি দুর্ঘটনায় সম্পর্কে উদ্বেজক ছাড়া সম্পর্ক উভয় প্রান্ত জন্য আইডি উপাদান হিসাবে একই UUID ব্যবহার করতে দেবে না যে সুবিধা আছে)। এই সদস্যপদ সম্পর্কের যদি কোনও দ্বিপক্ষীয় পদ্ধতিতে কোনও খেলোয়াড় এবং একটি দলকে সম্পর্কিত যে খোলামেলা সত্য ব্যতীত অন্য কোনও সম্পত্তি থাকে তবে তাদের নিজস্ব পরিচয় থাকতে হবে যা খেলোয়াড় এবং দল উভয়ের থেকে পৃথক; প্লেয়ার-টিম ভিউতে একটি জিইটি ( /player/{playerID}/teams/{teamID}) তারপরে দ্বিদ্বিদর্শন ভিউ ( /memberships/{uuid}) এ কোনও HTTP পুনর্নির্দেশ করতে পারে ।

XLink xlink:href বৈশিষ্ট্যগুলি ব্যবহার করে আপনি ফিরে আসা কোনও এক্সএমএল নথিগুলিতে লিঙ্কগুলি লেখার প্রস্তাব দিই (যদি আপনি অবশ্যই এক্সএমএল উত্পাদন করে থাকেন ) ।

Answer 2

/memberships/সংস্থানগুলির একটি পৃথক সেট করুন ।

1. আরএসইএসটি অন্য কিছু না হলে বিবর্তনযোগ্য সিস্টেম তৈরির বিষয়ে। এই মুহুর্তে, আপনি কেবল খেয়াল রাখতে পারেন যে কোনও প্রদত্ত খেলোয়াড় একটি নির্দিষ্ট দলে রয়েছেন তবে ভবিষ্যতের এক পর্যায়ে আপনি আরও তথ্যের সাথে সেই সম্পর্কটি বর্ননা করতে চাইবেন: তারা সেই দলে কত দিন ধরে ছিলেন, যারা তাদের উল্লেখ করেছেন সেই দলে, যারা তাদের কোচ ছিলেন / সেই দলে থাকাকালীন, ইত্যাদি etc.
2. আরআরইএসটি দক্ষতার জন্য ক্যাশিংয়ের উপর নির্ভর করে, যার ক্যাশে পারমাণবিকতা এবং অবৈধকরণের জন্য কিছু বিবেচনা প্রয়োজন। যদি আপনি /teams/3/players/সেই তালিকার কোনও নতুন সত্তা পোষ্ট করেন তবে তা অবৈধ হয়ে যাবে, তবে আপনি চান না যে বিকল্প ইউআরএল /players/5/teams/ক্যাশে থাকবে। হ্যাঁ, বিভিন্ন ক্যাশে বিভিন্ন তালিকার প্রতিটি তালিকার অনুলিপি থাকতে পারে এবং আমরা সে সম্পর্কে অনেক কিছুই করতে পারি না, তবে আমরা অবৈধ হওয়া দরকার এমন সংস্থাগুলির সীমাবদ্ধ রেখে আপডেটটি পোস্টের জন্য অন্তত বিভ্রান্তি হ্রাস করতে পারি we তাদের ক্লায়েন্টের স্থানীয় ক্যাশের মধ্যে এক এবং একমাত্র এক সময়ে /memberships/98745( "বিকল্প সূচকের" এর Helland এর আলোচনা দেখুন বন্টিত লেনদেন পরলোক লাইফ আরো বিস্তারিত আলোচনার জন্য)।
3. আপনি উপরোক্ত 2 পয়েন্টগুলি কেবল বাছাই করে ( /players/5/teamsবা /teams/3/playersউভয়ই নয়) প্রয়োগ করতে পারেন । প্রাক্তন ধরে নেওয়া যাক। তবে এক পর্যায়ে আপনি বর্তমান সদস্যতার /players/5/teams/তালিকার জন্য রিজার্ভ করতে চান এবং তবুও কোথাও কোথাও অতীতের সদস্যপদগুলি উল্লেখ করতে সক্ষম হবেন । সংস্থানগুলিতে হাইপারলিঙ্কগুলির একটি তালিকা তৈরি করুন এবং তারপরে স্বতন্ত্র সদস্যপদ সংস্থানগুলির জন্য প্রত্যেকের বুকমার্কগুলিকে না ভাঙিয়ে আপনি যখন পছন্দ করতে পারেন তখন যুক্ত করতে পারেন। এটি একটি সাধারণ ধারণা; আমি নিশ্চিত আপনি অন্যান্য অনুরূপ ভবিষ্যত কল্পনা করতে পারেন যা আপনার নির্দিষ্ট ক্ষেত্রে আরও প্রযোজ্য।/players/5/memberships//memberships/{id}//players/5/past_memberships/

Comments

পয়েন্ট 1 এবং 2 পুরোপুরি ব্যাখ্যা করা হয়েছে, ধন্যবাদ, কারও যদি বাস্তব জীবনের অভিজ্ঞতায় 3 পয়েন্টের জন্য আরও মাংস থাকে তবে তা আমাকে সাহায্য করবে।

— আলাইন

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

— ভেঙ্কট ডি

হাই ফুমানছু প্রশ্নগুলি: বাকী শেষ প্রান্তে / সদস্যতা / 98745 এ ইউআরএল শেষে সেই সংখ্যাটি কী উপস্থাপন করে? এটি সদস্যতার জন্য একটি অনন্য আইডি? সদস্যতা শেষ পয়েন্টের সাথে কীভাবে যোগাযোগ করবেন? খেলোয়াড় যুক্ত করতে কোনও পোস্টকে pay দল: 3, প্লেয়ার: 6 with সহ একটি পে-লোড সমেত পাঠানো হবে, যার ফলে দুজনের মধ্যে লিঙ্ক তৈরি হবে? একটি জিইটি সম্পর্কে কি? ফলাফল পেতে কি আপনি / সদস্যতা? প্লেয়ার = এবং / সদস্যশিপ? টিম = কে জিইটি প্রেরণ করবেন? এটাই কি ধারণা? আমি কি কিছু মিস করছি? (আমি বিশ্রামের শেষ বিষয়গুলি শেখার চেষ্টা করছি) সেক্ষেত্রে সদস্যতা / 98745 এর আইডি 98745 কি আসলেই কার্যকর?

— aruuuuu

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

— আলেকজান্ডার পালামারচুক

Answer 3

আমি সাব-রিসোর্সের সাথে এই জাতীয় সম্পর্কের মানচিত্র করব, সাধারণ নকশা / ট্র্যাভারসাল তখন হবে:

# team resource
/teams/{teamId}

# players resource
/players/{playerId}

# teams/players subresource
/teams/{teamId}/players/{playerId}

রেস্টলফুল-শর্তে এটি এসকিউএল না ভেবে অনেক বেশি সহায়তা করে এবং সংযুক্তি, উপ-সংগ্রহ এবং ট্র্যাভারসাল এ যোগ দেয়।

কিছু উদাহরণ:

# getting player 3 who is on team 1
# or simply checking whether player 3 is on that team (200 vs. 404)
GET /teams/1/players/3

# getting player 3 who is also on team 3
GET /teams/3/players/3

# adding player 3 also to team 2
PUT /teams/2/players/3

# getting all teams of player 3
GET /players/3/teams

# withdraw player 3 from team 1 (appeared drunk before match)
DELETE /teams/1/players/3

# team 1 found a replacement, who is not registered in league yet
POST /players
# from payload you get back the id, now place it officially to team 1
PUT /teams/1/players/44

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

Comments

যদি টিমপ্লেয়ারের স্ট্যাটাস ইত্যাদির মতো অতিরিক্ত তথ্য থাকে? আমরা কোথায় আপনার মডেল এটি উপস্থাপন? গেম /, প্লেয়ার /

— নরেন্দ্র কাম্মা

আরে, আমি এখন এই অধিকারটি পাচ্ছি তা নিশ্চিত করার জন্য দ্রুত প্রশ্ন: GET / টিমস / ১ / প্লেয়ার / 3 একটি খালি প্রতিক্রিয়া দেবে। এর থেকে শুধুমাত্র অর্থপূর্ণ প্রতিক্রিয়া 200 বনাম 404 The প্লেয়ার সত্তার তথ্য (নাম, বয়স ইত্যাদি) GET / দল / 1 / প্লেয়ার / 3 দ্বারা ফেরত আসে না। ক্লায়েন্ট যদি প্লেয়ারের উপরে অতিরিক্ত তথ্য পেতে চায় তবে তাকে অবশ্যই জিইটি / প্লেয়ার / 3 করতে হবে। সব কি ঠিক আছে?

— ভার্ডাগন

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

— JakubKnejzlik

পোষ্ট আদর্শবান নয়, অর্থাত্ যদি আপনি পোষ্ট / দল / ১ / প্লেয়ার এন-টাইম করেন, আপনি এন-টাইম / টিম / ১ পরিবর্তন করবেন। তবে কোনও খেলোয়াড়কে / টিম / ১ এন-টাইমে স্থানান্তরিত করা টিমের রাজ্যকে পরিবর্তন করবে না তাই পিইউটি ব্যবহার আরও সুস্পষ্ট।

— 19:34

@ নরেন্দ্রকাম্মা আমার ধারণা আমি পুট statusঅনুরোধে শুধু পরম হিসাবে প্রেরণ করব ? এই পদ্ধতির কোনও ক্ষতি আছে কি?

— ট্র্যাকসো

Answer 4

বিদ্যমান উত্তরগুলি ধারাবাহিকতা এবং আদর্শশক্তিগুলির ভূমিকা ব্যাখ্যা করে না - যা তাদের UUIDsআইডিগুলির জন্য / এলোমেলো সংখ্যার প্রস্তাবনাগুলি PUTপরিবর্তে প্রেরণা জোগায় POST।

"আমাদের দলে নতুন খেলোয়াড় যুক্ত করুন " এর মতো সাধারণ পরিস্থিতিটি যদি আমরা বিবেচনা করি তবে আমরা ধারাবাহিকতার সমস্যাগুলির মুখোমুখি হই।

প্লেয়ারের অস্তিত্ব নেই বলে আমাদের দরকার:

POST /players { "Name": "Murray" } //=> 302 /players/5
POST /teams/1/players/5

যাইহোক, ক্লায়েন্ট অপারেশন যদি এর পরে ব্যর্থ POSTহয় /players, আমরা এমন খেলোয়াড় তৈরি করেছি যা কোনও দলের নয় belong

POST /players { "Name": "Murray" } //=> 302 /players/5
// *client failure*
// *client retries naively*
POST /players { "Name": "Murray" } //=> 302 /players/6
POST /teams/1/players/6

এখন আমাদের মধ্যে একটি অনাথ অনুলিপি প্লেয়ার রয়েছে /players/5।

এটি ঠিক করার জন্য আমরা কাস্টম পুনরুদ্ধার কোডটি লিখতে পারি যা অনাথ খেলোয়াড়দের জন্য পরীক্ষা করে যা কিছু প্রাকৃতিক কী (যেমন Name) এর সাথে মেলে । এটি এমন কাস্টম কোড যা পরীক্ষার প্রয়োজন, আরও বেশি অর্থ এবং সময় ইত্যাদির প্রয়োজন

কাস্টম পুনরুদ্ধার কোডের প্রয়োজন এড়াতে, আমরা PUTপরিবর্তে প্রয়োগ করতে পারি POST।

আরএফসি থেকে :

এর উদ্দেশ্যটি PUTআদর্শবান

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

এটি আমাদের উভয় /players PUTএবং এর /memberships PUTপরিণতি ছাড়াই পুনরায় যুক্ত করতে দেয় :

PUT /players/23lkrjrqwlej { "Name": "Murray" } //=> 200 OK
// *client failure*
// *client YOLOs*
PUT /players/23lkrjrqwlej { "Name": "Murray" } //=> 200 OK
PUT /teams/1/players/23lkrjrqwlej

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

এটি বিদ্যমান উত্তরের আরও সংযোজন, তবে আমি আশা করি যে এটি কেবলমাত্র নমনীয় এবং নির্ভরযোগ্য আরএসটি হতে পারে তার বৃহত চিত্রের প্রসঙ্গে রাখে।

Comments

এই কাল্পনিক শেষ প্রান্তে আপনি কোথা থেকে পেলেন 23lkrjrqwlej?

— cbcoutinho

কীবোর্ডে মুখের রোল - 23lkr এর সাথে বিশেষ কিছু নেই ... গাব্বলডেগ ছাড়াও এটি অনুক্রমিক বা অর্থবহ নয়

— শেঠ

Answer 5

আমার পছন্দের সমাধান তিনটি সম্পদ তৈরি করতে হল: Players, Teamsএবং TeamsPlayers।

সুতরাং, কোনও দলের সমস্ত খেলোয়াড় পেতে, কেবল Teamsরিসোর্সে যান এবং কল করে তার সমস্ত খেলোয়াড় পান GET /Teams/{teamId}/Players।

অন্যদিকে, কোনও খেলোয়াড় খেলেছে এমন সমস্ত দল পেতে, এর মধ্যে Teamsসংস্থানটি পান Players। কল করুন GET /Players/{playerId}/Teams।

এবং, বহু থেকে বহু সম্পর্কের কল পেতে GET /Players/{playerId}/TeamsPlayersবা GET /Teams/{teamId}/TeamsPlayers।

দ্রষ্টব্য, এই সমাধানে, আপনি কল করার সময় GET /Players/{playerId}/Teams, আপনি একটি Teamsসংস্থানের সংস্থান পান, আপনি কল করার সময় ঠিক একই উত্স পাবেন GET /Teams/{teamId}। বিপরীত একই নীতি অনুসরণ করে, আপনি Playersকল করার সময় সংস্থানগুলির একটি অ্যারে পাবেন GET /Teams/{teamId}/Players।

উভয় কলগুলিতে, সম্পর্কের কোনও তথ্য ফিরে আসে না। উদাহরণস্বরূপ, কোনও contractStartDateফেরত দেওয়া হয় না, কারণ রিসোর্সে ফিরে আসা সম্পর্কের কোনও তথ্য নেই, কেবল তার নিজস্ব সংস্থান সম্পর্কে।

NN সম্পর্ক, কল পারেন মোকাবেলা করার জন্য GET /Players/{playerId}/TeamsPlayersবা GET /Teams/{teamId}/TeamsPlayers। এই কলগুলি ঠিক রিসোর্স দেয় TeamsPlayers,।

এই TeamsPlayersসম্পদ দিয়েছেন id, playerId, teamIdবৈশিষ্ট্যাবলী, সেইসাথে কিছু অন্যদের সম্পর্ক বর্ণনা করার জন্য। এছাড়াও, এটি মোকাবেলা করার জন্য প্রয়োজনীয় পদ্ধতি রয়েছে। GET, POST, PUT, DELETE ইত্যাদি যা ফেরত আসবে, অন্তর্ভুক্ত হবে, আপডেট হবে এবং সম্পর্কের সংস্থানটি সরিয়ে দেবে।

TeamsPlayersসম্পদ কার্যকরী কিছু প্রশ্নের, ভালো GET /TeamsPlayers?player={playerId}সব ফিরে যাওয়ার TeamsPlayersসম্পর্ক খেলোয়াড় দ্বারা চিহ্নিত {playerId}হয়েছে। একই ধারণা অনুসরণ করে, দলে খেলেছে এমন GET /TeamsPlayers?team={teamId}সমস্ত কিছু ফিরিয়ে দিতে ব্যবহার করুন । উভয় কলে, সংস্থানটি ফেরত দেওয়া হয়। সম্পর্কের সাথে সম্পর্কিত সমস্ত ডেটা ফেরত দেওয়া হয়।TeamsPlayers{teamId}GETTeamsPlayers

যখন কলিং GET /Players/{playerId}/Teams(অথবা GET /Teams/{teamId}/Players), সম্পদ Players(অথবা Teams) কল TeamsPlayersসংশ্লিষ্ট দল (বা খেলোয়াড়দের) একটি ক্যোয়ারী ফিল্টার ব্যবহারের দেখাবে।

GET /Players/{playerId}/Teams এই মত কাজ করে:

1. প্লেয়ারের আইডি = প্লেয়ারআইডি রয়েছে এমন সমস্ত টিমপ্লেয়ার সন্ধান করুন । ( )GET /TeamsPlayers?player={playerId}
2. ফিরে আসা টিমসপ্লেয়ারগুলি লুপ করুন
3. ব্যবহার teamId থেকে প্রাপ্ত TeamsPlayers , কল GET /Teams/{teamId}এবং ফিরে ডেটা জমা
4. লুপ শেষ হওয়ার পরে। লুপের মধ্যে থাকা সমস্ত দলকে ফিরিয়ে দিন।

কল করার সময় কোনও দল থেকে সমস্ত খেলোয়াড় পেতে একই অ্যালগরিদম ব্যবহার করতে পারেন GET /Teams/{teamId}/Players, তবে দল এবং খেলোয়াড়দের বিনিময় করতে পারেন।

আমার সংস্থানগুলি এর মতো দেখাবে:

/api/Teams/1:
{
    id: 1
    name: 'Vasco da Gama',
    logo: '/img/Vascao.png',
}

/api/Players/10:
{
    id: 10,
    name: 'Roberto Dinamite',
    birth: '1954-04-13T00:00:00Z',
}

/api/TeamsPlayers/100
{
    id: 100,
    playerId: 10,
    teamId: 1,
    contractStartDate: '1971-11-25T00:00:00Z',
}

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

যখনই কোনও সম্পর্ক তৈরি করা হয়, আপডেট করা হয় বা মুছে ফেলা হয়, উভয় Playersএবং Teamsসংস্থান স্বয়ংক্রিয়ভাবে আপডেট হয়।

Comments

টিমসপ্লেয়ার্স রিসোর্সটি উপস্থাপন করার জন্য এটি সত্যই বোধগম্য .আশ্চর্য

— বিজয়

সেরা ব্যাখ্যা

— ডায়ানা

Answer 6

আমি জানি যে এই প্রশ্নের গ্রহণযোগ্য হিসাবে চিহ্নিত একটি উত্তর আছে, তবে, আমরা এখানে পূর্ববর্তী উত্থাপিত সমস্যাগুলি কীভাবে সমাধান করতে পারি তা এখানে:

পিট জন্য বলুন

PUT    /membership/{collection}/{instance}/{collection}/{instance}/

উদাহরণস্বরূপ, অনুসরণগুলি সিঙ্কের প্রয়োজন ছাড়াই একই প্রভাবের ফলস্বরূপ হবে কারণ সেগুলি একক সংস্থানায় করা হয়েছে:

PUT    /membership/teams/team1/players/player1/
PUT    /membership/players/player1/teams/team1/

এখন আমরা যদি একটি দলের জন্য একাধিক সদস্যতা আপডেট করতে চাই তবে আমরা নীচের মতো (যথাযথ বৈধতা সহ) করতে পারি:

PUT    /membership/teams/team1/

{
    membership: [
        {
            teamId: "team1"
            playerId: "player1"
        },
        {
            teamId: "team1"
            playerId: "player2"
        },
        ...
    ]
}

Answer 7

1. / প্লেয়ার (একটি মাস্টার রিসোর্স)
2. / দল / {আইডি} / প্লেয়ার (একটি সম্পর্কের সংস্থান, তাই এটি দ্বিধাদ্বন্দ্বের প্রতিক্রিয়া দেখায় যে 1)
3. / সদস্যতা (একটি সম্পর্ক তবে শব্দার্থগতভাবে জটিল)
4. / প্লেয়ার / সদস্যতা (একটি সম্পর্ক তবে শব্দার্থগতভাবে জটিল)

আমি পছন্দ 2

Comments

সম্ভবত আমি উত্তরটি বুঝতে পারি না, তবে এই পোস্টটি প্রশ্নের উত্তর বলে মনে হচ্ছে না।

— ব্র্যাডলিডটনেট

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

— অবৈধ

@IllegalArgument এটা হল একটি উত্তর এবং একটি মন্তব্য হিসাবে জানার জন্য না। তবে এটি সবচেয়ে বড় উত্তর নয়।

— কিউস - মনিকা 24

এই উত্তরটি অনুসরণ করা কঠিন এবং কারণ সরবরাহ করে না।

— ভেঙ্কট ডি

এটি জিজ্ঞাসিত প্রশ্নের মোটেও ব্যাখ্যা বা উত্তর দেয় না।

— মনজিৎ কুমার