[openstack-dev] [api] Optional Properties in an Entity

Kevin L. Mitchell kevin.mitchell at rackspace.com
Mon Jan 19 21:54:44 UTC 2015

On Mon, 2015-01-19 at 19:55 +0000, Douglas Mendizabal wrote:
> I’m curious about something that came up during a bug discussion in
> one of the Barbican weekly meetings.  The question is about optional
> properties in an entity.  e.g. We have a Secret entity that has some
> properties that are optional, such as the Secret’s name.  We were
> split on what the best approach for returning the secret
> representation would be when an optional property is not set.
> In one camp, some developers would like to see the properties returned
> no matter what.  That is to say, the Secret dictionary would include a
> key for “name” set to null every single time.  i.e.
> On the other camp, some developers would like to see optional
> properties omitted if they were not set by the user.
> The advantage of always returning the property is that the response is
> easier to parse, since you don’t have to check for the existence of
> the optional keys.  The argument against it is that it makes the API
> more rigid, and clients more fragile.

I keep trying to come up with technical arguments for or against, and
the only one I can come up with that has any true meaning is that
omitting properties reduces bandwidth usage a little…but I don't really
think that's something we've particularly concerned about.  Thus, from a
technical perspective, either way is perfectly fine, and we just have to
answer consistency.

When we look at consistency, we look at everything else in OpenStack.
>From the standpoint of the nova API (with which I am the most familiar),
I am not aware of any property that is ever omitted from any payload
without versioning coming in to the picture, even if its value is null.
Thus, I would argue that we should encourage the first situation, where
all properties are included, even if their value is null.
Kevin L. Mitchell <kevin.mitchell at rackspace.com>

More information about the OpenStack-dev mailing list