我有一个Web服务API。某些调用返回包含文本字段的对象,其中包含用户提供的信息。从设计和安全的角度来看,在没有提供信息的情况下,在这些字段中返回null的缺点是什么?是否有明显的优势,总是返回一个空字符串,然后通过不要求客户端代码检查空值来简化API?
答案 0 :(得分:1)
这完全取决于您是否将空字符串值视为与空字符串在语义上不同。
如果null和空字符串都表示该字段没有数据,那么我认为没有理由不通过不检查并返回空字符串来使客户端的生活更简单。
答案 1 :(得分:1)
简答:请勿在网络服务中使用null。
一般来说,我建议坚持空字符串超过null,除非含义是零字符。我宁愿只使用null作为“未定义”。例如,对于用户输入,如果用户输入字段并且不输入任何内容,那么这将是一个空字符串。但是如果用户只是跳过该字段,则可能为空。
直到我定义null的含义,我赞成返回一个空字符串并在处理端使用String.IsNUllOrEmpty,因为代替任何未来的知识,我应该假设null和empty是相同的。
但是,网络服务有一个特殊的转折点,即
,<element/>
<element/>
与缺少元素的差异之间的工具错误不仅仅是公平的。足够混淆,除非我控制整个事情,否则我不相信互操作性是可以接受的。
因此,如果我需要表示像null这样的概念,我将创建一个单独的布尔元素来指示存在/不存在。
答案 2 :(得分:1)
我个人更喜欢返回空值而不是空字符串。 如果数据库具有空值,则返回该值的Web服务理想情况下应返回null而不是空字符串。
话虽如此,我遇到过像Adobe Flex这样的Web服务客户端无法真正使用空值的问题,如果无法修改客户端,则可能需要传入一个空字符串。
我没有看到任何安全问题。
答案 3 :(得分:0)
我认为返回null与返回空字符串存在安全问题。
对于那些没有信息的字段,返回null没有任何真正的缺点 - 这就是空值的含义。
您可以使用
简化客户端代码string.IsNullOrEmpty()
(假设这是.NET)
答案 4 :(得分:0)
Null只表示null。那里没有固有的安全问题。
由于Web服务是一个公共API,您应该严格检查所有输入数据并期望发生格式错误的输入。您永远不能假设客户端代码做正确的事情并且不会(恶意或其他方式)向您发送空值。
所以空字符串或其他标记值不会使您无法检查输入,它们也不一定能让生活更轻松。语义上空的字符串也不为空,它们是空的。
对于它的价值,.net SoapFormatter为null生成的xml没有任何东西,这与空字符串不同。这是一个微不足道的例子,但内容丰富。如果你发送null,你也会发送更少的数据,这可能需要考虑。
{
[WebMethod]
public MyClass HelloWorld()
{
MyClass val = new MyClass()
{
IsValid = false,
HelloString = "Hello World",
BlankString = "",
Nested = new NestedClass { Name = "Bob" }
};
return val;
}
}
public class MyClass
{
public bool IsValid { get; set; }
public string HelloString { get; set; }
public string BlankString { get; set; }
public string OtherString { get; set; }
public NestedClass Nested { get; set; }
public NestedClass NullNested { get; set; }
}
public class NestedClass
{
public string Name { get; set; }
}
产生以下xml响应。请注意,OtherString
和NullNested
完全从响应中丢失,与BlankString
不同。
<MyClass>
<IsValid>false</IsValid>
<HelloString>Hello World</HelloString>
<BlankString />
<Nested>
<Name>Bob</Name>
</Nested>
</MyClass>
答案 5 :(得分:0)
仅出于完整性考虑,假设您将一行数据或一组行数据作为JSON字符串返回,则始终有可能完全省略具有空值的字段。这样可以减少通过网络传输的数据,并且通常可以由任何客户端轻松处理(显然,此类约定应记录在某处)。参见例如以下杰克逊配置(它也忽略了空集合):
L123