This concern was brought up in arch board. The question posed was that with supporting older API versions, should we (the client library) validate against arguments intended and only supported by the latest API version, or should we defer to the service? We need to check these scenarios to see how the service handles e.g. an action type that wasn't yet introduced in an older version. Another point made was that the client should not validate action types in a way that would make the entire request fail when the service might return partial results.
There are instances in the client library today where we perform client side validation of parameters to ensure better error messages. E.g. if keyword show_opinion_mining is passed into v3.0, we raise with an error that it is only supported in versions 3.1 or greater. The motivation for this is that with our multiapi code, if using the older api version which doesn't support it, the kwarg will get passed to e.g. requests and we get a non-helpful error - "requests got unexpected keyword 'show_opinion_mining'". Look into minimizing this where we can for language API and possibly leveraging version tolerant models (when ready) to address this issue.
This concern was brought up in arch board. The question posed was that with supporting older API versions, should we (the client library) validate against arguments intended and only supported by the latest API version, or should we defer to the service? We need to check these scenarios to see how the service handles e.g. an action type that wasn't yet introduced in an older version. Another point made was that the client should not validate action types in a way that would make the entire request fail when the service might return partial results.
There are instances in the client library today where we perform client side validation of parameters to ensure better error messages. E.g. if keyword
show_opinion_miningis passed into v3.0, we raise with an error that it is only supported in versions 3.1 or greater. The motivation for this is that with our multiapi code, if using the older api version which doesn't support it, the kwarg will get passed to e.g. requests and we get a non-helpful error - "requests got unexpected keyword 'show_opinion_mining'". Look into minimizing this where we can for language API and possibly leveraging version tolerant models (when ready) to address this issue.