API应该为int参数返回NULL吗?+如何处理

Question

目前，我们的API正在为任何没有值的int参数返回NULL。

例如，在我们的用户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文档中说的内容如下：

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

这也让我感到肮脏。

(再说一遍，我正在用字符串初始化NSDecimalNumbers……所以我不知道为什么这会困扰我……)。

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
}