在哪里放置当前用户上下文数据以响应JSON?

时间:2015-09-23 07:27:36

标签: json api rest social-networking

考虑一个社交网络。它有帖子。对于Feed,您请求/feed并获取帖子列表。

在用户界面中,有一些内容可以为帖子显示,例如,如果用户喜欢该帖子,用户是否加星标等等,这些事情看起来都不属于帖子内部对象

另一种情况是你拿到喜欢的东西。前端需要知道每个用户是否喜欢'对象是否被遵循。

将此信息放在响应JSON中的位置?

3 个答案:

答案 0 :(得分:2)

它取决于您的应用程序以及您要向用户显示的数据。例如,请考虑列出用户的Feed。在该Feed中,您想要显示

  1. 消息
  2. 当前用户喜欢与否(我不知道喜欢和盯着之间的区别)
  3. 喜欢的数量
  4. 喜欢的用户列表。
  5. 由用户共享
  6. 共享点数
  7. 共享用户列表。
  8. 等。

    在上面的列表中,

    有些数据需要两次api fetch才能获得完整信息,有些则不需要。例如,"喜欢的用户列表","共享用户列表"。这通常是动态数据模块。您必须在单独的API中获取这些详细信息,以获得更好的服务器性能和数据完整性。

    在某些情况下,某些应用需要预览列表页面中喜欢的共享用户信息。在这种情况下,您可以在同一列表/feeds响应中包含一些固定的少量用户详细信息,并包括"查看更多(如Facebook)"用户界面中的选项。

    一些静态奇异数据(单列数据)可以在初始get /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
    }
    

答案 1 :(得分:1)

您有两种选择:

  • 制作单独的API方法,以获取有关用户上下文数据的信息 - /api/users/1/feeds/1。请注意,此选项会强制您按Feed发送请求。因此,如果您有1000个Feed - 您将有1000 + 1个请求(所谓的N + 1个问题)。
    至于我 - 这不是一个好主意。

  • 您可以将用户数据存储在json中,例如这样:

    {
       "feedName": "feed1",
       ...
       "currentUser": {
             "liked": true,
             "starred": true
       }
    }
    

    通过使用此选项,您将避免RESTful服务中的N + 1请求问题

答案 2 :(得分:1)

  

对于所有用户,post资源应该相同。在其中添加特定的用户上下文信息似乎污染它

我可以看到你来自哪里,我非常同意。

Ivan的第一个解决方案不应该像他已经提到的那样使用,他的第二个解决方案更好但是如果你获得应该只包含post对象的帖子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列表是否包含当前登录的用户,并根据需要继续执行结果。对于星星以及帖子可能具有的任何其他属性也是如此。