【问题标题】:Internal object representation when designing JSON apis设计 JSON api 时的内部对象表示
【发布时间】:2014-08-12 16:07:18
【问题描述】:

我有一个对象设计问题。

我正在用 Java 构建一个 json api。我的系统使用 pojos 来表示 json 对象,并使用 Jackson 将它们从 json 转换为 pojo。每个对象都需要在不同的上下文中采用不同的形式,我无法决定是创建一堆单独的类,为每个上下文创建一个类,还是尝试让一个通用类在所有情况下都有效。

让我举一个具体的例子。

系统有用户。该 api 具有添加、修改和删除用途的服务。数据库中有一个用户表。数据库记录如下所示:

{
  id: 123, // autoincrement
  name: "Bob",
  passwordHash: "random string",
  unmodifiable: "some string"
}

当您发布/添加用户时,您的 pojo 不应包含 id,因为它是自动生成的。您还希望能够包含密码,该密码经过哈希处理并存储在数据库中。

当你 PUT/更新用户时,你的 pojo 不应该包含不可修改的字段,但它必须包含 id,这样你就知道你正在修改哪个用户。

当您获取/检索用户时,您应该获取除密码哈希之外的所有字段。

因此,代表用户的 pojo 具有不同的属性,具体取决于您是添加、更新还是检索用户。它在数据库中具有不同的属性。

那么,我应该在我的系统中创建四个不同的 pojo 并在它们之间进行翻译吗?或者创建一个 User 类并尝试使用 Jackson 视图或其他机制使其在不同情况下看起来不同?

我发现后一种方法真的很难管理。

【问题讨论】:

  • 为什么要有 POJO?只需使用地图。
  • Pojo 很有帮助,因为它们可以轻松记录 Web 服务的输入和输出。

标签: java json web-services jackson


【解决方案1】:

在我看来,您应该只创建一个POJO - User,它具有所有需要的属性。现在您应该决定您的API 是严格还是宽松。如果您的API 是严格的,它应该在收到错误的JSON 数据时返回错误。在宽松的版本中,API 可以跳过多余的(不必要的)属性。

在提供示例之前,让我将“passwordHash”属性更改为“密码”。

添加新用户/POST
JSON 来自客户端的数据:

{
  id: 123,
  name: "Bob",
  password: "random string",
  unmodifiable: "some string"
}

严格的版本可以返回例如这样的东西:

{
    "status": "ERROR",
    "errors": [
        {
            "errorType": 1001,
            "message": "Id field is not allowed in POST request."
        }
    ]
}

Lenient 版本可以返回例如这样的内容:

{
    "status": "SUCCESS",
    "warnings": [
        "Id field was omitted."
    ]
}

对于每个CRUD 方法,您可以编写一组单元测试,这些单元测试将包含您选择的方式以及允许和不允许的信息。

【讨论】:

  • 我同意这一点。严格指定数据模式(例如,使用 XML 模式甚至 JSON 模式)的问题之一是验证决策不是数据固有的,而是流程的一部分。验证取决于您对数据所做的工作。因此,在这种情况下,最好将验证放入流程级别(API)而不是数据级别(POJO)。波斯特定律在这里很适用。
猜你喜欢
  • 1970-01-01
  • 2023-04-02
  • 2023-03-18
  • 1970-01-01
  • 1970-01-01
  • 2017-12-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多