CODEWITHSUNDEEP
web-services
user14128
user14128

Reputation: 2575

returning null values from a web service call

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?

Upvotes: 3

Views: 11098

Answers (6)

Remigius Stalder
Remigius Stalder

Reputation: 2170

just for completeness, assuming you return a row or a set of rows of data as a JSON string, there is always the possibility to completely omit fields with null values. this results in less data transferred over the network and can typically be handled easily by any client (obnviously, such a convention should be documented somewhere). see e.g. the following jackson configuration (it also omits empty collections):

private static ObjectMapper configureMapper(ObjectMapper mapper) {
  mapper.setDefaultPropertyInclusion(JsonInclude.Value.construct(JsonInclude.Include.NON_EMPY, JsonInclude.Include.NON_NULL));
  mapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);
  return mapper;
}

Upvotes: 0

Ra.
Ra.

Reputation: 289

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.

Upvotes: 1

nedruod
nedruod

Reputation: 1122

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.

Upvotes: 1

Robert Paulson
Robert Paulson

Reputation: 18061

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>

Upvotes: 0

Kev
Kev

Reputation: 119806

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.

Upvotes: 1

MusiGenesis
MusiGenesis

Reputation: 75296

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)

Upvotes: 0

Related Questions