Should we add validators to the API?

All cloud providers have constraints on configuration values and data that we should track on to ensure portability. Should we add validators to the API to reflect these constraints? Should we add a method to introspect these constraints for apps that might want to notify users of the constraints before values are submitted?

We could create an optional validation chain with Zend_Validate. This would self-document these constraints, making a handy reference for developers as a side effect.

The downside is that we’d have to keep up with changes in these constraints. One could argue, however, that these constraints are part of the API that we need to stay current on anyways.

Also, do these constraints belong in the client libs themselves? If so, might implementing them break backwards compatibility?

,Wil

Replies

Should we add validators to the API?

Reply by Peter on Nov 4, 2009

I think a validator should be part of the implementation of an adapter and be mostly hidden from the programmer. So, if I pass in a parameter that is fine for cloud provider A, it should be validated in the adapter then passed on. If I then switch cloud providers, to provider B, and that value in my code is now out of bounds, I would expect an exception to be generated by the adapter. At this time, if I want my code to be 100% interoperable between cloud provider A and B, I need to add some logic to my application that ensures that I only pass in valid params for the cloud providers I point my code at. Perhaps Zend_Validate (which I'm not familiar with) could be used to assist?

Add New Reply