Проектирование API *

Госзатраты (clearspending.ru) — это новый общественный и некоммерческий проект которым мы занимались последние полгода в виде базы всех государственных и муниципальных контрактов.

Мы взяли всю базу контрактов с zakupki.gov.ru и, после некоторого количества усилий, превратили в веб-сайт с удобным поиском, навигацией, некоторым количеством аналитики и, что особенно важно, с API.


И вот тут остановимся подробнее. API — это чуть ли не самая главная отличительная черта сайта от большинства подобных ему.

Система Адаптивных платежей API позволяет вам отправлять деньги различными способами: от простых до сложных. Например, вы можете создать небольшое приложение для отправки денег в соцсетях или стабильную платежную систему.

Система Адаптивных платежей обрабатывает платежи между их отправителем и одним или несколькими получателями. Вы – владелец приложения (торговец, владеющий вебсайтом, владелец виджета в соцсети, поставщик платежных приложений на мобильных телефонах и т.д.). Ваше приложение – это абонент системы Адаптивных платежей.

В первой части я рассказал, как создать RESTful API в облаке Windows Azure и как начать его использовать в своем мобильном приложении. Рекомендую ознакомиться с той статьей, поскольку данный текст и примеры во многом опираются на нее.

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

Windows Azure и Git

Как вы неверно уже слышали, компания Microsoft, к ее чести, в последнее время все чаще обращает свое внимание на Open Source технологии. Так, например, в последней версии Visual Studio 2013 была «из коробки» внедрена поддержка системы контроля версий Git. Облако Windows Azure тоже не осталось в стороне, и теперь позволяет работать с кодом не только через TFS, но и с помощью Git и прочих систем (SVN, Dropbox, Bitbucket).

В Windows Azure Mobile Services решили пойти дальше и оставить для работы только Git. Возможно это так только на время Preview-версии данного решения, но, учитывая тенденции корпорации, такой вариант может перекочевать в релиз.

Что же нам дает использование Git в своем проекте? Да все абсолютно то же, что и всегда. А именно — совместная работа над кодом, локальные репозитории у каждого участника команды, поддержка версионности. Но что еще важно, так это соблюдения принципа continuous integration — непрерывное развертывание решения при каждом новом чекине кода в репозиторий. Каждый раз, когда кто-то из участников команды отправляет свои изменения на сервер, происходит их деплой в облаке. Все это работает на Kudu (кстати, еще один open source проект), и довольно успешно.

Безопасность переписки уже стала широко обсуждаемой темой. Как вы знаете, в этой сфере широко известен написанный петербуржцами Telegram. Команда уверяет в 146% безопасности, но если вы уже пользовались этим мессенджером, знайте, как минимум названия ваших чатов уже скомпроментированы. На момент публикации уязвимость уже закрыта (что приятно, закрыли меньше чем за пятнадцать минут после репорта).

Доброго времени суток всем хабражителям. Меня зовут Илья Шакитько и я работаю в LeaseWeb, в команде, работающей над облачными сервисами. Решая очередную задачу, связанную с исследованием той или области, мы стараемся поделиться полученными знаниями или мыслями с сообществом. Не так давно мы проводили DevOps встречу в нашем офисе, где одним из выступающих был мой коллега, Мауритс ван дер Скхи, который рассказывал об API First архитектуре. Немногим ранее в нашем блоге он опубликовал статью, переводом которой я хотел бы поделиться с вами.

Введение

API First архитектура это архитектура, для которой API пользователь является основным пользователем приложения. Это означает, что этот API должен иметь наивысший приоритет, а не быть еще одним представлением (view) в парадигме MVC. Основное различие состоит в том, что API First требует наличия полного, адаптивного и хорошо документированного API. Это особенно важно в таргетировании: на мобильных платформах (приложения используют API), у реселлеров (слой представления использует API) и в многопродуктных средах с высокой интеграцией, но малой связанностью.

В прошлой статье мы немного познакомились с возможностями Audio API и написали простенький визуализатор сигнала. Теперь настало время копнуть поглубже и распробовать новые фишки API. Но нам нужна цель, к которой мы будем стремиться, и в данном случае нашей целью будет как следует поиздеваться над входящим сигналом и его характеристиками. Другими словами, мы напишем маленький вокодер.

Так как итоговый код получился довольно-таки большим, то в статье будет рассмотрены наиболее важные и интересные с точки зрения Audio API фрагменты. Итоговый результат вы конечно же сможете посмотреть на демке.

Web Audio API для меня является одной из тех новинок, которыми сейчас напичканы браузеры и с которой хотелось подружиться поближе и хоть как-то проникнуться тем, что же можно с помощью этого натворить. Что бы проникнуться, я решил написать простенький визуализатор аудио.

Но прежде чем начать разбираться непосредственно с Audio API, нам необходимо набросать заготовку нашего визуализатора и делать мы будем это при помощи canvas.

Если вам когда-нибудь приходилось разрабатывать форму регистрации или оформления заказа, то вы знаете, что для получения из формы качественных данных нужно прикрутить множество проверок для ФИО, почтовых адресов, e-mail, телефонов. При этом так уж исторически сложилось, что разработчики пишут код валидации информации каждый раз заново. Ну а потом эти проверки приходится еще и поддерживать, а на поддержку, как известно, приходится 80% усилий.

Кроме того, чем сложнее форма для ввода, и чем больше в ней валидируется информации, тем больше вероятность, что она будет глючить, и как результат — будет неудобна для пользователя.

Так не должно быть.

Поскольку статья вводная и обзорная, то рассматриваться будет простейшая разновидность смарт-карт — SIM-карты, полагаю, что таких карт на планете сейчас больше всего.
По сегодняшним меркам стандарт SIM выглядит архаично, но зато он идеален для первого знакомства с миром смарт-карт, усвоение принципов, которые заложены в основу этого стандарта, облегчит дальнейшее погружение в тему.
Если Вы «карточник», то вряд ли узнаете для себя что-то новое, разве что какие-нибудь не очень понятные моменты разложатся по полочкам, а может быть Вы разложете по полочкам то, что недопонял автор (но, напоминаю, держимся в рамках SIM!).

В декабре 2013 года мы выступили на конференции Mobile Developer&Business Day с докладом «Особенности разработки мобильных приложений для СМИ». В презентации мы обобщили опыт EastBanc Technologies в разработке мобильных приложений для российских и американских СМИ, попытались коснуться всех важных вещей, которые когда-то стали для нас открытием. Мы хотим донести до читателей, как важно понимать, для чего вы делаете приложение: как поддержку бренда или расширение канала сбыта, т.к. по-нашему мнению для разработчика очень важно осознавать, за какую задачу он взялся и адекватно оценить ресурсо- и времязатраты.

В данной статье мы «беллетризировали» доклад. Надеемся, что-то полезное для себя найдут как начинающие разработчики, так и бывалые.

На днях ВКонтакте в разделе для разработчиков выложили SDK для Android.

Популярная социальная сеть ВКонтакте пополнила свой набор инструментариев для разработки приложений, в котором уже имеются Flash и Javascript SDK, а также SDK для iOS, еще одним — SDK для Android.

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

Не забыли ребята и о владельцах девайсов с неактуальными версиями Android на борту — тестовое приложение, поставляемое вместе с SDK, имеет требования Android 2.2+

Также не оставлен без внимания вопрос защиты.
Подробности под катом.

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

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

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

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

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

«Только со смертью догмы начинается наука.»
// Галилео Галилей

«Я начал завидовать рабам. Они всё знают заранее. У них твёрдые убеждения.»
// х/ф Марка Захарова «Убить дракона» по мотивам пьесы Евгения Шварца

Уже пару лет и дня не проходит, чтобы я не услышал (или не прочитал) от людей, начинающих новые проекты, фразу типа «Возьмем серверный движок для REST API и MVC, и погнали». Сначала я думал, что у этих слов есть один источник, может книжку какую завезли во все магазины или где-то в топе поисковиков лежит статья, зомбирующая разработчиков. Если же выяснять у них, что они понимают под REST и MVC, то можно повредиться умом. Ну с MVC уже все ясно, об этом я уже давно писал, ничего не изменилось, только усугубилось, стоит набрать в Google Images «mvc» и мы увидим страшное, стрелочки в любые стороны. Ну а про REST отвечают следующее: ну как же, нам нужно из браузерного GUI и мобильного приложения вызывать серверные методы, например: setUserCity(userId, cityId) или calculateMatrix(data) или startVideoConverter(options, source, destination) а потом мы столкнемся с большой нагрузкой и архитектура REST все решит. Дальше я задаю вопросы, от которых глаза округляются уже у тех, кто недавно еще горел праведной верой, рвался в бой и точно знал, что к чему в этом мире. Теперь можно перейти к рассмотрению терминологической катастрофы, в эпицентре которой мы с вами пребываем.

В продолжение моего предыдущего поста о таком интересном инструменте как Yiinitializr, я решил ответить на вопрос о возможностях работы API, предоставляемых шаблоном Advanced. В рамках комментария или дополнительного пункта к прошлой статье материал уместить не удалось, поэтому всех, кого интересует данная тема, приглашаю под кат. В ней мы не будем касаться принципов проектирования правильной архитектуры API, а разберёмся как воспользоваться трудами ребят из 2amigos, которые дали нам возможность быстро (после прочтения статьи — точно быстро) развернуть API для наших проектов на Yii.

Способ реализации работы с API в Yiinitializr

API — программный интерфейс приложения, служащий для использования во внешних программных продуктах. Если мы хотим, чтобы возможностями нашего приложения могли воспользоваться другие разработчики в своих проектах, то без хорошо спроектированного API нам не обойтись. К сожалению, Yii первой версии не сможет помочь в этом деле. Вероятно, вам подойдет Yiinitializr, который решит часть вопросов, но, как мы знаем, отсутствие документации является серьезным препятствием.

Представим, что работа над нашим замечательным приложением закончена, работа API налажена, и уже появился первый разработчик, желающий воспользоваться возможностями нашей системы. По какому принципу будет строиться её использование?

Я работаю в Яндексе, у Яндекса есть карты, а у карт есть API. API – вещь, которая позволяет встроить карты Яндекса на свой сайт. С версии 2.0 наш API умеет кластеризовать метки на клиенте. Вот как выглядят метки до и после кластеризации:



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

В этой статье я хочу не просто перечислить новшества в работе с кластеризатором в версии 2.1.4, но и объяснить, зачем нам понадобилось эти новшества плодить. А то вам придется переписывать код, а переписывать код грустно, если не понимаешь, зачем это приходится делать.

В предыдущих статьях о таблицах в MultiCAD.NET речь шла о программном создании и форматировании таблиц в чертеже, использовании различных типов данных в качестве содержимого, а также о применении шаблонов таблиц. В этой статье мы продолжим рассказ об использовании шаблонов и более подробно рассмотрим API, позволяющий сохранить таблицу во внешний файл в качестве шаблона и загрузить его в чертеж для формирования типовых таблиц. Во второй половине статьи будет рассмотрен процесс обмена данными с Microsoft Excel.

^{Исполнительный директор Oracle Ларри Эллисон}

Полтора года назад компания Google одержала убедительную победу над Oracle в судебном процессе по использованию кода Java в операционной системе Android. Однако, в среду 4 декабря представителей компании Google вызвали в Апелляционный суд США для дачи показаний по поводу апелляции компании Oracle. Это значит, что процесс может возобновиться, а прежнее решение могут отменить.

Приветствую сообщество!
Недавно мы решили показывать рекламу не только по эфирному ТВ но и на нашем сайте. У нас есть несколько авторских передач, которые пользуются популярностью и собирают достаточно просмотров на сайте. До этого мы выкладывали их просто так — но сейчас решили использовать как ещё одну рекламную площадку. А точнее как три площадки=) Итак, хочется реализовать следующее:

Чтобы понять как устроена открытость публичной политики в США интересно обратиться к самым свежим примерам.

Буквально несколько дней назад компания Google анонсирована появление Google Civic Information API (API Google с гражданской информацией) в котором теперь публикуют информацию о выборах, об избранных представителях и избирательных участках.



Все сводится к нескольким вызовам:

electionQuery

Возвращает список выборов

Пример вызова:

https://www.googleapis.com/civicinfo/us_v1/elections?key=<YOUR_API_KEY>

Пример результатов выборки:

{
 "kind": "civicinfo#electionsqueryresponse",
 "elections": [
  {
   "id": "2000",
   "name": "VIP Test Election",
   "electionDay": "2013-06-06"
  },
  {
   "id": "2124",
   "name": "Rhode Island 2012 Primary Election",
   "electionDay": "2012-09-11"
  },
  {
   "id": "2126",
   "name": "Delaware 2012 Primary Election",
   "electionDay": "2012-09-11"
  }
 ]
}

Как вы уже поняли из предыдущих постов, Meople.Net — это агрегатор ваших персональных (и не только) новостей из социальных сетей, реализованный для WEB и Windows 8. Многие из вас могут законно сказать, что сервис далеко не революционный. Но в этой статье я бы хотел остановиться на том, что его делает уникальным с технической (функциональной) точки зрения, а не с пользовательской.

Итак, как происходит работа с социальными сетями: большинство социальных сетей предоставляют REST API функционал для сторонних разработчиков, которые хотят построить свои приложения на платформах/данных социальных сетей. То есть, если вы хотите использовать данные Facebook или ВКонтакте в своем приложении, то это то, что вам нужно.
Я опущу общие шаги, которые должен сделать любой разработчик:
● регистрация приложения на сайте соц. сети и получение секретных ключей приложения;
● реализация (в большинстве случаев) OАuth 2.0 авторизации (http://tools.ietf.org/html/rfc6749);
● собственно отправление подписанного запроса в соц. сеть для получения необходимых вам данных.

Авторизация

Авторизация делится на клиентскую и серверную. 99% приложений, которые построены на платформе социальной сети, делают серверную авторизацию, что дает им возможность проксировать все запросы и сохранять ваши авторизационные данные на своих серверах. Они, собственно, это и делают. Так как в противном случае вам пришлось бы постоянно вводить пароль от вашего аккаунта в соц. сети (либо постоянно подтверждать разрешение на пользование вашего аккаунта для стороннего приложения). Ваши авторизационные данные в таком случае хранятся на сторонних серверах, не принадлежащих соц. сети. Там с ними может произойти все что угодно — ими даже могут воспользоваться без вашего ведома: например, поставить лайк на какую-то страницу, подписать вас на какие-то новости, в целях рекламы отправить вашим друзьям сообщение, что вы начали использовать какое-то приложение и тд.
Наш сервис использует клиентскую авторизацию там, где это возможно. В результате чего ваши авторизационные данные находятся в вашем же браузере (cookies, data storage) или устройстве и не сохраняются на наших серверах. Подписка запросов, отправляющихся в сеть, также происходит на клиенте. То есть, когда вы не используете наш сервис, у нас нет даже теоритической возможности воспользоваться вашими данными.

Отправление запросов на получение данных

При серверной авторизации для получения актуальных данных подпись запроса происходит на стороннем сервере, это означает, чтобы получить какие-то данные запрос из вашего браузера идет на сторонний сервер, оттуда в дата центр соц.сети, из соц.сети обратно на сторонний сервер и возвращается к вам. Казалось бы, все хорошо, но представьте себе, что вы находитесь в России (а раз вы читаете этот пост, то вы, скорее всего, там находитесь), а сервер стороннего приложения в большинстве случаев (и у нас в том числе) в США. Это означает, что ваш запрос образно пропутешествует вот так: Россия -> США сторонний сервер -> США соц.сеть (у ВКонтакте не уверен есть ли там сервера) -> США сторонний сервер -> Россия.
В итоге мы видим кучу запросов и на каждом из них многочисленные задержки. Особенно в случае запросов Россия — США. В результате производительность приложения падает. Частично это решается кешированием на некоторое время данных на сторонних серверах (это еще одна вещь, которой всегда хочется избежать) — но при этом вы лишаетесь возможности получить актуальные на данную секунду данные, а получаете данные с задержкой.

В нашем случае работа происходит по-другому. Подписанный запрос на получение данных отправляется напрямую из вашего браузера до ближайшего дата центра соц.сети, то есть путешествие примерно такое: Россия -> Россия соц.сеть -> Россия. Таким образом — нет промежуточных сторонних серверов, что позволяет получить данные максимально быстро и быть уверенным в безопасности запроса. Как видим, наш сервис использует инфраструктуру соц. сетей по всему миру для достижения производительности.