Improve the efficiency of request handling in ZIO Http & Play

[adamw]

The request is decoded once, and the decision whether a request should be handled by tapir is done based on the shape of the path

[frekw]

Amazing, great that you found a way to handle it @adamw! ❤️🎉

[gaeljw]

FYI, we had a minor regression in a - I believe - corner case usage due to this change.

We had:

• /api/something/ handled by Play router (routes file definition)
• /api/something (no trailing slash) handled by Tapir router and redirecting to the trailing slash endpoint

Because both routes were considered as having the same shape, the runtime exception was raised.

The path: ... matches the shape of some endpoint, but none of the endpoints decoded the request successfully, and the decode failure handler didn't provide a response. Play requires that if the path shape matches some endpoints, the request should be handled by tapir.

The setup was a bit weird in the 1st place and thus we moved both routes in the same router (Play in our case) and no more issue.

I believe that's expected behaviour and acceptable but commenting to let others know about it :)

[adamw]

@gaeljw Ah yes, this does sound like a scenario where this would break. Btw. you can write a redirect-to-slash endpoint, e.g.

tapir/docs/swagger-ui/src/main/scala/sttp/tapir/swagger/SwaggerUI.scala

Line 67 in fbe92fd

val redirectToSlashEndpoint = baseEndpoint

, using the noTrailingSlash input