This idea looks fantastic!
I have 2 questions:
What about “contract evolution”?
And by that, I mean versioning and breaking changes.
Modifying a contract by adding a field with a default value, it’s a backwards compatible change, but renaming a field would be a backwards incompatible change. Something like a “backup” contract might be a solved problem, but I bet there will be contracts that are too green and will need to evolve over time.
In Kubernetes, resources have like: apiVersion: gateway.networking.k8s.io/v1. In avro, there’s the concept of “schema evolution”, where you can say “this schema accepts only backwards compatible changes”.
What about features support within a contract?
Where do you draw the line in what’s supported and what it’s not, let’s say on a reverse_proxy? Could it be composed of a subset of contracts?
Let’s say tomorrow there’s a new ACME Challenge, or a reverse proxy adds support for HTTP/4, and you want to enable that feature? How does a Reverse Proxy implementation says “I support this but not that”?