smithy-lang / smithy

Smithy is a protocol-agnostic interface definition language and set of tools for generating clients, servers, and documentation for any programming language.
https://smithy.io
Apache License 2.0
1.7k stars 201 forks source link

Evolvability of operations with no input/output #2253

Closed david-perez closed 2 months ago

david-perez commented 2 months ago

I was under the impression that changing this model:

operation MyOperation { }

to this one:

operation MyOperation {
    input: MyOperationInput
    output: MyOperationInput
}

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:

operation MyOperation {
    input: smithy.api#Unit
    output: smithy.api#Unit
}

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.

mtdowling commented 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.

david-perez commented 2 months ago

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.