Open david-perez opened 2 weeks ago
Services can have multiple protocols, each of which may or may not respect certain traits, so we can't reasonably fail a build in those cases.
I know, but can't we fail the build/emit a warning in the case where in all the protocols the service supports the traits are meaningless, like in the example I provided?
I think that would be confusing for cases where a shared definition of an operation is used by an RPC based service. The shared operation definition (e.g., TagResource) might define HTTP bindings in order to make it just work if the service uses HTTP bindings, and services that don't would ignore the bindings.
In RPC protocols like AWS JSON and RPC v2 CBOR, HTTP binding traits are currently allowed. For example, this model builds fine:
I think Smithy should disallow these traits if in all the protocols the service supports they are meaningless.