Class PathServiceHandler

  • All Implemented Interfaces:
    LightHttpHandler, MiddlewareHandler, io.undertow.server.HttpHandler

    public class PathServiceHandler
    extends Object
    implements MiddlewareHandler
    When using router, each request must have serviceId in the header in order to allow router to do the service discovery before invoke downstream service. The reason we have to do that is due to the unpredictable path between services. If you are sure that all the downstream services can be identified by the path, then you can use this Path to ServiceId mapper handler to uniquely identify the serviceId and put it into the header. In this case, the client can invoke the service just the same way it is invoking the service directly. Please note that you cannot invoke /health or /server/info endpoints as these are the common endpoints injected by the framework and all services will have them on the same path. The router cannot figure out which service you want to invoke so an error message will be returned This handler depends on OpenAPIHandler or SwaggerHandler in light-rest-4j framework. That means this handler only works with RESTful APIs. In rest swagger-meta or openapi-meta, the endpoint of each request is saved into auditInfo object which is attached to the exchange for auditing. This service mapper handler is very similar to the ServiceDictHandler but this one is using the light-rest-4j endpoint in the auditInfo object to do the mapping and the other one is doing the path and method pattern to do the mapping.
    Author:
    Steve Hu