custom domain name with base path

[jinwg]

When I specified /ping1 as basePath for my custom domain. when I am trying to invoke them (api.mydomain.com/ping1/ping) I got 404. after dump the input stream, i found the base path was passed into API request path like below.
{"resource":"/{proxy+}","path":"/ping1/ping","httpMethod":"GET","headers":

Do we have a good solution to solve the problem?

Thanks in advance

[sapessi]

Hi @jinwg

I can see this going both ways. Let me make a practical example of an application that is composed of two services: First, a catalogue service accessible from the /catalogue resource; second, an ordering service accessible from the /orders resources. The services would be implemented as two separate Lambda function, each expecting a full resource path - for the orders service this could be /orders/{orderId}.

To allow the two teams to build the APIs independently you would declare these two as completely separate APIs in API Gateway and them bring them together with a custom domain name, using the /orders and /catalogue as base paths in the custom domain name.

Because each team has declared the full path for each service in their code, you would still want to receive the full path of the request.

I can also see a scenario where the developers of the orders service would just declare the / and /{id} in their code, assuming that API Gateway is in charge of the routing before that. While this would work, I don't think it's practical when you want to start the application outside of API Gateway and Lambda.

One option here could be to expose a setting in the library to decide whether a base path mapping should be excluded from the request path object. Any thoughts?

[jinwg]

@sapessi , thanks for your reply. sometime the base path in API gateway domain mapping is not full controlled by developer. other product team may decide how to use that. and this issue only happen when i use {proxy+} mode, if i publish each method behind API endpoint, this problem will not happen. look below path filed for 2 cases, possible it is problem of APIGateway?

Custom domain with base path /contentalerts
"path": "/contentalerts1/subscriptions/user/1234",
"pathParameters": {
"proxy": "subscriptions/user/1234"
},
"requestContext": {
"path": "/contentalerts1/subscriptions/user/1234",

Direct API endpoint without custom domain
"path": "/subscriptions/user/1234",
"pathParameters": {
"proxy": "subscriptions/user/1234"
},
"requestContext": {
"path": "/dev/subscriptions/user/1234",

[jinwg]

oh, sorry.. i misunderstand you.. my bad..

[sapessi]

@jinwg No need to close the issue. If you think we should offer an option to exclude a base path from the request leave it open and we'll talk it through

[johnboy14]

@sapessi This sounds like an issue with the APIGateway, surely it shouldn't be including the custom domains base path but instead be mapping directly to the raw endpoint. A quick work around for this, is rewriting the path variable to match the resource variable e.g.

awsProxyRequest.setPath(awsProxyRequest.getResource());

It's an unfortunate hack but it worked for us.

[sapessi]

@johnboy14 I don't think it's so black and white. The base path may actually be part of the endpoint you define in the code. Per my original example, you may have the API called orders that defines the resources under /orders. However, the /orders resource is not part of the API definition but rather a base path in the custom domain name, this way you can have both /orders and /catalogue under the same domain name, even though they are completely separate APIs. To write your app in such a way that it can be executed both in Lambda + API Gateway and EC2 you would want to define the full path in your annotations /orders/{id}. In this case it would be important for API GW to pass the full path.

The Resource string would not work here. The resource is what is configured in API Gateway, such as /orders/{proxy+} - this is something most framework would not understand.

I think the most generic solution is to offer an option to define whether you want the base path excluded or not.

[jinwg]

@sapessi, thanks for reopening this again. i agree with you, it is better to offer an option to define wether or not exclude the base path, and suggest excluding the base path by default. i think a microservice usually is supposed to handle its own internal resources without dependency of external input.

Thanks again.

[sapessi]

This is now implemented and merged into master. Release 0.5 will go out later today.

You can set it by using the stripBasePath method in the LambdaContainerHandler object.

JerseyLambdaContainerHandler<AwsProxyRequest, AwsProxyResponse> handler = JerseyLambdaContainerHandler.getAwsProxyHandler(jerseyApplication);
handler.stripBasePath("/customDomainBasePath");

I've used Jersey for my example but the method is available in all implementations.