API 是否应该为 int 参数返回 NULL？ + 如何处理

Question

目前，我们的 API 对于任何没有值的

NULL

参数返回

int

。

例如在我们的用户 API 中，我们的参数之一如下所示：

{
    ...
    "user_id":NULL
    ...
}

我知道这不可能是

0

，因为这可能是有效的响应，但是拥有

NULL

指针会导致各种问题，因为

int

不能是

NULL

指针。

我的想法是这些值应该被完全忽略 - 然后它们会返回

nil

值（在目标 c 中，例如

[dictionary objectForKey:@"user_id"] == nil

），这似乎更合适，并且不检查空指针（这似乎是错误的， int 和指针之间有区别）。

否则，解决方法是将其变成需要指针的

NSNumber

对象，因此可以是

NULL

。然后我可以做类似的事情：

NSNumber *userID = [dictionary objectForKey:@"user_id"];
if(userID != [NSNull null]){
  // its not null
}

但对我来说，这感觉从根本上是错误的，

NSNumber

文档说这样的话：

请注意，数字对象不一定保留它们创建时所用的类型。

这也让我感觉很肮脏。

（话又说回来，我正在用字符串初始化

NSDecimalNumber

s...所以我不知道为什么这会困扰我...）。

Answer 1

如果您的“API”预计返回

int

，那么它永远不应该返回 NULL。就像你已经说过的，你可以使用

NSNumber

，在这种情况下你可以返回 NULL。当谈论

int

时，

NSNumber

不会带来数据丢失，只有在像无理数这样的情况下，不同的类型才会有影响。

所以简而言之，如果你想在某些情况下返回 NULL/nil，你必须使用对象类型，而不是

int

。如果您对使用

int

感觉更好，那么唯一的方法是使用特殊的“无效”值，例如

-1

或

-INT_MAX

让用户知道该值无效。或者，如果可以的话，您可以抛出异常 - 或者只是添加另一个方法来检查是否可以给出有效的响应。

Answer 2

如果API没有用户并且user_id是唯一返回的值，为什么不返回正文中没有任何内容的404状态代码。 然后你只需检查状态代码。 有道理，404==资源不存在。 利用 REST 并使用您的状态代码，不要返回带有 200 个状态代码的虚假资源。

但是，如果 user_id 只是返回的较大资源的一部分（例如与另一个资源的关系），那么如果没有为返回的资源设置 user_id，则 NULL 是完全合理的。

Answer 3

用API调用的成功结果制作一个状态键怎么样？这就是我在创建 API 响应时总是做的事情。它可能只是一个布尔值，指示它是否有效，或者是一个整数，指示如果不成功则发生什么错误。这样，如果 API 失败，您甚至不需要触摸本示例中的 user_id。

NSNumber *status= [dictionary objectForKey:@"status"];
if(status > 0){
    //succeed
}
else {
   //use status to indicate which error occured
}