Question

我们有一个案例，我们有一个休息端点，响应将根据应用程序流程而有所不同。 json中的属性会有所不同，所以问题是我们是否需要一个包含json的响应，该响应具有不同的结构，具体取决于应用程序流。

我现在基本上有三种选择。要么我们可以有两个属性，其中一个将始终为null（customer或businessCustomer）：

{
  "data": {
    "target": "Business",
    "customer": null,
    "businessCustomer": {
        ....
    }
}

{
  "data": {
    "target": "Customer",
    "customer": {
        ....
    },
    "businessCustomer": null,
}

或者我们只有一个属性，其中json对象的内容将不同（客户总是填充）：

{
  "data": {
    "target": "Customer or business",
    "customer": {
        ....
    }
}

我认为仅使用一个属性消耗数据可能很困难。你如何在强类型语言中以平滑的方式将其序列化......

哪种方式最好？提前谢谢！

Answer 1

我们在开发过程中遇到了类似的情况，并使用资源类型解决了它，并为所有子类创建了一个基类。它是一个通用实现，客户端代码负责检查@type并从他们那边创建相应的对象。

CustomerResource (Considering this as Base Class)
    BusinessCustomerResource (Extended from Customer Resource)

对于商业客户资源：

{
    "someOtherElement": "value",
    "customer" : {
                    "@type" : "BusinessCustomerResource",
                    "faxNumber" : "35635636",
                    "email" : "test@gmail.com",
                    "phone" : "2503334444",
                    "contactName" : "name",
                    "firstName" : "Owner",
                    "lastName" : "lastName"
                    ...
                    "address" : {
                      "@type" : "InternationalAddressResource",
                      "province" : "AB",
                      "country" : "Canada",
                      ...
                    }
                }
}

对于客户资源：

{
    "someOtherElement": "value",
    "customer" : {
                    "@type" : "CustomerResource",
                    "email" : "test@gmail.com",
                    "phone" : "2503334444",
                    "firstName" : "Owner",
                    "lastName" : "lastName"
                    ...
                    "address" : {
                      "@type" : "PostalAddressResource",
                      "province" : "AB",
                      "country" : "Canada",
                      ...
                    }
                }
}

Answer 2

我建议采用通用的响应格式。您可以在现实世界中观察类似的示例（例如：HTTP请求/响应）。

您可以将其标准化如下：

{
  "statusCode": 0,
  "statusDesc": "Response description",
  "value": null
}

此处 statusCode 和 statusDesc 在您的所有响应中都会很常见，值会根据api而改变（在您的情况下，您可以通过分别是客户或 businessCustomer ）。通过这样做，客户可以使用通用实用程序来了解它是否成功并采取相应的措施。

如何正确设计REST API响应？

2 个答案: