繁体   English   中英

在哪里将当前用户上下文数据放入响应JSON中?

[英]Where to put current user context data in response JSON?

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

在UI中,有一些要显示的内容,例如用户是否喜欢该帖子,用户是否对它加注星标等等。这些东西看起来并不像它们属于post对象内部。

另一种情况是您获取喜欢的商品。 前端需要知道是否关注每个“喜欢”对象中的用户。

将此信息放在响应JSON中的哪里?

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

  1. 信息
  2. 当前用户是否喜欢(我不喜欢“喜欢”和“被注视”之间的区别)
  3. 喜欢次数
  4. 喜欢的用户列表。
  5. 是否由用户共享
  6. 共享数
  7. 共享用户列表。

等等..

在上面的列表中,

有些数据需要两次api提取才能获取完整的信息,而另一些则不需要。 例如,“喜欢的用户列表”,“共享用户列表”。 这通常是一个动态数据模块。 您必须在单独的api中获得这些详细信息,以提高服务器的性能以及数据完整性。

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

一些静态的奇异数据(单列数据)可以在初始get /feeds本身中列出。

我不知道您为什么不遵循相同的Twitter列表推文样式,

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
}

您有两种选择:

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

  • 您可以将用户数据存储在json中,例如,通过这种方式:

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

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

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

我可以看到您来自哪里,我也很同意。

Ivan的第一个解决方案不应该像他已经提到的那样使用,他的第二个解决方案更好,但是如果您获取应该仅包含发布对象的发布JSON,则还有一个currentUser并不真正属于该发布对象。

我的建议是,对于每个帖子,您都要跟踪哪些用户喜欢和/或为其加注了星标,等等。然后,您可以保持结构简洁,同时在相同的请求/响应中仍可以获取所需的信息。

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列表是否包含当前登录的用户,并根据需要继续处理结果。 对于星标以及帖子可能具有的任何其他这些属性都相同。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM