In the case of asking for something that should never exist, I think an exception could be in order (though I have qualms due to cross-version connections), but for something that _might_ be there, and is requested along with a number of other fields, throwing an exception and returning no data seems bad to me. For example, if I request  zone information and device information, to display on a page that lists other devices in the area, and the device isn't in a zone, then I'll get a 500 and will have to re-request, leaving out particular fields until I get a successful subset, which seems inefficient and messy. If we were only allowing one field to be requested at a time, then an abortive "500" would also make more sense to me.

How about:
* If a field is "understood" (the device knows about it), but it doesn't have a value (e.g. no zone membership), instead of leaving it out like we're doing here, we should explicitly return with it set to null. This makes semantic sense to me: "What's your zone?" -> None.
* If a field isn't understood by the server (e.g. if the client is a newer version), it could ignore it but then add the field name to a list of "invalid_fields" that gets returned as a field on the response.

Thoughts?