I typically agree with @ecrisostomo on letting the server do the relevant validation.

We *do* want to minimize downstream work that we have to do if we change or introduce something in the REST API.  That being said, it is most important for the end-user to have as easy as a time as is possible when using the SDKs.

Because of this, I think I'm in favor letting the client [_fail fast_](http://en.wikipedia.org/wiki/Fail-fast), _in this particular scenario_, as this is typically a desirable property when it makes sense to support it.  Yes, we'd have to change the Python SDK in the future, but in this particular case, I'm not sure it will be something we have to address any time soon.  If it's already built, I'm inclined to let it in and try it out.

On a side note, we *should* change the error mechanism in the Python SDK to report the more meaningful developer messages to the developer.  These should be shown by default to the dev.  The generic 'message' error attribute is something the SDK user can use to show directly to their application end-user.  But if they don't the error should be crystal clear to the dev.

For example, we've changed this in the Java SDK to have `ResourceException.getMessage()` no longer report the Stormpath SDK error `message` attribute (it used to).  In stack traces, this app end-user message was of little use to the developer.

The [newest ResourceException](https://github.com/stormpath/stormpath-sdk-java/blob/master/api/src/main/java/com/stormpath/sdk/resource/ResourceException.java) implementation lets `exception.getMessage()` report a much nicer dev-centric exception message.

The app-end-user-focused simpler message will be available in a future release (e.g. `getUserMessage()` for example).

We should ensure the Python SDK has faults/errors function in this new way as well.