enhance PathPrefixServiceHandler to support both path and method

[stevehu]

In order to allow light-router to discover services, the serviceId must be in the header of the client request. This is a little intrusive to the client so I have built the PathServiceHandler to allow mapping from the requesting endpoint to a serviceId and put into the request header automatically. It depends on the endpoint in the auditInfo attachment populated by the openapi-meta or swagger-meta from light-rest-4j.

There are two drawbacks.

• It assumes that the backend service is REST only.
• The backend service openapi.yaml/json or swagger.json must be deployed to the light-router instance. It might be OK if there is only one service behind the light-router but most of the cases, there are multiple services behind the light-router.

Given the inconvenience, @logi created PathPrefixServiceHandler which can determine the serviceId from the path prefix. This works in his use case very well and I am using it for some of our services. However, there is room to improve it after we have support handler.yml with multi-chains. The current implementation only considers the path prefix and cannot handler the following scenarios.

• If you have two services share the same prefix. For example, in CQRS, the read service and write service might have the same path but get and post methods.
• For some of the services that cannot be differentiated by just the prefix. We need to further parse into the path parameters.

Since we are parsing the path and method in the handler module, we can use the result to map to serviceId in this middleware handler. This gives us more flexibility and hides the logic from the original client. My suggestion is to create a new middleware handler and deprecate PathServiceHandler and PathPrefixServiceHandler but keep them for a while in case someone is using it. What do you think?

[stevehu]

#30

[stevehu]

enhance PathPrefixServiceHandler to support both path and method