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

Большинство людей не задумываются о геокодировании, когда дают своему смартфону запрос в виде адреса, GPS-координат, широты и долготы, или координат what3words. Разработчики в свою очередь должны понимать всю критическую важность геокодера. Каждый из предложенных геокодеров имеет свои плюсы и минусы, которые нужно учитывать при выборе. Некоторые геокодеры могут иметь неприемлемые ограничения, стоимость, или быть недоступными для коммерческих целей. Некоторые сервисы не поддерживают кэширование, и практически все они имеют 24-часовые лимиты. Универсального варианта не существовало до появления OpenCage.

Во всех руководствах в описаниях REST дают простые примеры, типа вот вам пользователи, они будут ресурсом /users, вот вам один пользователь, он будет /users/[id] и действия с ним добавить\удалить\изменить.

А что если действия сложные или комплексные и не вписываются в GET\POST\DELETE?

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

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

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

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

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

В конце октября 2014 года в Москве прошла 10-я юбилейная конференция «Разработка ПО, CEE-SECR-2014», на которой был представлен наш доклад о создании кросс-САПР-платформенных приложений. Доклад состоял из исторического обзора, рассказа об опыте портирования САПР приложений на nanoCAD и анализа основных затруднений при портировании. В настоящей статье мы не будем останавливаться на первых двух частях доклада — запись опубликована в конце статьи, а более подробно рассмотрим третью часть, доработанную по результатам обсуждения доклада в кулуарах конференции.

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

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

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

Интерфейсы программирования приложений (Application programming interfaces, APIs) уже давно стали одним из инструментов разработчиков, помогающих создавать и связывать приложения. Скоро веб API или интерфейсы сервисов, вызов которых происходит по Сети, станут частью любого нового сценария работы с ИТ: от Интернета вещей до аналитики, интеграции сервисов или фиксации состояния пользователя. Роберто Медрано из SOA Software поделился своими соображениями о том, чем в этом году нам смогут помочь веб API, и оказалось, что с их помощью можно будет решать практически любые задачи.

Цель данной статьи — показать возможный подход для построения микросервисов с использованием Scala, RESTful JSON, Spray и Akka. В качестве базы данных мы будем использовать MongoDB. В результате нашей работы мы упакуем наш проект в Docker-контейнер, а Vagrant и Ansible позволит нам управлять конфигурацией приложения.

В этой статье вы не найдете подробностей о языке Scala и других технологиях, которые будут использоваться в проекте. В ней вы не найдете руководства, которое ответит на все ваши вопросы. Цель статьи — показать технику, которую можно использовать при разработке микросервисов. На самом деле, большая часть этой статьи не завязана на конкретной технологии. Docker имеет более широкую сферу использования, нежели только микросервисы. Ansible позволяют быстро развернуть любое требуемое окружение, а Vagrant — отличный инструмент для создания виртуальных машин.

Привет, хабралюди!

Хочу поделиться с вами небольшим опытом использования Flickr API в Android приложениях и рассказать об авторизации пользователя Flickr. Которую в дальнейшем можно будет использовать например для вывода списка альбомов и изображений.

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

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

Был создан репозиторий на гитхабе, зарегистрирован временный домен в зоне .tk (почему временный, я думаю, объяснять не стоит. Кому интересен сей проект, милости прошу под кат.

Сегодня Яндекс убил сервис Яндекс.Подписки. Несмотря на то, что о нём гордо писали во время закрытия Google Reader, мол — мы остаёмся, теперь сервис убит и всех насильно перетащили в Яндекс.Новости.

Можно скачать архив подписок, который там был. Но там в xml-файле только адреса rss-лент.
Самое ужасное, что они потеряли все непрочитанные статьи. Я вот, например, некоторые записи в ленте держал непрочитанными, чтобы позже к ним вернуться, когда будет время.

API, пока что, работает, через него ещё можно спасти непрочитанное. Сдаётся мне, что его тоже убьют.

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

Пост в Блоге Яндекс.Почты с анонсом.

UPDATE: с 31 марта закрыт и API сервиса.

TWCC, World Coordinate Converter — это открытое бесплатное веб-приложение, разработанное Клеманом Ронзоном. Оно позволяет конвертировать пространственные координаты между большинством из существующих систем, к которым не так давно присоединилась и система what3words.

Во время работы над проектом по стримингу аудио необходимо было добавить поддержку новых сервисов, таких как Яндекс.Диск. Работа с аудио в приложении реализована через AVPlayer, который проигрывает файлы по url и поддерживает стандартные схемы, такие как file, http, https. Все работает отлично для сервисов, в которых токен авторизации передается в url запроса, среди них DropBox, Box, Google Drive. Для таких сервисов, как Яндекс.Диск, токен авторизации передается в заголовке запроса и к нему AVPlayer доступ не предоставляет.

Поиск решения этой проблемы среди имеющегося API привели к использованию объекта resourceLoader в AVURLAsset. С его помощью мы предоставляем доступ к файлу, размещенному на удаленном ресурсе, для AVPlayer. Работает это по принципу локального HTTP прокси но с максимальным упрощением для использования.

Привет, Хабр!

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

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

FutoIn — с одной стороны, это «клей» из стандартов/спецификаций разных мастей для унификации программных интерфейсов различных существующих проектов по устоявшимся типам, с другой — это концепция для построения и масштабирования компонентов проекта и инфраструктуры, написанных на разных технологиях, без потребности в добавления этого самого «клея».

AsyncSteps — это спецификация и реализация программного интерфейса для построения асинхронных программ в независимости от выбранного языка или технологии.

Цели, поставленные для концепции:

• реализация (с оговорками) должна быть возможна на всех распространённых языках программирования с поддержкой объектов и анонимных функций. Репрезентативный минимум: С++, C#, Java, JavaScript, Lua (не ООП), PHP, Python;
• написанная программа должна легко читаться (сравнимо с классическим вариантом);
• должны поддерживаться исключения языка (Exceptions) с возможностью перехвата и разворачиванием асинхронного стека до самого начала;
• требуется удобство для написания асинхронных библиотек с единым подходом для вызова, возврата результата и обработки ошибок;
• предоставить простой инструмент для естественного распараллеливания независимых веток программы;
• предоставить простой инструмент создания асинхронных циклов с классическим управлением (break, continue) и меткой для выхода из вложенных циклов;
• предоставить место для хранения состояния исполняемой бизнес-логики;
• возможность отменять абстрактную асинхронную задачу, правильно завершая выполнение (освобождая внешние ресурсы);
• возможность легко интегрироваться с другими подходами асинхронного программирования;
• возможность ограничивать время выполнения задачи и отдельно каждой подзадачи;
• возможность создавать модель задачи для копирования (улучшения производительности критичных частей) или использования как объект первого класса для передачи логики в качестве параметра (а-ля callback);
• сделать отладку асинхронной программы максимально комфортной.

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

Идеальным вариантом было бы пристроить небольшой индикатор прямо рядом с курсором в поле ввода, но это оказалось сложной задачей: некоторые приложения вообще не используют системный курсор. Простым и достаточно удобным решением проблемы оказалась смена цвета панели задач и заголовка окна во всей системе. Как оказалось, это можно делать программно при помощи недокументированных возможностей Desktop Window Manager API…

К нам в техподдержку часто приходит вопрос: «Как посчитать суммы длин отрезков (участков трубопровода, элементов электрических схем и т.п.) в чертеже?». Существует масса способов решения этой задачи, в сегодняшней публикации мы рассмотрим реализацию приложения на MultiCAD.NET API, суммирующего длины, которое работает в nanoCAD, AutoCAD и ZWCAD. В качестве примера мы возьмем задачу определения суммарной длины труб в схеме водоснабжения и рассмотрим два варианта выбора элементов для подсчета: пользовательский и по созданному фильтру.

На фото: Том Круз в фильме Лучший Стрелок

В этой статье мы рассмотрим взаимодействие Single Page HTML Application с облачной MongoDB через JavaScript. В качестве MongoDB-as-a-Service я возьму Mongolab. Стоимость развернутой MongoDB, с объёмом в 500мб, обойдется нам всего-лишь в 0 USD.

Для того, чтобы создать todo-лист, нам не потребуется бекенд. Взаимодействовать с Mongolab мы будем через REST API, а обертку для него в клиентской части мы напишем не прибегая к помощи сторонних JavaScript-фреймворков.

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

Impress Application Server (IAS) — это сервер приложений для Node.js с альтернативной архитектурой и философией, не похожий на мэйнстрим разработки под нодой и призванный упростить и автоматизировать широкий круг повторяемых типовых задач, поднять уровень абстракции прикладного кода, задать рамки и структуру приложений, оптимизировать как производительность кода, так и производительность разработчиков. IAS покрывает сейчас только серверные задачи, но делает это комплексно, например, можно объединить на одном порту API, веб-сокеты, стриминг, статику, Server-Sent Events, проксирование и URL-реврайтинг, обслуживать несколько доменов и несколько приложений, как на одном сервере, так и на группе серверов, работающих в связке, как одно целое, как один сервер приложений.

Друзья, под закат уходящего 2014 года и начала 2015 есть отличная новость для всех кто любит работать с открытыми данными, участвовать в конкурсах для разработчиков.

А также, я уверен, что есть и те кто любит историю и исторические данные.

С 23 декабря Минфин России с нашей помощью Информационной культуры открывает конкурс приложений BudgetApps http://budgetapps.ru/contest на открытых данных которые Минфин России публиковал последние несколько лет.



Данные самые разные. Это данные о бюджетах, данные об аудиторских организациях, государственном долге, государственных резервах и многое другое.

Ну и, так оказалось, что меня зовут Иван Бегтин и я член жюри этого конкурса.

Все они есть по ссылке на сайте Минфина — http://minfin.ru/ru/opendata/
И много бюджетных данных есть на Едином портале бюджетной системы — http://budget.gov.ru/data/opendata там есть структура бюджета в CSV формате, сами данные, справочники и многое и многое другое. А также данные по всем официальным учреждениям вот тут http://bus.gov.ru/public/opendata.html. На этот ресурс обратите особое внимание. Там опубликованы индикаторы, бюджеты, уставы и многое другое по каждой государственной организации и муниципальном учреждении в России. Если Вы задумаете любой региональный проект, то эти данные будут просто бесценны.

Это не значит, что нельзя использовать какие-либо другие данные, безусловно можно и нужно, однако поскольку это конкурс Минфина России, то конечно ожидается что другие данные будут использоваться вместе с этими.

Я лично считаю, что не стоит ограничиваться только теми данными которые уже переведены в машиночитаемый вид. Есть также данные которые можно превратить в открытые данные самостоятельно.
Многие умеют писать парсеры, но для тех кто этого не делал раньше, хорошее подпорье может быть ScraperWiki (https://scraperwiki.com/) чтобы собрать информацию со страниц, а также разные библиотеки для разбора Excel файлов, извлечение таблиц из PDF документов — с помощью pdftables.com или сервисов Abbyy или их Abbyy Finereader.

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

Исторические бюджеты