[SOLVED] Why is serverless including the stage name in the service's URL?

Why is serverless including the stage name in the service's URL?

I have a project that uses httpApi (API Gateway V2). However, if I understand correctly, only version 1 of the API Gateway supports gzip compression.

Is that correct?

If so, this leaves me a bit confused because how can the newer API regress in features?

Anyways, if that’s the case, how can I prevent the Serverless Framework from breaking the URL by inserting the staging name?

POST - https://a0chsgxup2.execute-api.us-east-1.amazonaws.com/v1/collars/register # httpApi, no staging name on URL
GET - https://a0chsgxup2.execute-api.us-east-1.amazonaws.com/v1/flush/config # httpApi, no staging name on URL
GET - https://a0chsgxup2.execute-api.us-east-1.amazonaws.com/v1/flush/calories # httpApi, no staging name on URL
GET - https://a0chsgxup2.execute-api.us-east-1.amazonaws.com/unstable/v1/playground # http, staging name on URL (unstable)

Solution

AWS has moved away from the v1/v2 nomenclature and now distinguish as REST vs HTTP. From their docs: "REST APIs support more features than HTTP APIs, while HTTP APIs are designed with minimal features so that they can be offered at a lower price". https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html

So, try not to look at it as v2 as the next generation of v1.

The default behavior of REST APIs (v1) is to include the stage name in the URL. A way around it is to create custom domain names. See: https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html

For HTTP apis (v2), from AWS docs: "You can create a $default stage that is served from the base of your API's URL—for example, https://{api_id}.execute-api.{region}.amazonaws.com/. You use this URL to invoke an API stage." https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-stages.html

The default behavior is different as you were seeing. So this is not from the serverless framework, but AWS itself.

HTTP apis are cheaper and REST apis have a lot more features. I think it would be pretty difficult to mix and match, so you might be best picking one - and it sounds like you will need REST given your compression need.