एक सामाजिक नेटवर्क पर विचार करें। इसके पोस्ट हैं। फ़ीड के लिए, आप अनुरोध करते हैं /feed और पदों की सूची प्राप्त करें।
यूआई में, किसी पोस्ट के लिए दिखाने के लिए चीजें हैं, जैसे कि उपयोगकर्ता को पोस्ट पसंद आया या नहीं, अगर उपयोगकर्ता ने इसे तारांकित किया या नहीं, आदि ये चीजें नहीं दिखती हैं, जैसे वे पोस्ट ऑब्जेक्ट के अंदर हैं।
एक और मामला है जब आप पसंद को प्राप्त करते हैं। सीमांत को यह जानना होगा कि प्रत्येक "जैसे" ऑब्जेक्ट में उपयोगकर्ता का अनुसरण किया जा रहा है या नहीं।
प्रतिक्रिया JSON में यह जानकारी कहां रखी जाए?
उत्तर:
जवाब के लिए 2 № 1यह आपके एप्लिकेशन पर निर्भर करता है और आप उपयोगकर्ता को कौन सा डेटा दिखाना चाहते हैं। पूर्व के लिए, विचार करें कि आप उपयोगकर्ता के फ़ीड को सूचीबद्ध कर रहे हैं। उस फ़ीड में, आप दिखाना चाहते हैं
- संदेश
- वर्तमान उपयोगकर्ता द्वारा पसंद किया गया है या नहीं (मुझे पसंद नहीं है और स्टार्स के बीच का अंतर पता नहीं है)
- पसंद की संख्या
- पसंद किए गए उपयोगकर्ताओं की सूची।
- उपयोगकर्ता द्वारा साझा किया गया है या नहीं
- साझा की गई गणना
- उपयोगकर्ताओं की सूची
आदि..
उपरोक्त सूची में,
कुछ डेटा को पूरी जानकारी प्राप्त करने के लिए दो एपि की जरूरत होती हैऔर कुछ नहीं। उदाहरण के लिए, "पसंद किए गए उपयोगकर्ताओं की सूची", "साझा उपयोगकर्ताओं की सूची"। यह आम तौर पर एक गतिशील डेटा मॉड्यूल है। आपको सर्वर के बेहतर प्रदर्शन और डेटा अखंडता के लिए एक अलग एपीआई में उन विवरणों को प्राप्त करना होगा।
कुछ मामलों में, कुछ ऐप्स को सूचीबद्ध पृष्ठ में पसंद किए गए साझा किए गए उपयोगकर्ताओं की जानकारी को चुपके से देखने की आवश्यकता है। उस स्थिति में, आप कुछ निश्चित छोटी संख्या के उपयोगकर्ताओं को एक ही सूची में शामिल कर सकते हैं /feeds स्वयं प्रतिक्रिया दें और UI में "See More (जैसे फेसबुक)" विकल्प शामिल करें।
कुछ स्थिर विलक्षण डेटा (एकल स्तंभ डेटा) को प्रारंभिक प्राप्त करने में सूचीबद्ध किया जा सकता है /feeds अपने आप।
मुझे आश्चर्य है कि क्यों आप एक ही चहचहाना की सूची शैली का पालन नहीं करते हैं,
https://dev.twitter.com/rest/reference/get/search/tweets
{
"coordinates": null,
"favorited": false,
"truncated": false,
"created_at": "Fri Sep 21 23:40:54 +0000 2012",
"id_str": "249292149810667520",
"entities": {
"urls": [
],
"hashtags": [
{
"text": "FreeBandNames",
"indices": [
20,
34
]
}
],
"user_mentions": [
]
},
"in_reply_to_user_id_str": null,
"contributors": null,
"text": "Thee Namaste Nerdz. #FreeBandNames",
"metadata": {
"iso_language_code": "pl",
"result_type": "recent"
},
"retweet_count": 0,
"in_reply_to_status_id_str": null,
"id": 249292149810667520,
"geo": null,
"retweeted": false,
"in_reply_to_user_id": null,
"place": null,
"user":
{
"profile_sidebar_fill_color": "DDFFCC",
"profile_sidebar_border_color": "BDDCAD",
"profile_background_tile": true,
"name": "Chaz Martenstein",
"profile_image_url": "http://a0.twimg.com/profile_images/447958234/Lichtenstein_normal.jpg",
"created_at": "Tue Apr 07 19:05:07 +0000 2009",
"location": "Durham, NC",
"follow_request_sent": null,
"profile_link_color": "0084B4",
"is_translator": false,
"id_str": "29516238",
"entities": {
"url": {
"urls": [
{
"expanded_url": null,
"url": "http://bullcityrecords.com/wnng/",
"indices": [
0,
32
]
}
]
},
"description": {
"urls": [
]
}
},
"default_profile": false,
"contributors_enabled": false,
"favourites_count": 8,
"url": "http://bullcityrecords.com/wnng/",
"profile_image_url_https": "https://si0.twimg.com/profile_images/447958234/Lichtenstein_normal.jpg",
"utc_offset": -18000,
"id": 29516238,
"profile_use_background_image": true,
"listed_count": 118,
"profile_text_color": "333333",
"lang": "en",
"followers_count": 2052,
"protected": false,
"notifications": null,
"profile_background_image_url_https": "https://si0.twimg.com/profile_background_images/9423277/background_tile.bmp",
"profile_background_color": "9AE4E8",
"verified": false,
"geo_enabled": false,
"time_zone": "Eastern Time (US & Canada)",
"description": "You will come to Durham, North Carolina. I will sell you some records then, here in Durham, North Carolina. Fun will happen.",
"default_profile_image": false,
"profile_background_image_url": "http://a0.twimg.com/profile_background_images/9423277/background_tile.bmp",
"statuses_count": 7579,
"friends_count": 348,
"following": null,
"show_all_inline_media": true,
"screen_name": "bullcityrecords"
},
"in_reply_to_screen_name": null,
"source": "web",
"in_reply_to_status_id": null
}
उत्तर № 2 के लिए 1
सभी उपयोगकर्ताओं के लिए, पोस्ट संसाधन समान होना चाहिए। इसके अंदर विशिष्ट उपयोगकर्ता संदर्भ जानकारी जोड़ना ऐसा लगता है जैसे यह प्रदूषित कर रहा है
मैं देख सकता हूं कि आप कहां से आ रहे हैं और मैं काफी सहमत हूं।
इवान के 1 समाधान का उपयोग उसे नहीं करना चाहिएपहले से ही उल्लेख किया गया है, उसका दूसरा बेहतर है, लेकिन तब यदि आप JSON के पदों को प्राप्त करते हैं जिसमें केवल पोस्ट ऑब्जेक्ट होना चाहिए, तो यह भी वर्तमान है कि वास्तव में वहाँ नहीं हैं।
मेरा सुझाव यह है कि प्रत्येक पद के लिए आप रखेंजिन उपयोगकर्ताओं ने इसे पसंद किया है और / या इसे तारांकित किया है, आदि का ट्रैक करते हैं, फिर भी आप एक ही अनुरोध / प्रतिक्रिया में उपलब्ध जानकारी की आवश्यकता होने पर भी एक साफ संरचना रखते हैं।
उदाहरण
GET /feed HTTP/1.1
[
{
"text": "hello world, im a post!",
"author": "Jack",
"likes": 3,
"likedBy": [
"John",
"James",
"Jessica"
],
"stars": 2,
"starredBy": [
"John",
"Mary"
]
},
{
"text": "hello world, im also a post! :D",
"author": "Mary",
"likes": 1,
"likedBy": [
"James"
],
"stars": 0,
"starredBy": [
]
},
]
जहां प्रत्येक {} ऑब्जेक्ट एक पोस्ट ऑब्जेक्ट का प्रतिनिधित्व करता है।
क्लाइंट की तरफ, आप तब जांच सकते हैं कि क्या likedBy सूची में वर्तमान में उपयोगकर्ता लॉग इन है और जैसा कि आप फिट देखते हैं परिणाम के साथ आगे बढ़ें। सितारों और इन गुणों के किसी भी एक पोस्ट के लिए एक ही हो सकता है।
उत्तर № 3 के लिए 1
आपके पास दो विकल्प हैं:
उपयोगकर्ता संदर्भ डेटा के बारे में जानकारी प्राप्त करने के लिए एक अलग एपीआई विधि बनाएं -
/api/users/1/feeds/1ध्यान दें, यह विकल्प आपको प्रति फ़ीड अनुरोध भेजने के लिए मजबूर करेगा। इसलिए, यदि आपके पास 1000 फ़ीड होंगे - तो आपके पास 1000 + 1 अनुरोध होगा (तथाकथित एन + 1 समस्या)।
मेरे लिए - यह एक अच्छा विचार नहीं है।आप उपयोगकर्ता डेटा को json में संग्रहीत कर सकते हैं, उदाहरण के लिए यह इस प्रकार है:
{ "feedName": "feed1", ... "currentUser": { "liked": true, "starred": true } }इस विकल्प का उपयोग करके आप अपनी Restful सेवा में N + 1 अनुरोध समस्या से बचेंगे