Fintrospect a library that adds an intelligent HTTP routing layer to the Finagle RPC framework from Twitter. It provides a simple way to implement contracts for both server and client-side HTTP services
In theory, you could easily reuse the Query, Header, and Body extractors, but you'd need to deal with the validation cases yourself since the validation logic is encapsulated in the RouteModule. You could reuse this logic from RouteModule.scala:
private def validationFilter(route: ServerRoute[RQ, RS]) = Filter.mk[Request, Response, Request, Response] {
(request, svc) =>
route.routeSpec <--? request match {
case Extracted(extractedRequest) => svc(extractedRequest)
case ExtractionFailed(invalid) => Future(moduleRenderer.badRequest(invalid))
}
}
to recreate the Filter, but you need the ModuleRenderer instance and the ServerRoute. That would give you the validation layer which would give you the automatic 400 generation.
Hi, @daviddenton . Thanks for the prompt response.
Apparently, FIntrospect and Finatra are competing implementations from the perspective of handling routes. From my scarse understanding of the two (actually zero in regards to FInstrospect), seems like I should let FIntrospect attend the request, perform validation and handle a Service[Request, Response] to Finatra.
Since I don't need any fancy rendering, just mundane HTTP Server and HTTP Client in my microservice, I don't see at this point what would be the advantage of handling the service to Finatra, since the most interesting thing, which is: routing, was already done at this point by FInstrospect.
I suppose that management of Futures is done by lower levels in Finagle anyway so, if I'm not mistaken, it does not make much difference if I have FIntrospect or Finatra on top of Finagle. I suppose I need to do a small PoC in order to understand better this matter.
.withDescriptionPath(_ / "api-docs") is where you set that value. By default it goes into the root of the module