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

Сегодня при содействии Хабра мы запускаем WGDC — первый официальный конкурс Wargaming для сообщества разработчиков. Цель конкурса — актуализировать наш формат взаимодействия с разработчиками приложений и модов игрового клиента, поискать точки соприкосновения и сделать шаг к взаимовыгодному сотрудничеству.

Мы прекрасно понимаем, что в связи с конкурсом у вас могут возникнуть вопросы, на которые правила не дадут ответа. Ниже мы попытаемся охватить самые актуальные из них и рассказать, зачем Wargaming придумал WGDC, какую пользу он может принести участникам, чего мы ожидаем от разработчиков, а также кратко пробежим по самим правилам. Если вопросы останутся и после прочтения поста — задавайте их в комментариях.

Wargaming.net Public API — набор общедоступных программных интерфейсов, которые предоставляют доступ к проектам Wargaming.net, включая игровой контент, статистику игроков, данные энциклопедии и многое другое.

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

Желание написать об C++ API у меня возникло давно, и вот наконец выдался спокойный вечер. По роду деятельности я и мои ребята пишем код на C++ для программистов на C++ и Python, общее ядро функционала, который используется во всех продуктах нашей компании. Разумеется это подразумевает, что код должен иметь интуитивно понятный API, с общей логикой как для низкоуровневого C++, так и для высокоуровневого Python, вне зависимости от разночтения в языках некоторых базовых конструкций. Об объединении C++ и Python я много писал ранее в статьях про Boost.Python, сейчас я очень благодарен архитектуре и логике языка Python, я многое понял и перенял в С++ именно благодаря опыту построения общего API для этих двух таких разных языков, но сейчас речь пойдёт только и исключительно о C++, про API и про то, что такой зверский гибкий язык позволяет сделать с интерфейсом вашей замечательной библиотеки, если не учитывать ряд важных особенностей языка C++.

ГдеСейчас — это гео-ассистент на телефоне, приложение для личного обмена местоположением с друзьями и близкими в один клик, которому можно довериться, не тревожась за свою приватность. Денис Магда, разработчик и сооснователь приложения рассказал об опыте интеграции с Evernote.

Приложение: ГдеСейчас/GeoMe
Разработчик: gdeseychas.ru
Местонахождение: Санкт-Петербург
Платформы: iPhone, Android, Chrome, Pebble
Категория: Связь, Социальные сети
Интеграция: Подключить аккаунт Evernote 

Помимо основной функции (узнать кто и где находится) ГдеСейчас — это инструмент для работы с гео-заметками.  В отличие от социальных сервисов, таких как Foursquare и другие,  здесь речь идет не о публичных местах, а о бытовых: домашние и рабочие адреса друзей, места без определенного названия/адреса, которые могут пригодиться в будущем.

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

Gmail API дают доступ к отдельным ресурсам, таким как Threads, Messages, Labels, Drafts или History. Например, стороннее приложение может запросить доступ только на отправку писем (но не чтение), или только на чтение (но не отправку), или только на изменение меток для писем и цепочек, или только на поиск конкретных писем и цепочек.

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

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

Например, при использовании нового API все приложения, которым просто нужно хранить свои файлы в Диске, смогут получать доступ только к своей папке, лежащей в Диске пользователя в папке «Приложения». В WebDAV API сервису для этого придётся получать у пользователя разрешение на запись/чтение всего Диска, а не только конкретной папки.



В этом посте я хочу рассказывать не о структуре или об операциях, которые умеет выполнять наш API — там всё довольно очевидно — а сразу перейду к интересным вещам: что такое Hypermedia и Machine-readable and Self-describing API, и как мы все это реализовали.

Введение

Если вы завязаны в разработке, то так или иначе сталкивались с баг-трекерными системами. В наши дни обойтись без них в процессе разработки программного обеспечения не просто трудно, а невозможно. Естественно, и нас это не обошло стороной. В компании мы пользуемся системой Redmine. Тут есть все, что нам необходимо:

— Отслеживание состояния задач
— Группировка задач в трекере
— Внутрипроектное обсуждение при необходимости
— Ведение документации (хоть и возможности весьма ограничены)
— Учет времени сотрудников и видов их деятельности

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

Каждый разработчик приложений САПР рано или поздно сталкивается с проблемой хранения в чертеже вспомогательной неграфической информации. Это могут быть атрибуты отдельных графических элементов, атрибуты отдельных листов, или же настройки всего чертежа. В отличие от атрибутов блока, эта информация не видна пользователю и применяется для программной обработки чертежей.

На сегодняшний день существует ряд традиционных способов решения задачи: это добавление XData к элементам чертежа, использование XRecord и создание собственных неграфических объектов.

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

Как это работает и как применяется на практике смотрите под катом.

Если вы собираетесь написать n-ную платежную систему, рекомендую ознакомиться с типичными ошибками в реализации API, которые я собрал в процессе написания модулей для своего проекта.

Удобные и простые решения проблем при интеграции с серверными мощностями — что делать, если возникает задача сделать два продукта, которые бы идеально стыковались, предоставляли бы друг другу консистентные данные и сами по себе работали без сбоев.

С подробностями Егор Тафланиди, Redmadrobot.

Введение

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

Всем привет!
В предыдущей главе мы познакомились с основами бибилиотекиThree.js. Увидели несколько примеров и создали свою первую полноценную Three.js сцену. В этой главе мы немного глубже углубимся в эту библиотеку и попробуем более подробно объяснить основные компоненты, составляющие Three.js сцену. В этой главе вы узнаете о следующем:

1. какие компоненты используются в Three.js сцене
2. что можно делать с объектом THREE.Scene()
3. какая разница между ортогональной и перспективной камерами

Начнем мы с того, что посмотрим, как же можно создать сцену и добавить на нее объекты.

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

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

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

1. Одна из первых проблем с которой я столкнулся — сохранение различных сущностей в одной таблице. Для получения таких записей уже не достаточно просто указать имя модели как это предлагается, например тут. Один из примеров такого механизма — таблица AuthItems, которая используется фреймворком в механизме RBAC (если кто-то не знаком с ним — есть замечательная статья на эту тему). В ней содержатся роли, операции и задачи которые определяются флагом type, и для работы с этими сущностями через API мне хотелось использовать url не такого типа:
   

   GET: /api/authitems/?type=0 - получение списка операций
GET: /api/authitems/?type=1 - получение списка задач
GET: /api/authitems/?type=2 - получение списка ролей

   
   а такого:
   

   GET: /api/operations - получение списка операций
GET: /api/tasks - получение списка задач
GET: /api/roles - получение списка ролей
   

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

   SELECT * FROM users WHERE (age>25 AND first_name LIKE '%alex%') OR (last_name='shepard');
   

   
   
3. Порой не хватает возможности создания, обновления, удаления коллекций. Т.е. изменение n-ого количества записей одним запросом опять же используя поиск и фильтрацию. Например, зачастую требуется удалить или обновить все записи, попадающие под какое-либо условие, а использовать отдельные запросы слишком накладно.
   
4. Еще одним важным моментом была возможность получать связанные данные. Например: получить данные роли вместе со всеми её задачами и операциями.
   
5. Конечно невозможно хоть сколько-нибудь комфортно работать с API не имея возможности ограничить количество получаемых записей (limit), сместить начало выборки (offset), и указать порядок сортировки записей (order by). Так же не плохо бы иметь возможность группировки (group by).
   
6. Важно иметь возможность для каждой из операций проверять права пользователя (метод checkAccess все в том же RBAC).
   
7. Ну и наконец, все это дело нужно как-то тестировать.
   

В результате анализа примерно такого списка «хотелок» и появился на свет мой вариант реализации API на этом замечательном фреймворке!

2013 был ознаменован впечатляющими достижениями в развитии технологии API, а также в ее популяризации и инвестициях в эту сферу. Количество API, отмеченных в ProgrammableWeb, впервые перевалило за 10 000, произошли серьезные денежные вливания и поглощения, связанные с этой технологией, было организовано множество новых конференций, включая нашу собственную конференцию API Strategy and Practice, проведенную совместно с API Evangelist. 2013 отметился и новыми инициативами, такими как API Commons, в рамках которой участники пытаются решить долгосрочные задачи различных отраслей экономики.

Количество действующих пользовательских API, которые мы поддерживаем в рамках нашей платформы по управлению API, возросло за прошедший год в 2 раза – и точно так же вырос API-траффик. Поэтому после такого впечатляющего 2013-го мы задались вопросом: что готовит нам новый 2014-й? И вот наши прогнозы!

 
В данной статье мы познакомимся с программированием DECT модуля SC14CVMDECT, обязательно помигаем светодиодом, а также поделимся опытом разработки решения для SIP-телефонии на базе этого модуля.

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

Если гонится за вами
Слишком много человек,
Расспросите их подробно
Чем они огорчены?
Постарайтесь всех утешить.
Дайте каждому совет,
Но снижать при этом скорость
Совершенно ни к чему.
Г. Остер

Сегодня чудесный весенний день. И не только потому что он весенний и очень скоро кому-то придется ехать на дачу копать картошку. А потому что сегодня версия 2.1 API Яндекс.Карт перестает быть beta-версией и становится основной.

К этому событию мы полностью обновили документацию, добавили новых примеров в песочницу и написали эту статью. В этот раз мы решили не рассказывать только про версию 2.1, так как про нее мы уже и так достаточно поговорили во время запуска беты. Поговорим об использовании API Яндекс.Карт в целом.

Разработка API – очень специфичная область программирования. На любую задумку дизайнера и разработчика накладываются потребности и умения пользователей API. Основной фидбек, который мы получаем – это сообщения пользователей в нашем клубе. Туда присылают примеры сайтов с Яндекс.Картами, багрепорты и рекомендации по улучшению нашего продукта. Мы видим, как API смотрится в боевых условиях, и мотаем на ус.

Некоторые вещи часто делают неправильно. Сегодня я хочу о них рассказать. Все советы, которые вы прочтете — вредные. Если вы поймете, что соблюдаете некоторые из рекомендаций этой статьи, ничего страшного – никогда не поздно сделать ваш проект немного лучше. Итак, Irony mode ON.

Резюме поста в нескольких предложениях

• Возможности Excel в части удаленного доступа и совместной работы с документами на сегодняшний день по меньшей мере сопоставимы с Google Docs;
• Excel-документ может быть интегрирован в html-страницы с сохранением значительной части функциональности, т.е. формулы и pivot tables будут работать;
  
• Я, равно как и любой другой человек, могу опубликовать свой Excel-документ таким образом, что ваше, равно как и чье-либо еще, веб-приложение сможет:
  
  1. отрисовать и открыть его для ручного ввода значений в ячейки,
  2. напрямую взаимодействовать с ним через JavaScript;
     
• У Microsoft есть сайт, посвященный интеграции Excel-документов в веб-приложения; также в природе существуют jQuery плагины, позволяющие сделать эту интеграцию быстрой и безболезненной;
  
• С практической точки зрения пользователь получает следующие плюшки:
  
  1. JavaScript представляет широкие возможности для визуализации и анимации Excel-таблиц, а также создания на их базе интерактивных приложений и дэшбордов;
  2. Возможность работы с Excel-документами на планшетах и мобильных устройствах;
  3. Удобный инструмент для создания рабочих прототипов систем управленческой отчетности.

При создании пользовательских объектов на традиционном C++ API (NRX в nanoCAD, ObjectARX в AutoCAD) для обеспечения сохранения объектов и чтения их из файла чертежа необходимо в явном виде описывать запись (сериализацию) и чтение (десериализацию) каждого поля. В MultiCAD.NET API применён более привычный .NET разработчикам описательный подход, в основе которого лежит стандартная .NET сериализация.

Применение сериализации, нечувствительной к версии объектов (Version Tolerance Serialization), предоставляет разработчикам более гибкий механизм управления совместимостью объектов разных версий, чем существующий в традиционном C++ API, где предусмотрено чтение предыдущих версий, но чтение файлов «из будущего» невозможно.

В MultiCAD.NET при описании новых версий объектов можно указать, что вновь добавленные поля необязательны, и тогда чертёж, сохранённый в формате новой версии приложения, прочтётся и в предыдущей версии. Разумеется, без изменений остался и традиционный подход, приводящий к созданию прокси объектов (кешированной графики объектов) при загрузке чертежа в предыдущую версию приложения.

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