returning null values from a web service call

Question

I have a web service API. Some calls return objects containing text fields with information provided by the user. From both a design and a security standpoint, what are the downsides to returning null in those fields when no information has been provided? Is there a clear advantage to always returning an empty string instead, other then simplifying the API by not requiring the client code to check for nulls?

Answer 1

I don't think there's a security issue involved with returning null vs. returning an empty string.

There's not any real downside to returning null for those fields for which there is no information - that's kind of what nulls are meant to indicate.

You can simplify your client code by using

string.IsNullOrEmpty()

(assuming this is .NET)

Answer 2

It all depends on whether you treat a null string value as semantically different from an empty string.

If null and empty string both mean that there's no data for that field then I see no reason not to make life simpler for the client by not having to check and return empty string.

Answer 3

Null just means null. There's no inherent security issue there.

As a web service is a public API, you should be rigorously checking all input data and expect badly-formed input to occur. You can never assume that the client code does the right thing and doesn't send you null either (maliciously or otherwise).

So Empty strings or other sentinel values don't save you from checking input, and they don't necessarily make life easier either. Semantically empty strings aren't null either, they're empty.

For what it's worth, the xml generated by the .net SoapFormatter for a null is plain old nothing, and that's not the same as an empty string. It's a trivial example, but informative. If you send null you're also sending less data, which may be something to consider.

{
    [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; }
}

yields the following xml response. Note how OtherString and NullNested are missing entirely from the response, which is different to BlankString.

<MyClass>
  <IsValid>false</IsValid> 
  <HelloString>Hello World</HelloString> 
  <BlankString /> 
  <Nested>
    <Name>Bob</Name> 
  </Nested>
</MyClass>

Answer 4

Short answer: Don't use null in web-services.

In general I advise sticking to empty strings over null unless when the meaning is zero characters. I would prefer to use null only as an "undefined". For example, with user input, if the user enters the field and types nothing, that would be an empty string. But if the user simply skips the field, that might be null.

Up until I define a meaning for null, I favor returning an empty string and using String.IsNUllOrEmpty on the processing side, because in lieu of any future knowledge, I should assume null and empty are the same.

But web-services have a special twist, which is that there has been more than a fair share of mistakes in tools between the differences in <element/>, <element></element> and the element simply being missing. Enough confusion that unless I control the whole thing I don't trust the interoperability to be acceptable.

So if I have a concept like null that I need to represent, I'll create a separate boolean element to indicate present/not present.

Answer 5

I personally prefer returning nulls instead of empty strings. If the database has a null value, a web service returning that value should ideally return null instead of an empty string.

Having said that, I have come across problems where web service clients like Adobe Flex cannot really work with nulls, and you might have to pass in an empty string if the client cannot be modified.

I don't see any security issues either way.