Облачный API для мобильных приложений своими руками. Часть 1

Вместо вcтупления

На заре программирования и до совсем недавнего времени программа была чем-то законченным, полностью готовой к употреблению самостоятельной единицей, которая выполняла свои функции и только их.

Однако с появлением мобильных устройств, веб сайтов с богатой логикой и социальных сетей все стало меняться. Сейчас программы, которые не выходят в сеть, не умеют что-то выкладывать в фейсбуки и вообще работают сами в себе, практически не имеют права на жизнь. Даже професcиональные инструменты, такие как, Microsoft Office 2013 ^[1], стали поддерживать облачные хранилища для обмена документами.

Мир меняется. Теперь, чтобы заработать денег на продаже софта, необязательно писать свою собственную операционную систему ^[2] или антивирус, потратив кучу времени и ресурсов. Достаточно просто попросить свою жену и вдвоем разработать мировой хит ^[3]. Поэтому многие сегодня мечтают создать своих злых птичек или кат-зе-роуп, изучая разработку под iOS ^[4], Android ^[5], Windows Phone ^[6].

Допустим, вы написали свое приложение и опубликовали его в каком-то из магазинов. Все отлично, вы получаете прибыль, но хочется больше. Вы понимаете, что надо писать приложения еще и для других платформ, чтобы расширить пользовательскую базу. Здесь-то и кроется первая засада — как минимизировать количество кода, который вы пишете, если приложения будут работать по большей степени одинаково и отличаться будут только внешним видом (и то не факт) и языком программирования?

Ответом на этот вопрос станет старичок ООП, облачившийся в модные шмотки и сменивший имя. Если вынести общую логику из кода приложения в некий общий сервис и расположить этот сервис в интернете, чтобы все приложения могли к нему подключаться, тогда для реализации мобильного приложения на конкретной платформе вам останется лишь написать код отображения данных с сервера. Звучит знакомо, не так ли? Это очень похоже на паттерн MVC ^[7]. Здесь Model — это сервис в интернете, который получает и отдает данные, а View и Controller реализуются на мобильном устройстве и могут быть максимально упрощены. В качестве модели устройства подобного сервиса сегодня все чаще стали использовать так называемый RESTful ^[8] API ^[9] — программный интерфейс, к которому можно обращаться через стандартные HTTP методы.

И все вроде бы выглядит хорошо и уже кажется, что решение найдено. Однако проблемы начинаются, когда вы станете самостоятельно развертывать сервис бекенда на сервере. Я — программист, и когда дело доходит до установки и настройки сервера, мне сразу становится не по себе. Во-первых, это абсолютно новые знания, которые надо изучить, чтобы все работало как надо. Во-вторых, чтобы все работало действительно как надо и не упало при возросшей нагрузке или атаке, надо курить маны еще больше и упорнее. Можно попробовать найти такого хостера, который избавит вас от возни с серверами и предустановит PHP и/или что-то еще. Но тогда останется проблема того, что нужно будет самостоятельно реализовывать все необходимые обработчики событий сервера для реализации полноценного REST API. А это опять же отнимает ваше полезное время и тратит его на ненужные вещи.

К чему я это все?

Я сам долго время мучился вопросом, а как же мне организовать свой серверный бекенд для приложения. Сначала писал что-то свое, используя WCF сервисы. Потом появился ASP.NET Web API ^[10], который довольно неплохо упростил жизнь. Но сегодня я хочу поведать о другом. Я как любитель простых в использовании вещей не мог пройти мимо относительного нового сервиса, который появился в облачной платформе Windows Azure ^[11]. Имя этого сервиса — Windows Azure Mobile Services Custom API.

Данный сервис, наряду с другими полезными возможностями Windows Azure Mobile Services, является PaaS решением и предоставляет возможность быстро развернуть облачный RESTful API, к которому может получить доступ программа на любом языке и платформе. В основу этого решения легла уже не новая, но довольно популярная технология Node.js ^[12]. Custom API является полностью функциональным Node.js приложением со всеми вытекающими последствиями — это полноценное решение без компромиссов. А с учетом того факта, что для работы с ним написаны нативные SDK для всех трех популярных мобильных платформ, это решение становится еще интереснее.

Далее в этой части я хочу рассказать о том, как создать и начать пользоваться облачным бекендом в Windows Azure и обращаться к нему с мобильного устройства. Не переключайтесь!

Создание облачного бекенда

Создание облачного бекенда, как и любого другого сервиса в Windows Azure, происходит из портала управления ^[13] облаком. Сперва надо создать мобильную службы, придумав ей какое-то вменяемое название:

Далее вам необходимо выбрать SQL базу данных, в которой будут храниться данные мобильной службы. Есть вариант создать бесплатный экземпляр на 20Мб. Для тестирования возможностей — хватит за глаза. А если понравится, то всегда можно проапгрейдиться на более серьезные решения.

После нажатия на стрелку далее и ввода параметров сервера БД (создать новый или использовать существующий логин/пароль администратора и прочая скукота), новый мобильный сервис начнет создаваться в облаке. Обычно это происходит крайне быстро, меньше чем за минуту. Когда служба создастся и вы зайдете в нее, то увидите что-то вроде этого окна:

Запомните его, оно нам еще пригодится далее.

Создание API

Чтобы создать свой первый облачный API, просто перейдите на вкладку API и нажмите кнопку Create a Custom API:

Если вы ранее работали с мобильными службами Windows Azure, то следующее окно будет вам знакомо. В нем необходимо задать название будущего API, а также один из четырех уровней доступа к различным его методам. Оставим все по умолчанию, тогда к нашему API смогут подключаться только те клиенты, у которых есть параметр авторизации:

Как только новый API создался, мы можем приступить к его редактированию. Изначально вы должны увидеть скрипт, похожий на этот:

В образовательных/тестовых целях я предлагаю слегка его изменить, чтобы получилось вот так:

Основным изменением в данном случае стало то, что в обработчике POST-запросов стали возвращаться данные в виде простой строки, а в GET добавилась переменная, и у ее объекта есть более одного поля. Я сделал так для наглядности, чтобы проиллюстрировать различные возможности работы с данными.

Использование API

Для данной статьи мы воспользуемся тестовым приложением, которое нам любезно предоставляет Windows Azure Mobile Services. Для этого вернемся на страницу Quick Create (это та самая, с облачком и молнией на пиктограмме), выберем Windows Phone 8 (хотя обратите внимание на богатый выбор) и нажмем Create A New Windows Phone App:

Создав нужную табличку (TodoItem) и скачав приложение по кнопке Download, откроем его в Visual Studio.

В первую очередь нас интересует две вещи. В файле App.xaml.cs есть строка примерно такого вида:

public static MobileServiceClient MobileService = new MobileServiceClient(
        "https://mva-test-api.azure-mobile.net/",
        "тут_набор_непонятных_символов"
        );

С помощью этого поля мы будем общаться с нашей новоиспеченной мобильной службой. Набор непонятных символов — это ApplicationKey, индивидуальный ключ вашей службы, хольте его и лелейте.

Давайте запустим приложение и посмотрим хотя бы, как оно выглядит:

Ну не хит апстора, но для начала неплохо. Давайте наделим его дополнительной логикой и вызовем наши API методы. Идем в файл MainPage.xaml.cs. От него я хочу добиться того, чтобы при нажатии на кнопку Save происходило обращение к сервисам, после чего полученный результат просто писался в консоль отладки. Для этого в конец метода InsertTodoItem добавьте следующий код:

// Обращение к POST
var result = await App.MobileService.InvokeApiAsync("CoolAPI", null, HttpMethod.Post, null, null);
Debug.WriteLine(result.StatusCode);
var stringData = await result.Content.ReadAsStringAsync();
Debug.WriteLine(stringData);

// Обращение к GET
var resultJson = await App.MobileService.InvokeApiAsync("CoolAPI", HttpMethod.Get, null);
Debug.WriteLine(resultJson);

Главным методом в этом коде можно назвать InvokeApiAsync. Он отвечает за вызов того или иного метода API. Этот метод перегружен и наделен различным набором параметров. В примере видно, что в случае с POST мы передаем аж 5 параметров, а в случае с GET всего 3. Это связано с тем, что метод для POST рассчитан на то, что результатом работы будет обычная строка (вспоминаем реализацию скрипта на бекенде), а вариант с GET — на работу с JSON объектом (результатом будет Newtonsoft.Json ^[14]).

Если теперь запустить приложение и понажимать кнопку Save, то в Debug-консоли приложения будет видно что-то вроде этого:

Как у них

Я не просто так попросил обратить внимание на возможность выбора типа приложения на страничке Quick Create в панели управления Windows Azure. Дело в том, что нативный SDK для работы с мобильными службами написан не только для Windows устройств. Свои библиотеки выпущены и для iOS, и для Android, поэтому все то же самое можно использовать и на этих платформах. Вот пример кода на ObjectiveC, который будет делать примерно то же, что и в примере:

[self.client invokeAPI:@"CoolAPI" data:nil HTTPMethod:"POST" 
    parameters:nil headers:nil completion:^(NSData *result,
    NSHTTPURLResponse *response, NSError *error) {

        NSLog(@"%i", response.statusCode);
        NSString *stringData = [[NSSatring alloc] initWithData:result encoding:NSUTF8StringEncoding];
}];

Как видите — «чистый» ObjectiveC, без мухляжа. Аналогично для Android, WinRT и даже для веб-версии (на HTML и JavaScript).

Что дальше

Я изначально планировал написать только одну статью сразу про все возможности серверного кода в Windows Azure Mobile Services, но материала получается слишком много. Поэтому сейчас мы закончим, а в следующей части я расскажу о том, как можно работать над облачным бекендом в команде, используя при этом Git. А еще о том, как расширить функциональность общими скриптами и NPM-пакетами.

Автор: glamcoder

Источник ^[15]