feature request: Add path based routing

[mingfang]

Currently APITools supports host based routing.
For our use case, we need path based routing.
e.g. http://www.mycompany.com/api/user, we need /api/user to route to an api

[mikz]

@mingfang so you need two different paths to go to two different APIs?
For example /api/user doing to User API and /api/history going to History API?

That is doable now with a middleware.

[mingfang]

Yes, my use case is similar to the traditional Nginx reverse proxy.
We use Nginx locations to point to different upstreams.
While our Nginx setup works, I would like to benefit from APITools' management and middleware functionality.
I will take a look at doing this using the middleware.

[mikz]

@mingfang it might not be polished experience

could you tell me more about the use case? do you need to change just the host ? or are you changing the path? like removing the prefix part

There are two ways to do it:

• use http client to get the response
• change the actual host where the request should go

We have outstanding internal issue about the second use case. If it would work for you, I would do it today or tomorrow and send you an example how to use it.

[mingfang]

Ultimately I want to use APITools as an api gateway for our micro service architecture.
The api gateway would dynamically discover new services and register their routes automatically.

We would use something like Consul for discovery.
https://hashicorp.com/blog/introducing-consul-template.html
Except I would use APITool's admin api to dynamically configure the routes.

After more reading it looks like you guys already have the router piece.
https://docs.apitools.com/blog/2014/04/24/a-small-router-for-openresty.html

It would be perfect is this can be added to APITools as a first class citizen,
with admin tools and monitoring.

[mingfang]

Here is another example http://openresty.org/#DynamicRoutingBasedOnRedis

[mikz]

@mingfang I made a PR to allow a change where the request will go. See #19

Would that work for you now? Without exposing the router? You could still use Lua stdlib to match strings from the start by almost regular expressions.

The only way how to do path based routing in APItools is via a middleware. That middleware can use external APIs to to discovery/fetch configuration.

[mingfang]

I will look into using middleware.
However I hope you will reconsider making path based routing a first class citizen in the future.
With this feature I can see Monitor becoming a perfect tool as an api gateway for micro services architecture.

[mikz]

@mingfang we definitely want to expose rack in the middleware

It can't be earlier than January, but the quick and dirty #19 can work now if you want to try it for a month.

[mingfang]

I'm starting to play with another API gateway named Tyk.io.
Here they talk about path based routing https://tyk.io/v1.3/api-management/api-definitions/
This is really useful for us.

[mikz]

Because we allow you to write Lua middleware, you can do the routing like:

function(req, next_middleware)
  if string.match(request.path, '^/some-path/') then
    return http.request(req)
  else
    return { status = 404 }
  end
end

Would that be enough for you? Exposing more things in the middleware is one way road. If we do it we can't take it back easily so I would prefer exposing as little as possible. If you have something on mind, please try to express it as simple pseudo middleware similar to one I posted. That way we can iterate on what is really needed.

I already have a PR #19 that allows redirecting one service to another, but it might not be needed. It really depends on your use case wether is better to use http client or some internal paths.

[galenzhao]

Hi everyone,
how can I change the backend host of request in middleware?
I want to forward some requests based on rules to another server,
like:
request.r1 -> server1.apitools -> server1.com
to: request.r2 -> server1.apitools -> server2.com
I changed the host parameter of request object but no success.

[mikz]

@galenzhao the functionality is not merged, but it is available in #19.