While requesting random fights is great, what if we introduced a "fairness" setting in the UI. Sometimes we get fights that don't seem fair, where one fighter is a level 10 and the other is 10,000,000.
We could have a dropdown/radio button/whatever that, when selected in the UI, gave a choice to the user. Something like
- Weaklings
- Average
- Super strong
- Super-duper strong
We can certainly come up with better names/categories, but whatever we come up with we'd assign ranges of fighter levels to each term. The weakling would be anything <= some number and the Super-duper strong would be anything >= some number.
We'd pass that on the getRandomFighters call to rest-fights, which would in turn pass to the rest-heroes & rest-villains. rest-heroes & rest-villains would guarantee that only a fighter between those levels would be returned.
We could use this scenario to really showcase consumer-driven contract testing where making sure rules within the contract between consumers & producers stipulates the requirement in the contract.
So for example, in the rest-fights consumer contract you'd have something in the contract that said
When I (the rest-fights consumer requests a random hero/villain between a certain level, the level attribute in the response from the rest-heroes/rest-villains service should be between the values passed in the request.
Thats the kind of thing that can't be done using straight OpenAPI.
While requesting random fights is great, what if we introduced a "fairness" setting in the UI. Sometimes we get fights that don't seem fair, where one fighter is a level 10 and the other is 10,000,000.
We could have a dropdown/radio button/whatever that, when selected in the UI, gave a choice to the user. Something like
We can certainly come up with better names/categories, but whatever we come up with we'd assign ranges of fighter levels to each term. The weakling would be anything <= some number and the Super-duper strong would be anything >= some number.
We'd pass that on the
getRandomFighterscall torest-fights, which would in turn pass to therest-heroes&rest-villains.rest-heroes&rest-villainswould guarantee that only a fighter between those levels would be returned.We could use this scenario to really showcase consumer-driven contract testing where making sure rules within the contract between consumers & producers stipulates the requirement in the contract.
So for example, in the
rest-fightsconsumer contract you'd have something in the contract that saidThats the kind of thing that can't be done using straight OpenAPI.