API Gateway v2 API моделирует маршруты очень обобщенно c, так что одни и те же модели данных можно использовать как для API HTTP, так и для API WebSocket. В обоих случаях это аргумент route_key
, который используется для сопоставления маршрутов.
Для API WebSocket мы можем выбрать, как API-шлюз будет создавать ключ маршрута, задав route_selection_expression
при объявлении API.
Для API-интерфейсов HTTP API Gateway v2 использует одну строку, состоящую из метода, за которым следует путь, разделенный пробелом. Например, следующий ключ маршрута будет соответствовать тому, что вы ввели в консоль для своего скриншота:
route_key = "ANY /"
Документация API Gateway для маршрутов предлагает второй пример, который мы можем перевести на Terraform, как это:
route_key = "GET /pets"
Похоже, консоль API Gateway автоматически объединяет эти два поля в пользовательском интерфейсе в одну строку при создании маршрута.
Общие положения Совет, когда вы пытаетесь понять, как консольный пользовательский интерфейс AWS отображается на базовый API - и, следовательно, как он отображается в Terraform - состоит в создании тестового объекта в консоли и его импорте в Terraform, чтобы увидеть, как Terraform видит это.
В этом случае вам нужно создать маршрут с пользовательским интерфейсом, как вы показали, а затем использовать консоль, чтобы найти внутренний идентификатор всего API и этого маршрута в API. API шлюза, например, перейдя к нему в консоли и просмотрев строку URL браузера. Затем вы можете написать для Terraform пустую конфигурацию местозаполнителя и импортировать в нее свой объект:
resource "aws_apigatewayv2_route" "example" {
# TODO: Fill in after import
}
terraform import aws_apigatewayv2_route.example api-id/route-id
Если импорт завершится успешно, вы можете посмотреть на понимание Terarform объекта, который вы импортировали, запустив terraform show
и ищет блок resource "aws_apigatewayv2_route" "example"
в выходных данных. Затем вы можете увидеть route_key
, который консоль создала, и скопировать его в вашей конфигурации.
Важно соблюдать осторожность при использовании terraform import
таким образом, потому что после этого Terraform считает, что он является единственным менеджером этот объект и планирует уничтожить его, если вы запустите terraform destroy
или удалите его из конфигурации. По этой причине я бы предложил сделать это с временным HTTP API, созданным только для экспериментов, а не с любым реально существующим HTTP API, который вы хотите сохранить. (Конечно, вы можете использовать terraform import
для переноса вашего существующего API в Terraform, если вы уже достаточно экспериментировали, чтобы знать, как представлять существующие объекты, если вы намерены использовать Terraform для управления API на постоянной основе.)