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

На днях ВКонтакте в разделе для разработчиков выложили 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) или устройстве и не сохраняются на наших серверах. Подписка запросов, отправляющихся в сеть, также происходит на клиенте. То есть, когда вы не используете наш сервис, у нас нет даже теоритической возможности воспользоваться вашими данными.

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

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

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

Несмотря на проблемы, трудности и всяческие злоключения, разработка нашего «больше чем ридера» продвинулась далеко вперед. Мы полностью завершили работы по созданию архитектуры проекта, доработали механизмы взаимодействия с платформой iLook и существенно продвинулись в разработке мобильных приложений. Но самое главное: мы завершили работы по созданию «сердца» нашего Медиа-центра — серверную часть ридера с открытым API. И сегодня мы приглашаем вас присоединиться к проверке работоспособности боевого API на стенде-прототипе.

В этом небольшом посте описывается работа с сервисом Semantics3, с которым я познакомился в процессе разработки некого портала для покупок в интернете.
Цель сервиса — собрать в одном месте все товары в мире и давать доступ магазинам по API к своей базе, где можно будет видеть динамику цен, кто что продает и так далее(на данный момент проиндексировано более 35 миллионов продуктов). После того, как Google Search API for Shopping “ушел на пенсию”, Semantics3 стремительно набирает обороты. Входит в семерку лучших стартапов в фонде Y Combinator за зимнюю сессию 2013 года.

Не так давно у меня возникла необходимость парсинга и последующего вывода нужной информации из iCalendar. После упорных поисков я наткнулся на библиотеку iCal4J. Присмотревшись к её функционалу, я понял — это то, что мне нужно. Давайте же попробуем её применить на практике.

Подготовка календаря

В Google Calendar я создал маленький календарь, состоящий из нескольких различных мероприятий длительностью от 30 минут до 6 часов. Затем я скачал календарь в формате iCal к себе на ноутбук. Если кто не знает — делается это так: заходим в настройки календаря Google и в разделе «Закрытый адрес календаря» жмём на зеленую кнопочку «ICAL». Всё, календарь загружен на устройство.

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

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

Ранее я писал в паре постов о том как устроена открытость электронных петиций в разных странах, какие данные есть в России и как можно сделать APO для небезызвестной Российской общественной инициативы — www.roi.ru.

Прочитать всё это можно здесь:

• API для Российской общественной инициативы. Шаг 1: сбор и анализ данных
• API для Российской общественной инициативы. Шаг 2.1: опыт Великобритании в работе с данными электронных петиций

В этот раз мы рассмотрим то как устроены электронные петиции Белого Дома, в первую очередь, с точки зрения их открытости и пригодности к данных для использования.

Справка

Особенности петиций в США

1. Относятся именно к президенту и ответы дает его администрация.
2. Не требуют ничего кроме email'а для подписи — дополнительная авторизация ненужна.
3. Петиции должны пройти 2 порога — 150 подписей за 30 дней чтобы их можно было найти (по прямой ссылке они доступны) и 100 000 подписей за 30 дней чтобы получить официальный ответ — petitions.whitehouse.gov/how-why/terms-participation

В цифрах

• всего 2246 петиций
• даны ответы на 208 петиций
• в ожидании ответа 26 петиций
• закрыто 1972 петиций
• открыто для голосования 40 петиций

Цифры учитывают только те петиции что прошли 1-й порог в 150 подписей за 30 дней.

WhiteHouse.gov/developers

Одно из важных отличий сайта Белого Дома США от сайтов всех лидеров в мире — это ориентированность на разработчиков. На сайте даже есть специальный раздел /Developers где размещены данные, раскрыт исходный код проектов и описаны API многих из инициатив если не всех вообще.

Открытый код

Поскольку нас интересуют в первую очередь петиции, то рассмотрим их подробнее.

Во первых исходный код петиций полностью опубликован на Github — https://github.com/WhiteHouse/petitions

У репозитория больше 15 контрибьюторов, несколько десятков багов и вопросов и мы можем говорить о том что разработка проекта идет открытым образом.

Открытое API

Другая сторона происходящего в том для разработчиков доступен не только исходный код, но и API и данные накопленные на сервисе.
Все API по петициям доступны по ссылке — https://petitions.whitehouse.gov/developers

API доступа к данным состоит из 3-х эндпоинтов:

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

Самое, что вероятно бросается в глаза — в новой версии нет XML. Да, мы оставили только JSON, но этим всё не ограничивается.

Вчера состоялся выпуск новой версии программы для синхронизации файлов через торренты BitTorrent Sync 1.2. Разработчики сообщили несколько приятных новостей. Во-первых, популярность BitTorrent Sync растёт высокими темпами, что гарантирует успешное развитие проекта в будущем. Количество пользователей превысило 1 млн человек (месячная активная аудитория), а объём синхронизированных файлов — 30 петабайт.

Во-вторых, в новой версии произведена оптимизация протокола синхронизации, так что максимальная скорость в локальной сети увеличена до 90 МБ/c. Это значит, что 10-гигабайтный файл автоматически синхронизируется между компьютерами в локалке быстрее, чем за две минуты.

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

Иногда, для разминки ради, ставлю себе задачи. Просто ради интереса. Чаще всего они забываются сразу после найденного решения и более не используются. Так произошло и в этот раз. Начитался в интернетах о том, что эффективным способ продвижения в Instagram, считается поиск фото по тегам и «лайканье» оных. Если правильно выбрать теги (как правило те, что соответствуют тематике вашего аккаунта), вы получите не только ответные лайки, но и новых подписчиков (что подтвердилось).

Задача

Написать робота (MySQl+php+js), который находил бы фото по тегам и ставил им лайки. Более того, желательно, чтобы наш робот не попал в бан.

Всем привет.
У нас снова появилась необходимость узнать мнение пользователей Хабры по поводу издания книги «RESTful Web APIs».

Как можно вручную протестировать API? Наоборот, если есть API, чем плохи модульные тесты? При разработке API nanoCAD-а мы столкнулись с тем, что не весь API можно протестировать при помощи модульных тестов — часть API неразрывно связана с пользовательским интерфейсом и интерактивным взаимодействием с пользователем.

В этой статье мы расскажем о том, как мы тестировали API вручную, через какие стадии автоматизации мы прошли, и какой подход позволил нам создать надёжные и легко поддерживаемые автотесты.



По мотивам доклада на конференции SQA Days-12.