मुझे एक आरपीजी गेम

Question

के लिए इन्वेंट्री एपीआई के एक त्वरित कार्यान्वयन के लिए एक विचार की आवश्यकता है, मैं एक प्रकार का आरपीजी गेम पर काम कर रहा हूं। और मैं इन्वेंट्री एपीआई को परिभाषित करने के लिए एक अच्छा, साफ और विश्वसनीय तरीका समझने की कोशिश कर रहा हूं।

सूची में slots जैसे head, chest आदि शामिल हैं (जैसे अधिकांश आरपीजी गेम में)।

• अच्छी तरह से, स्पष्ट रूप से /inventory
• पर सूची जीवन इतना 1:

  अब मैं

  कुछ विचार मैं था स्लॉट वाई के लिए स्लॉट एक्स से सभी आइटम ले जाने के लिए REST API परिभाषित करने की जरूरत विचार /inventory/movement की तरह smth था और CRUD बनाने के लिए CREATE है। तो यह POST /inventory/movement होगा। यह सीआरयूडी और आरईएसटी होगा, लेकिन यह बहुत बुरा लगता है।

• एक और सूची में कुछ जादू गुण थे और बस इसे अपडेट करने के लिए: PUT /inventory?move_from=A&move_to=B। यह अभी भी बहुत अच्छा महसूस नहीं करता है।

तो .. इसके लिए एक स्वच्छ CRUD REST समाधान के लिए कोई विचार?

अद्यतन: बस एक और था: PUT /inventory/:to_slot?from=:from_slot - अभी भी सुनिश्चित नहीं है। 2 में शामिल होने पर केवल एक स्लॉट पर कार्रवाई क्यों की जाती है? हम्म ... उह!

Answer 1

चूंकि आरईएसटी में आपको संसाधन पर या संसाधनों के संग्रह पर हमेशा कार्य करना चाहिए, इस मामले में मैं 'MOVE' आरईएसटी संसाधन के रूप में कार्रवाई पर विचार करता हूं। यह पहली बार गलत लग सकता है, क्योंकि हम 'MOVE' पर एक क्रिया होने के लिए और संज्ञा नहीं मानते हैं, लेकिन यह समझ में आता है कि इंटरफ़ेस उच्च स्तर के अमूर्तता को कवर करता है। एक उच्च स्तरीय इंटरफ़ेस में जो उपयोगकर्ता को गेम को नियंत्रित करने के लिए उपलब्ध विकल्पों को उजागर करता है, आप 'मूव विकल्प' पर कार्य करना चाहेंगे, जो अचानक एक संज्ञा बन जाता है!

मैं इसलिए, सूची के भीतर एक आइटम ले जाने के लिए पोस्ट क्रिया का प्रयोग करेंगे क्योंकि हम के लिए एक अनुरोध पत्र जारी करने की जाएगी एक नए 'चाल' कार्रवाई पैदा करते हैं। निम्नलिखित स्वतः स्पष्ट उदाहरणों को देखें:

- POST /move/inventory/a/b 
- POST /sell/inventory/a 
- POST /use/inventory/b 

'चाल' कच्चे CRUD संचालन में आदेश सामान्य रूप से के साथ एक एक हटाएँ द्वारा पीछा बनाने कार्यान्वित किया जाता है। हालांकि, मुझे लगता है कि यदि आप खेल संसाधनों पर कच्चे सीआरयूडी संचालन का उपयोग करना चाहते हैं तो आपको बहुत कम स्तर मिलेगा।

यदि आप एक्स से एक आइटम प्राप्त करना चाहते हैं और इसे वाई में डालते हैं, तो आप सत्यापन तर्क कहां डाल देंगे जो जांचता है कि वाई वैध गंतव्य है या नहीं? क्या यह मॉडल (इंटरफ़ेस के पीछे) या आपके गेम में होना चाहिए? यदि यह मॉडल में होना चाहिए, तो मुझे लगता है कि आपको पहले वर्णित उच्च स्तरीय दृष्टिकोण पर विचार करना चाहिए। यदि, दूसरी तरफ आप इस तर्क को गेम (इंटरफेस के सामने) में संभालने का इरादा रखते हैं, तो आप कच्चे सीआरयूडी दृष्टिकोण को Jan suggested in another answer के रूप में ले सकते हैं।

ध्यान दें कि यदि आपका आरपीजी वेब-फेस होने वाला है, तो यह आवश्यक है कि आप सर्वर के पक्ष में गेम तर्क को संभालें।उस स्थिति में मैं उपयोगकर्ता को संकेत दिए गए नियंत्रण और विकल्पों के साथ एक-से-एक आरईएसटी इंटरफेस को मैप करना चाहता हूं - और फिर, मैं ऊपर प्रस्तावित उच्च स्तरीय मॉडल का सुझाव दूंगा।

Answer 2

इसे डोमेन तर्क के अंदर एक आईपोटेटिक आइटम की स्थिति_आईडी अपडेट करनी चाहिए, या ऐसा कुछ नहीं है?

तो मुझे लगता है कि आप मौजूदा आइटम के लिए रखा shuld:

PUT /items/:id?position_id=:position_id 

नमूना:

PUT /items/1?position_id=2 

आप पहले से ही "से स्थिति" जानते हैं, क्योंकि यह पहले से ही अपने मद मॉडल isn में परिभाषित किया जाना चाहिए यह नहीं है?

निश्चित रूप से आप अगर आप इसे और वर्णनात्मक बनाने के लिए करना/सूची/नाम स्थान में जोड़ सकते हैं, तो मैं सुझाव है:

PUT /inventory/items/:id?position_id=:position_id 

पी.एस. ध्यान दें कि पैरामीटर के बाद? मापदंडों प्राप्त नहीं कर रहे हैं :)

Answer 3

विटाली,

कार्यों के संदर्भ (के लिए कदम करने के लिए), लेकिन संसाधनों और राज्य हस्तांतरण के मामले में में नहीं सोचता। यहां बताया गया है कि मैं आरईएसटी के साथ क्या करता हूं:

 
GET /game/inventories/5536 

200 Ok 
Content-Type: application/rpg.inventory+xml 

<inventory> 
    <slot href="/game/inventories/5536/slot">X</slot> 
    .... 
</inventory> 





PUT /game/inventories/5536/slot 

Content-Type: text/plain (or what you need) 

"Y" 

GET /game/inventories/5536 

200 Ok 
Content-Type: application/rpg.inventory+xml 

<inventory> 
    <slot href="/game/inventories/5536/slot">Y</slot> 
    .... 
</inventory> 

लेकिन अन्य तरीके भी हो सकते हैं।

जनवरी

Answer 4

क्योंकि सूची एक चरित्र मॉडल में सिर्फ एक हैश है, तो आप अपने महत्वपूर्ण स्लॉट्स हैश को संशोधित कि के रूप में आवश्यक से प्रत्येक के लिए कस्टम accessors साथ द्वारा प्राप्त कर सकते हैं।

बी को स्लॉट एक से RESTful कदम हो सकता है की तरह

PUT /inventory with params: 

{inventory => {:worn_on_head => nil, :worn_on_left_arm => @item}} 

कुछ आप संभवतः सत्यापन के साथ मानकों को सरल बनाने और फोन पीठ या यहाँ तक कि यह सुनिश्चित करने के लिए कि एक ही आइटम नहीं है accessors खुद को इस्तेमाल कर सकते हैं एकाधिक स्लॉट में। अनिवार्य रूप से की तरह कुछ करने के लिए एक स्थानांतरण अनुरोध के लिए मानकों को छोटा:

PUT /inventory with params: 

{:inventory => {:worn_on_left_arm => @item}} 

का अधिक सुरक्षित शर्त बस, एक उपयोगकर्ता एक आइटम की तुलना में वे राशि की और कॉपी लैस करने के लिए कोशिश करता है तो एक प्रमाणीकरण त्रुटि फेंक अन्य में से एक बदले बिना है परिवर्तन के समय वाले लोग।