How can an API call methods in itself? How does it find the right URL if you have multiple stages? Can't refer to variable restApiId

Serverless Framework
1

I’m relatively new to serverless, so I beg your indulgence with this possibly stupid question.

I see in the documentation on variables this:

To self-reference properties in serverless.yml , use the ${self:someProperty} syntax in your serverless.yml . someProperty can contain the empty string for a top-level self-reference or a dotted attribute reference to any depth of attribute, so you can go as shallow or deep in the object tree as you want.

I see in the “serverless.yml” section of the documentation, under “provider”

apiGateway: # Optional API Gateway global config
restApiId: xxxxxxxxxx # REST API resource ID. Default is generated by the framework

If I try to refer to ${self:provider.apiGateway.restApiId}, I get

Trying to populate non string value into a string for variable ${self:provider.apiGateway.restApiId}. Please make sure the value of the property is a string.

This may be a reflection of my lack of experience with AWS API Gateway, but the problem that I’m trying to solve is that I have some elements of my API that need to invoke each other, and I am trying to configure the URL into an environment variable.

I would be grateful if someone could help me understand:

  • What’s the usual idiom in serverless for parts of an API that need to invoke each other? How do they find the correct endpoint depending on their deployment stage?
  • Assuming that the API URL has to be configured in some way inside serverless.yml, how does one figure out the correct value?

Thanks!

2

For both cost and performance reasons it’s usually better to invoke the Lambda directly or use SNS for asynchronous requests rather calling other API via the API gateway.

If you still need to work out the API Gateway URL then check out How to I get my API Gateway URL with the Serverless Framework

3

Thanks! I just found it!

I will take a look at invoking the Lambda directly though. This is a very low-volume API where neither cost nor performance is a big deal, but I do want to learn good practice.

Thanks again for your response.