Package com.networknt.router.middleware

Class PathPrefixServiceHandler

  • All Implemented Interfaces:
    LightHttpHandler, MiddlewareHandler, io.undertow.server.HttpHandler
    public class PathPrefixServiceHandler
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 a unique path prefix, 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

    Unlike PathServiceHandler, this handler does not require OpenAPIHandler or SwaggerHandler but is also unable to do any validation beyond the path prefix. Previously, this handler will skip the logic when server_url is in the header. However, since we have updated the TokenHandler to support multiple downstream hosts with different OAuth 2.0 servers, we need to put the service_id into the header regardless if the server_url is in the header. Also, this handler work on the best effort basis, so it only works if the prefix is in the config. This is the simplest mapping with the prefix and all APIs behind the http-sidecar or light-router should have a unique prefix. All the services of light-router is following this convention.

    Author:
    Logi Ragnarsson, Steve Hu