Closed david-perez closed 2 months ago
An operation with no input or out is semantically equivalent to using Unit. Unit is assumed if no input or output is associated with an operation. Adding input or output after not initially adding one is a breaking change in the model. The best practice is to define an empty structure per operation:
operation DeleteFoor {
input := {}
output := {}
}
See https://smithy.io/2.0/spec/service-types.html#operation
That said, code generators are free to make an implicit input or output shape for an operation if that's what their users are used to. Many AWS generators do this and create synthetic input and output shapes for every operation that ignore the name given in the model to make normalized names.
I see, I had failed to read https://smithy.io/2.0/spec/service-types.html#operation. Now things make sense, thanks!
that ignore the name given in the model to make normalized names.
I had imagined this would be one reason, but in smithy-rs we've got documented that it was mainly because of backwards-compatibility. We'll have to update the docs for that transform.
Since evolvability is not an issue, I'm thinking of removing that transform for smithy-rs servers, since they are authoritative model consumers. So we'd honor the names for operation input/outputs in the model, and the user would work with operation handlers that don't have any inputs/outputs if in the model they're using the Unit
shape.
I was under the impression that changing this model:
to this one:
or vice-versa was considered a backwards-compatible change from Smithy's perspective (i.e. adding input/output to operation shapes).
And also that an operation with no input and output is not semantically equivalent to:
Is my understanding correct here? I don't know where I got this from, the evolving models page does not seem to have these provisions.