Allow for third-party routing logic to tap into the Tapir backends about tapir HOT 3 OPEN

I wouldn't at all mind integrating with smithy4s, though I'm not sure if this integration would make much sense. Going along with your proposition, we would have to add a method like:

def toRoutes(interpreter: ThirdPartyInterpreter[F]): HttpRoutes[F]

to each of our interpreters. This workload seems equivalent to simply adding these integrations in the smithy repo? I think the only piece of code that you would reuse is the RequestBody / ToResponseBody implementations. Although, they are quite low level, and where only ever envisioned to be used by server interpreters - not when implementing endpoints (same with RawBodyType, I wouldn't expect an end-user to use this). And do you need their flexibility - that is, how would you use the RequestBody and ToResponseBody implementations in your integration?

from tapir.

though I'm not sure if this integration would make much sense

I'm afraid integrating with the high-level Tapir "Endpoint" construct would require a significant amount of (albeit interesting/fun) work, and I'm quite unsure it'd allow to cater to some of the edge cases that are inherent to smithy protocols that we're already catering to in smithy4s.

Providing access to lower level constructs that'd allow to circumvent the Tapir Endpoint construct and tap directly into the lower levels http requests would allow for the integration to benefit from a large area-surface of Tapir, as well as a large area-surface of Smithy4s, without inducing a large amount of glue code to translate high-level concepts from one side to the other. That's what the POC aims at proving.

Going along with your proposition, we would have to add a method like [...] to each of our interpreters

That is unfortunately correct. I 100% understand why it seems annoying. I however think that it'd allow potentially other third parties than Smithy4s to integrate with Tapir in a similar fashion, which may be desirable (or not, depending on your point of view).

This workload seems equivalent to simply adding these integrations in the smithy repo

Not really, because a lot of the details of the translation from third-party request/response models have been made private in Tapir. The proposed solution doesn't require making those constructs to become public. Moreover Tapir already publishes artifacts for all the libraries it integrates with, which means that the build infrastructure, as well as the test infrastructure required to test the integrations is already present.

It's also worth noting that the ThirdPartyIntepreter interface in the proof-of-concept PR is pretty close to the existing ServerInterpreter construct in Tapir, the main difference being that the B and S type parameters are moved away from the interface and into the method, allowing for a larger degree of polymorphism, at the cost of hiding away the underlying streaming constructs away from the user. But topically it remains something that "belongs" to Tapir, imho (though it's certainly not my prerogative to say so).

Although, they are quite low level, and where only ever envisioned to be used by server interpreters - not when implementing endpoints (same with RawBodyType, I wouldn't expect an end-user to use this)

Well the point is to NOT interface with Tapir's Endpoint construct, but rather to tap into the lower level allowing to interact with the third-party specific constructs. Smithy4s has its own concept of endpoint and its own concept of HttpRequest and HttpResponse, so translating those to Tapir's own ServerRequest and ServerResponse models (and vice versa) is a lot more straightforward.

And do you need their flexibility - that is, how would you use the RequestBody and ToResponseBody implementations in your integration?

Well for better or worse, so far Smithy4s is dealing only with "unary" endpoints (as opposed to "streaming" endpoints) , so knowing exactly how the underlying body is handled by specific libraries it not really important to us at this point. RequestBody and ToResponseBody are interesting/required because of how they allow for translating common byte representations to third-party specific representations and vice versa, by catering to the lowest common denominator that is java types (byte array, byte buffer, input/output streams).

See :

• toResponseBody usage
• [fromRequestyBody usage](requestBody <- fromRequestBody.toRaw(request, RawBodyType.ByteArrayBody, maxBytes))

from tapir.