smithy
smithy copied to clipboard
URI conflict validation is too constraining
Minimised repro
namespace foo
service Foo {
operations: [Hello1, Hello2]
}
structure Hello1Input {
@httpLabel
@required
name: String,
}
@http(method: "GET", uri: "/hello")
@readonly
operation Hello2 {
}
@http(method: "GET", uri: "/{name}/greet")
operation Hello1 {
input: Hello1Input,
}
Gives the following errors :

Expected behaviour :
These two URI paths should not be presenting a conflict, as there is always a possibility to distinguish between one and the other without additional informations.
I believe the cause of the problem is this condition which rakes too widely.
Yes, it is too constraining in several ways. We have a few proposals to make URI conflict resolution more flexible. I’m hoping we can finish those up and publish an RFC soon.
Is that RFC ready?
Bumped into this whilst trying to smithy-translate an API...
Another example from today:
GET /subscriptions/{id}
GET /subscriptions/device/{deviceId}
these shouldn't be conflicting as {id} isn't a greedy label. Is there any chance we can update this soon?
We are aware that the rule is too restrictive and we are planning to publish an RFC in the coming weeks to allow these and URIs that might conflict at runtime by specifying how the conflicts should be resolved by using the most specific URI, similar to what API Gateway does.
I will update this issue when the RFC is publish to get early feedback and make sure that the proposal covers your use cases.
I have opened a draft pull request for our current thinking about how to remove this restriction, if you have time we will appreciate your feedback on this proposal
Hey, I saw the pr about uri conflict resolution has been merged, yay 🎉!
Just wonder do We have any roadmap/plan to make it into smithy specification soon? thanks!
The RFC has been merged and the implemented in Smithy, see the updated docs here. Apologies for the late notice, I forgot about updating this thread.