Подход управления версиями API с помощью AWS API Gateway

Аннотация

В этой статье я попытался описать шаги и артефакты, необходимые для реализации стратегии управления версиями REST API на основе Amazon API Gateway.

Вступление

Существует требование для управления версиями REST API в одном из наших проектов. Эти REST API должны быть достаточно универсальными для поддержки нескольких арендаторов и нескольких версий. Поскольку эти API будут использоваться несколькими клиентами, существует возможность, когда два разных клиента могут использовать две разные версии API одновременно.

Поскольку мы реализуем наш API с помощью сервиса Amazon API Gateway, и мы хотим реализовать рекомендуемый наилучший подход. Я пытался найти лучшую стратегию управления версиями с использованием AWS API Gateway и Lambda. Проведя день в поиске, я понимаю, что существует три грубых стратегии для версии REST API. 1) Создайте совершенно новый API с добавлением номера версии в конце (например, www.mydomain.com/ordersV1, www.mydomain.com/ordersV2 примерно так), 2) Поместите индикатор версии в путь к ресурсу (например, www .mydomain.com / api / v1 / xxx, www.mydomain.com/api/v2/xxx) — это традиционный подход. и 3) Создать совершенно новый домен для новой версии (v1.api.mysite.com, v2.api.mysite.com). Мы должны выбрать наш подход из этих трех стратегий.

Решение Подход

В AWS API Gateway есть опция с именем Stage Variables. В представлении Integration Request мы можем предоставить имя переменной рабочей области (  ${stageVariables.<stage variable name> } ) вместо фактического имени функции Lambda. Во время развертывания переменная stage может содержать другую версию Lambda (или псевдоним), так что в зависимости от активированного ресурса (/ api / v1 / getOrders), промежуточной среды (dev, prod и т. Д.) И лямбда-имени с версией, определенной в stage Переменная API-шлюз может выбрать соответствующую функцию для вызова. Мы решили использовать эту функцию в соответствии с традиционным подходом к управлению версиями, то есть к управлению версиями на основе пути к ресурсам. В следующем разделе объясняются подробности этапов реализации этого подхода вручную.

Детали решения

Я создал одну простую лямбда-функцию NodeJs с двумя версиями, а затем создал ресурсы API шлюза AWS для запуска этих версий. Все описанные здесь шаги выполняются вручную. Позже мы установим AWS CodePipeline для развертывания версии (или псевдонима) Lambda, но в соответствии с текущим планом мы не будем автоматизировать развертывание API. Это будет сделано вручную в соответствии с дорожной картой.

1. Создайте одну лямбда-функцию nodejs getOrders.

2. Сгенерируйте две версии функции с некоторыми изменениями в ответе JSON.

3. Создайте тестовое событие для проверки лямбды. Поскольку у меня есть план по созданию LAMBDA_PROXYинтеграции типов в API Gateway, я выбираю  шаблон API Gateway AWS Proxy . Запрос JSON тестового события приведен ниже.

{
  "body": "{\"test\":\"body\"}",
  "resource": "/dev/v1/orders",
  "requestContext": {
    "resourceId": "123456",
    "apiId": "1234567890",
    "resourcePath": "/dev/v1/orders",
    "httpMethod": "GET",
    "requestId": "c6af9ac6-7b61-11e6-9a41-93e8deadbeef",
    "accountId": "123456789012",
    "identity": {
      "apiKey": null,
      "userArn": null,
      "cognitoAuthenticationType": null,
      "caller": null,
      "userAgent": "Custom User Agent String",
      "user": null,
      "cognitoIdentityPoolId": null,
      "cognitoIdentityId": null,
      "cognitoAuthenticationProvider": null,
      "sourceIp": "127.0.0.1",
      "accountId": null
    },
    "stage": "dev"
  },
  "queryStringParameters": {
    "start":"2015-10-01T00:00:00Z",
    "end":"2015-10-04T00:00:00Z"
  },
  "headers": {
    "Via": "1.1 08f323deadbeefa7af34d5feb414ce27.cloudfront.net (CloudFront)",
    "Accept-Language": "en-US,en;.8",
    "CloudFront-Is-Desktop-Viewer": "true",
    "CloudFront-Is-SmartTV-Viewer": "false",
    "CloudFront-Is-Mobile-Viewer": "false",
    "X-Forwarded-For": "127.0.0.1, 127.0.0.2",
    "CloudFront-Viewer-Country": "US",
    "Accept": "text/html,application/xhtml+xml,application/xml;.9,image/webp,*/*;.8",
    "Upgrade-Insecure-Requests": "1",
    "X-Forwarded-Port": "443",
    "Host": "1234567890.execute-api.us-east-2.amazonaws.com",
    "X-Forwarded-Proto": "https",
    "X-Amz-Cf-Id": "cDehVQoZnx43VYQb9j2-nvCh-9z396Uhbp027Y2JvkCPNLmGJHqlaA==",
    "CloudFront-Is-Tablet-Viewer": "false",
    "Cache-Control": "",
    "User-Agent": "Custom User Agent String",
    "CloudFront-Forwarded-Proto": "https",
    "Accept-Encoding": "gzip, deflate, sdch"
  },
  "pathParameters": {
    "proxy": "path/to/resource"
  },
  "httpMethod": "GET",
  "stageVariables": {
    "v1fn": "getOrders:1",
    "v2fn":"getOrders:2"
  },
  "path": "/path/to/resource"
}