<@U1VBC6HJ7> maybe things look similar, but I'd ad...

# server

[dave]

@kenkyee maybe things look similar, but I'd add these questions into the mix:
1. can you modularise routes (for reuse) and nest those modules under common contexts?
2. Is the parameter extraction typesafe and how do you extend it to define your own types to (de)serialise?
3. How does the API cope with required/optional/defaulted parameters, or the multiplicity of those parameters? How about failure - do 400s get generated automatically?
4. How do you add request pre/post processing or app agnostic behaviour? Can those behaviours also be modularised?
5. Is there a model for form submission which includes error collection for invalid fields?
6. What about outgoing HTTP clients - is there a symmetrical model for outgoing requests - which means developers only have to contend with a single HTTP API and you can plug suites of services together in-memory?
7. Testing - can you test routes out-of-container and how easy is it to compare expected responses (in pure kotlin, we can use data classes for this)?
8. (Also testing): how much custom infrastructure is required to test routes or apps? This matters because your endpoint tests should be decoupled from your implementation, so at the very least it should be made easy to reuse tests at different scopes by just switching out the underlying client - or even switch out the impl entirely if you move to another framework.