Amazon Web Services позволяют очень быстро производить прототипирование простых веб-приложений, и написать API, допустим, для простого мобильного приложения можно за считанные минуты. Мы будем использовать связку DynamoDB и API Gateway (без Lambda-функций!) для настройки GET и POST запросов к базе с возможностью чтения, записи и изменения данных в ней.
Прежде всего, вам необходимо зарегистрироваться на AWS и войти в консоль. Создание нашего сервиса мы начнём с базы данных DynamoDB, нажмите кнопку Create table, введите название таблицы apiData (в руководстве я буду использовать свои названия, вы же можете указывать любые другие), основной ключ по которому в неё будут добавляться записи: userID и отметьте галочку Use default settings.
В DynamoDB строки в таблицу добавляются по указанному ключу, при этом возможно добавление любого количества параметров и не обязательно совпадение структуры данных для разных ключей. В нашем случае для каждого из пользователей по указанному userID мы сможем добавлять любые данные, описывающие данного пользователя.
Далее нам необходимо создать так называемую роль в сервисе Identity and Access Management. В меню слева выберите раздел Roles и нажмите кнопку Create new role; укажите её название — dynamoAPI, и после нажатия кнопки Next Step — в разделе AWS Service Roles выберите Amazon API Gateway, ещё дважды нажмите Next Step и наконец — Create Role.
Нас интересует значение Role ARN указанное в формате arn:aws:iam::000000000000:role/roleName. Это значение необходимо будет использовать при связи запросов с базой данных, поэтому запишите его. Далее нам необходимо создать политику доступа для данной роли, это делается на вкладке Permissions в разделе Inline policies, раскройте его и нажмите click here.
В разделе Policy Generator нажмите кнопку Select, на открывшейся странице выберите сервис Amazon DynamoDB и укажите следующие Actions:
Возможно, вы захотите иметь возможность делать какие-то другие действия с помощью вашего API, в таком случае — можете изучить их на данной странице справки, для базовых операций нам указанных действий хватит за глаза. Что касается пункта Amazon Resource Name — здесь вы можете либо указать ARN вашей таблицы (находится на вкладке Overview), либо указать * что даст возможность пользователям с созданной ролью иметь доступ ко всем таблицам вашего аккаунта. Нажмите кнопку Add Statement и Next Step, на открывшейся странице — Apply Policy. На этом настройка роли завершена!
Переходим к созданию API с использованием сервиса API Gateway. Нажмите синюю кнопку Create API, на открывшейся страницу укажите его название — The API и нажмите кнопку Create API внизу страницы. Теперь нам необходимо создать ресурс, к которому можно будет обращаться с запросами, нажмите кнопку Actions и выберите Create Resource.
Назовём данный ресурс user, он будет содержать информацию о пользователях, и чтобы получить доступ к конкретному пользователю — необходимо будет указать ID пользователя в качестве параметра пути. Чтобы в сервисе API Gateway создавать такие параметры, нам необходимо создать новый ресурс на уровень ниже уже созданного user, и в качестве Resource Name и Resource Path указать {userid} (обратите внимание, что при указании названия в таком формате Resource Path автоматом заменяется на -userid-, вам необходимо вручную указать нужную форму для параметра пути).
Далее создадим метод для создания записи о новом пользователе, для этого выберем ресурс {userid}, и нажав кнопку Actions выберем Create method, укажите его тип — POST и нажмите галочку для его создания. В открывшемся меню настроек в разделе Integration type необходимо открыть спойлер Show advanced и выбрать AWS Service Proxy. Настройки:
После сохранения этих настроек необходимо сперва зайти в первый квадрат Method Request, в пункте API Key Required выбрать true и нажать на галочку чтобы сохранить настройки — это необходимо для доступа к данному методу извне с помощью токена авторизации (настроим позже; не забывайте проделывать эту операцию для всех методов!). Вернитесь назад и зайдите во второй квадрат Integration Request для настройки собственно запроса в DynamoDB. На открывшейся странице — промотайте в самый низ и откройте раздел Body Mapping Templates, нажмите кнопку Add mapping template, укажите Content type: application/json, в поле ввода необходимо указать параметры запроса, для создания новой записи используйте следующий код:
Здесь мы указываем имя таблицы, в которой производим изменения, первым указывается ключ, по которому будут вноситься данные: userID, его значение берётся из параметра пути userid. Из тела запроса берутся данные по ключу parameter и добавляются в одноимённый столбец нашей базы данных для указанного пользователя. В качестве ответа — присылается предыдущее значение по указанному ключу, если оно существовало. Если пользователя с таким именем пользователя не существовало — придёт пустой ответ.
Всё что нам остаётся — это проверить работоспособность запроса, для этого вверху страницы нажмите кнопку назад и справа от четырёх квадратов — нажмите на кнопку Test со значком Гарри Поттера:
В открывшемся окне нам нужно будет указать значение Path parameter — это имя пользователя, которого мы хотим создать / пересоздать (напомню, PutItem перезаписывает всю строку по указанному ключу), чуть ниже — указываем body запроса:
Запрос прошёл успешно, мы получили ответ с пустым телом без всяких ошибок!
Если мы перейдём в DynamoDB, то на вкладке Items сможем увидеть только что созданного пользователя:
Для чтения данных о пользователе — необходимо так же в рамках ресурса {userid} создать GET метод c Action — Query, произвести настройку интеграционного запроса (помните — в этом случае запрос к базе все равно делается POST методом!) и указать следующий темплейт для боди маппинга:
Если же мы хотим изменить какое-то значения параметра для определённого пользователя, не меняя все остальные строки, то мы также можем использовать POST метод c Action типа UpdateItem и следующим темплейтом маппинга:
В этом случае запрос возвращает все обновлённые данные о пользователе в случае успеха, из примеров — этот метод можно использовать для хранения appsecret_proof при авторизации пользователя через Facebook в вашем приложении.
По сути, все базовые сценарии использования API можно создать основываясь на данных примерах. Всё что нам остаётся — это получить доступ к API извне, для этого необходимо нажать нашу любимую кнопку Actions в меню нашего API и выбрать Deploy API. Указываете:
Нажимаете Deploy и получаете Invoke URL следующего вида: m00000000a.execute-api.us-east-1.amazonaws.com/apiRelease. Чтобы делать запросы по этому адресу — необходим токен авторизации, для его получения — в меню слева зайдите в раздел API Keys, нажмите кнопку Create, назовите как-то свой ключ и сохраните его. Далее в появившемся разделе API Stage Association выберите нужный API и недавно созданную сцену, после нажмите кнопку Add. Вернитесь через левое меню в наш API, выберите Actions -> Deploy API, выберите уже созданную Stage и нажмите Deploy. Вуаля!
Теперь вы можете делать запросы к вашему API извне, добавив к запросам header x-api-key с вашим токеном в качестве значения. Чтобы получить данные о нашем созданном пользователе достаточно сделать соответствующий GET запрос на адрес m00000000a.execute-api.us-east-1.amazonaws.com/apiRelease/user/newUserOne и вы получите всю имеющуюся о нём информацию в ответе! Таким образом, за считанные минуты можно создать простой API для доступа к базе данных, с помощью которого можно тестить ваше новое приложение или любой другой сервис, не требующий сложной структуры данных. Для более сложных проектов, конечно, стоит использовать более подходящие инструменты.
Прежде всего, вам необходимо зарегистрироваться на AWS и войти в консоль. Создание нашего сервиса мы начнём с базы данных DynamoDB, нажмите кнопку Create table, введите название таблицы apiData (в руководстве я буду использовать свои названия, вы же можете указывать любые другие), основной ключ по которому в неё будут добавляться записи: userID и отметьте галочку Use default settings.
В DynamoDB строки в таблицу добавляются по указанному ключу, при этом возможно добавление любого количества параметров и не обязательно совпадение структуры данных для разных ключей. В нашем случае для каждого из пользователей по указанному userID мы сможем добавлять любые данные, описывающие данного пользователя.
Далее нам необходимо создать так называемую роль в сервисе Identity and Access Management. В меню слева выберите раздел Roles и нажмите кнопку Create new role; укажите её название — dynamoAPI, и после нажатия кнопки Next Step — в разделе AWS Service Roles выберите Amazon API Gateway, ещё дважды нажмите Next Step и наконец — Create Role.
Нас интересует значение Role ARN указанное в формате arn:aws:iam::000000000000:role/roleName. Это значение необходимо будет использовать при связи запросов с базой данных, поэтому запишите его. Далее нам необходимо создать политику доступа для данной роли, это делается на вкладке Permissions в разделе Inline policies, раскройте его и нажмите click here.
В разделе Policy Generator нажмите кнопку Select, на открывшейся странице выберите сервис Amazon DynamoDB и укажите следующие Actions:
- DeleteItem
- GetItem
- PutItem
- Query
- Scan
- UpdateItem
Возможно, вы захотите иметь возможность делать какие-то другие действия с помощью вашего API, в таком случае — можете изучить их на данной странице справки, для базовых операций нам указанных действий хватит за глаза. Что касается пункта Amazon Resource Name — здесь вы можете либо указать ARN вашей таблицы (находится на вкладке Overview), либо указать * что даст возможность пользователям с созданной ролью иметь доступ ко всем таблицам вашего аккаунта. Нажмите кнопку Add Statement и Next Step, на открывшейся странице — Apply Policy. На этом настройка роли завершена!
Переходим к созданию API с использованием сервиса API Gateway. Нажмите синюю кнопку Create API, на открывшейся страницу укажите его название — The API и нажмите кнопку Create API внизу страницы. Теперь нам необходимо создать ресурс, к которому можно будет обращаться с запросами, нажмите кнопку Actions и выберите Create Resource.
Назовём данный ресурс user, он будет содержать информацию о пользователях, и чтобы получить доступ к конкретному пользователю — необходимо будет указать ID пользователя в качестве параметра пути. Чтобы в сервисе API Gateway создавать такие параметры, нам необходимо создать новый ресурс на уровень ниже уже созданного user, и в качестве Resource Name и Resource Path указать {userid} (обратите внимание, что при указании названия в таком формате Resource Path автоматом заменяется на -userid-, вам необходимо вручную указать нужную форму для параметра пути).
Далее создадим метод для создания записи о новом пользователе, для этого выберем ресурс {userid}, и нажав кнопку Actions выберем Create method, укажите его тип — POST и нажмите галочку для его создания. В открывшемся меню настроек в разделе Integration type необходимо открыть спойлер Show advanced и выбрать AWS Service Proxy. Настройки:
- AWS Region укажите регион, в котором находится ваша база данных (по умолчанию — us-east-1, проверить его можно в разделе Overview вашей таблицы)
- AWS Service: DynamoDB
- AWS Subdomain: оставить пустым
- HTTP method: POST (используется для любых обращений к DynamoDB, в том числе и для получения данных)
- Action Type: Use action name
- Action: PutItem (используется для создания новой записи/перезаписи всего значения по указанному ключу)
- Execution role: указать роль, которую мы создали, в формате arn:aws:iam::000000000000:role/roleName
После сохранения этих настроек необходимо сперва зайти в первый квадрат Method Request, в пункте API Key Required выбрать true и нажать на галочку чтобы сохранить настройки — это необходимо для доступа к данному методу извне с помощью токена авторизации (настроим позже; не забывайте проделывать эту операцию для всех методов!). Вернитесь назад и зайдите во второй квадрат Integration Request для настройки собственно запроса в DynamoDB. На открывшейся странице — промотайте в самый низ и откройте раздел Body Mapping Templates, нажмите кнопку Add mapping template, укажите Content type: application/json, в поле ввода необходимо указать параметры запроса, для создания новой записи используйте следующий код:
{
"TableName": "apiData",
"Item": {
"userID": {
"S": "$input.params('userid')"
},
"parameter": {
"S": "$input.path('$.parameter')"
}
},
"ReturnValues": "ALL_OLD"
}
Здесь мы указываем имя таблицы, в которой производим изменения, первым указывается ключ, по которому будут вноситься данные: userID, его значение берётся из параметра пути userid. Из тела запроса берутся данные по ключу parameter и добавляются в одноимённый столбец нашей базы данных для указанного пользователя. В качестве ответа — присылается предыдущее значение по указанному ключу, если оно существовало. Если пользователя с таким именем пользователя не существовало — придёт пустой ответ.
Всё что нам остаётся — это проверить работоспособность запроса, для этого вверху страницы нажмите кнопку назад и справа от четырёх квадратов — нажмите на кнопку Test со значком Гарри Поттера:
В открывшемся окне нам нужно будет указать значение Path parameter — это имя пользователя, которого мы хотим создать / пересоздать (напомню, PutItem перезаписывает всю строку по указанному ключу), чуть ниже — указываем body запроса:
{
"parameter": "112233"
}
Запрос прошёл успешно, мы получили ответ с пустым телом без всяких ошибок!
Если мы перейдём в DynamoDB, то на вкладке Items сможем увидеть только что созданного пользователя:
Для чтения данных о пользователе — необходимо так же в рамках ресурса {userid} создать GET метод c Action — Query, произвести настройку интеграционного запроса (помните — в этом случае запрос к базе все равно делается POST методом!) и указать следующий темплейт для боди маппинга:
{
"TableName": "apiData",
"KeyConditionExpression": "userID = :v1",
"ExpressionAttributeValues": {
":v1": {
"S": "$input.params('userid')"
}
}
}
Если же мы хотим изменить какое-то значения параметра для определённого пользователя, не меняя все остальные строки, то мы также можем использовать POST метод c Action типа UpdateItem и следующим темплейтом маппинга:
{
"TableName": "apiData",
"Key": {
"userID": {
"S": "$input.params('userid')"
}
},
"UpdateExpression": "set token_proof = :tkn",
"ExpressionAttributeValues": {
":tkn": {
"S": "$input.path('$.token')"
}
},
"ReturnValues": "UPDATED_NEW"
}
В этом случае запрос возвращает все обновлённые данные о пользователе в случае успеха, из примеров — этот метод можно использовать для хранения appsecret_proof при авторизации пользователя через Facebook в вашем приложении.
По сути, все базовые сценарии использования API можно создать основываясь на данных примерах. Всё что нам остаётся — это получить доступ к API извне, для этого необходимо нажать нашу любимую кнопку Actions в меню нашего API и выбрать Deploy API. Указываете:
- Deployment stage: [New Stage]
- Stage name: apiRelease (или любое другое)
Нажимаете Deploy и получаете Invoke URL следующего вида: m00000000a.execute-api.us-east-1.amazonaws.com/apiRelease. Чтобы делать запросы по этому адресу — необходим токен авторизации, для его получения — в меню слева зайдите в раздел API Keys, нажмите кнопку Create, назовите как-то свой ключ и сохраните его. Далее в появившемся разделе API Stage Association выберите нужный API и недавно созданную сцену, после нажмите кнопку Add. Вернитесь через левое меню в наш API, выберите Actions -> Deploy API, выберите уже созданную Stage и нажмите Deploy. Вуаля!
Теперь вы можете делать запросы к вашему API извне, добавив к запросам header x-api-key с вашим токеном в качестве значения. Чтобы получить данные о нашем созданном пользователе достаточно сделать соответствующий GET запрос на адрес m00000000a.execute-api.us-east-1.amazonaws.com/apiRelease/user/newUserOne и вы получите всю имеющуюся о нём информацию в ответе! Таким образом, за считанные минуты можно создать простой API для доступа к базе данных, с помощью которого можно тестить ваше новое приложение или любой другой сервис, не требующий сложной структуры данных. Для более сложных проектов, конечно, стоит использовать более подходящие инструменты.
Поделиться с друзьями
rma4ok
Можно еще использовать AWS-SDK и обращаться к DynamoDB прямо из браузера/девайса. Тогда никакая HTTP прослойка не нужна. Контроль доступа осуществляется через AWS cognito.
drinkius
Да, думаю об этом написать в следующей статье!