आरईएसटी संसाधन पदानुक्रम की संरचना कैसे करें?

Question

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

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

/users 
     /{id} 
      /location 
      /about 
      /name 
      /seller_rating 
      /bought 
      /sold 

उत्पादों के लिए: यहाँ कैसे मैं यूआरआई पदानुक्रम,

उपयोगकर्ताओं के लिए की संरचना करने के लिए शुरू किया है

/products 
     /{id} 
       /name 
       /category 
       /description 
       /keywords 
       /buyer 
       /seller 

इन दोनों मामलों में प्रत्येक पदानुक्रम संदर्भ सबसेट में वस्तुओं अन्य पदानुक्रम में वस्तुओं का। उदाहरण के लिए /users/{id}/bought उन उत्पादों की एक सूची है जो कुछ उपयोगकर्ता ने खरीदी हैं, जो /products का सबसेट है। इसके अलावा, /products/{id}/seller उस उपयोगकर्ता को संदर्भित करता है जिसने एक विशिष्ट उत्पाद बेचा है।

चूंकि इन यूआरआई के संदर्भ अन्य ऑब्जेक्ट्स, या अन्य ऑब्जेक्ट्स के सबसेट्स, एपीआई को इस तरह की चीजों को समर्थन देना चाहिए: /users/{id}/bought/id/description और /products/{id}/buyer/location? क्योंकि अगर उन प्रकार के यूआरआई समर्थित हैं, तो इस /users/{id}/bought/{id}/buyer/bought/{id}/seller/name जैसे कुछ को रोकने के लिए क्या है, या कुछ समान रूप से घुलनशील है? इसके अलावा, इस मामले में, आप रूटिंग को कैसे संभालेंगे क्योंकि सर्वर में राउटर को यूआरआई की मनमानी लंबाई की व्याख्या करना होगा?

Answer 1

लक्ष्य सुविधाजनक संसाधन पहचानकर्ताओं का निर्माण करना है, सब कुछ पार करने का प्रयास न करें। तुम्हें पता है, यूआरएल प्रतिनिधित्व :)

लिंक /product/{id}/buyer की तरह मौजूद कभी नहीं करना चाहिए में अपने डेटाबेस संबंधों को दोहराने की जरूरत नहीं है क्योंकि वहाँ पहले से ही है कि संसाधन के लिए पहचानकर्ता है: /user/{id}

हालांकि यह /product/{id}/buyers-list के लिए ठीक है, क्योंकि खरीदारों की सूची उत्पाद की एक संपत्ति है जो अन्य संदर्भों में मौजूद नहीं है।

Answer 2

आपको इसे एक सीआरयूडी फैशन में सोचना चाहिए, जहां प्रत्येक इकाई क्रमशः जीईटी, पोस्ट, पुट, और हटाए गए HTTP क्रियाओं का उपयोग करके, पढ़ें, पढ़ें, अपडेट करें और हटाएं()।

इसका मतलब है कि आपके एंडपॉइंट आमतौर पर केवल एक स्तर गहरे होंगे। उदाहरण के लिए

उपयोगकर्ता

GET /users  - Return a list of all users (you may not want to make this publically available) 
GET /users/:id - Return the user with that id 
POST /users  - Create a new user. Return a 201 Status Code and the newly created id (if you want) 
PUT /users/:id - Update the user with that id 
DELETE /users/:id - Delete the user with that id 

और अधिक विस्तार में जा रहे हैं, इस तरह के रूप /users/:id/about संभावना आवश्यक नहीं है। हालांकि यह काम कर सकता है, यह थोड़ा ओवरपेसिफिक हो सकता है।

शायद आपके मामले में आप में जोड़ सकते हैं:

GET /users/:id/bought - Array of products that the user bought 
GET /users/:id/sold - Array of products that the user sold 

आप एक (जो उत्पादों एपीआई के माध्यम से दिलवाया जा सकता है) आईडी की सूची में वापसी कर सकता है जहां, या आप उन्हें वापस भेजने से पहले अगर उत्पाद को पॉप्युलेट सकता है तुम चाहो।यदि आप उन्हें पॉप्युलेट करना चुनते हैं, तो शायद आपको प्रत्येक उत्पाद द्वारा संदर्भित उपयोगकर्ताओं को पॉप्युलेट नहीं करना चाहिए। इससे परिपत्र में वृद्धि होगी और गलत है।

और उत्पादों के लिए, अपने sitation में मैं का प्रयोग करेंगे:

GET /products- Return a list of all products 
GET /products/:id - Return the products with that id 
POST /products- Create a new product. Return a 201 Status Code and the newly created id (if you want) 
PUT /products/:id - Update the product with that id 
DELETE /products/:id - Delete the product with that id 

GET /products/:id/buyers  - Array of who bought the product 
GET /products/:id/sellers - Array of everyone selling the product