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

Привет, Хабр! Мы продолжаем нашу экспериментальную серию статей, наблюдая за которой вы можете в реальном времени влиять на ход создания игры на UWP. Сегодня на повестке дня — получение данных пользователя. Ведь почти во всех приложениях это — нужная процедура. Присоединяйтесь!

Как только в компании появляется хотя бы две информационных системы, которым необходимо обмениваться данными, возникает вопрос, как организовать их взаимодействие. Вариантов множество: файловый обмен, линки между базами данных, web или rest сервисы, различные системы обмена сообщениями, устаревшие RPC и CORBA, новомодный gRPC и т.д. Выбор зависит от предпочтений участников проекта и от возможностей систем (архитектура системы, используемая платформа, наличие готового API и пр.). Предположим, выбрали какой-то способ обмена, системы начали взаимодействовать, все хорошо. Но потом возникает третья система, с которой тоже надо интегрироваться, потом четвертая и т.д. Нужно опять садиться и выбирать способ обмена, и не факт что удастся ограничиться уже используемыми технологиями (где-то это продиктовано ограничениями новых систем, где-то разработчик настоял на другой технологии или захотел попробовать что-то новое). С ростом количества систем растет количество и сложность взаимодействий между ними, растет количество используемых технологий. В итоге вся интеграционная архитектура компании начинает напоминать запутанный клубок разноцветных ниток, как-то связывающих системы компании, который все сложнее распутывать при разборе ошибок и доработках. Рано или поздно начинают приходить мысли о создании единой интеграционной среды, которая прозрачно и расширяемо свяжет все системы воедино.

В этой статье я расскажу об опыте использования Apache ServiceMix (Camel) и RabbitMQ для построения такой интеграционной среды.

Наверное, абсолютно все читатели используют API, работая с фрэймворками, библиотеками, виджетами, как некий язык общения между сущностью и основным приложением. И вы наверняка замечали, что некоторыми API удобнее пользоваться, а в некоторых есть явные проблемы. Всеволод Шмыров (@vsesh) в своем докладе на Frontend Conf, расшифровку которого вы найдете под катом, постарался ответить на вопрос, какой API является хорошим.

Рассказ опирается на опыт разработки АPI Яндекс.Карт, и хотя это и JavaScript-библиотека, многие принципы и особенности его разработки применимы и к другим типам АPI, к примеру, к серверным API и Standalone библиотекам. Все то, о чем пойдет речь, относится именно к публичному АPI. Если к API вашей библиотеки обращаются только ваши коллеги, которым вы можете легко рассказать, что где-то что-то надо поменять, то вы, скорее всего, не столкнетесь с теми проблемами, с которыми сталкиваются разработчики публичного АPI.



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

• Проектирование интерфейса
  
• Обратная совместимость
  
• Исследование своего API
  
• Дополнительные действия
  

В марте 2018 года Альянс FIDO (Fast IDentity Online) и Консорциум W3C достигли важного рубежа: после двух лет разработки стандарт Web Authentication (WebAuthn) получил статус кандидата в рекомендации (CR) — это стабильная версия документа, в которую больше не планируется вносить принципиальных изменений. Обсуждение CR завершилось 1 мая.

Что дальше? Теперь очередь Google, Mozilla и Microsoft. Когда поддержку Web Authentication API независимо и совместимо реализуют в двух браузерах, стандарт получит статус предложения в рекомендации. К этому моменту будут рассмотрены все предложения от сообщества — и документ представят Консультативному Совету W3C для окончательного утверждения.

Существует новое API JavaScript, предназначенное для организации асинхронного доступа к буферу обмена с использованием спецификации, которая всё ещё находится на этапе разработки. До сих пор в веб-разработке стандартным способом копирования текста в буфер обмена является подход, предусматривающий использование метода document.execCommand. Основной недостаток этого подхода заключается в том, что это — синхронная блокирующая операция. Асинхронное API для работы с буфером обмена основано на промисах, одной из его задач является устранение этого недостатка. Оно призвано дать веб-разработчикам более простое в использовании унифицированное API для работы с буфером обмена. Кроме того, это API спроектировано с учётом возможности поддержки множества типов данных, а не только text/plain.

Надо отметить, что сейчас новое API доступно только в Chrome 66+ и поддерживает лишь копирование и вставку обычного текста. Кроме того, работает оно только тогда, когда страница загружена по HTTPS или с localhost, и только в тех случаях, когда страница открыта в текущей активной вкладке браузера.

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

Здравствуйте, коллеги.

Сегодня хотим обсудить с вами такую нетривиальную тему как архитектура IoT для больших предприятий. Популяризация IoT на русском языке идет полным ходом, однако на английском языке уже выходят первые серьезные книги об архитектуре таких решений в масштабе (больших) предприятий. Нас изрядно заинтересовала следующая книга Перри Ли (Perry Lea):


Просим вас активно высказываться насчет актуальности этой книги. Если кто-то хочет поделиться реальным опытом реализации промышленного IoT в России и/или отрецензировать перевод книги — также пишите.

Под катом предлагаем перевод публикации Red Hat, где рассмотрены вопросы грамотного и безопасного проектирования API для IoT-систем

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

Сегодня утром я открыл почтовый ящик и обнаружил около 150 предупреждений из программы мониторинга лога. Я подумал, что случайно запушил какой-то баг в продакшн — и быстро начал расследование. Но вскоре стало понятно, что некий парень очень быстро создаёт новые учетные записи на нашем сервисе API скриншотов ApiLeap и быстро расходует весь кредит бесплатного плана на каждом аккаунте.



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

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

Здравствуйте коллеги, сегодня мы расскажем и продемонстрируем подходы и механизмы автоматизации системы защиты от сетевых атак на основе Check Point и Splunk.

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

Я специально объединил 2 темы в одну, так как для нас работа по API, создание того или иного сервиса или внедрение нового функционала в свой имеющийся – это по своей сути точно такие же партнёрские отношения. Мы открыты к сотрудничеству в любых сферах деятельности и в любом направлении, предлагая по-настоящему надёжные услуги на самом современном серверном оборудовании. Такие, какими мы пользуемся сами изо дня в день для других направлений бизнеса. Речь, разумеется, пойдет о предоставлении серверов VPS Windows в аренду.

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

На недавнем митапе в офисе Tutu я рассказывал о том, как мы в рамках редизайна superjob.ru совершали переход от монолитного приложения к api-based архитектуре с красивыми single page applications на ReactJS на фронте и шустрым PHP-приложением на бэке. В этой статье я бы хотел подробнее рассказать о том, как мы оптимизировали наше бэкенд-приложение, чтобы оно действительно стало шустрым.

Заинтересовавшихся — прошу под кат.

История превью страниц.


Когда вы наводите курсор на ссылку, появляются карточки предварительного просмотра (и да, у меня на десктопе мобильный скин Википедии). Текст из статей Википедии об айсбергах и воде, CC BY-SA 3.0. Изображения слева направо, сверху вниз: #1 Ким Хансен, CC BY-SA 3.0; #2 Андреас Вайт, CC BY-SA 4.0; #3 Национальная библиотека Новой Зеландии, CC0

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

На первый взгляд всё очень просто. Такое есть на многих сайтах. На карточке размещается изображение и немного текста — и она отображается при наведении курсора на ссылку. Ничего инновационного… по крайней мере, так может показаться на первый взгляд.

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

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

Работать с интернет-банкингом большого количества предприятий может оказаться достаточно рутинной задачей. Для создания платежей и их контроля необходимо каждый раз переключаться между кабинетами. А если таких организаций больше 50, то можно с легкостью сбиться и наделать ошибок, не говоря уже о портаченном времени. Давайте посмотрим, как можно облегчить жизнь бухгалтера на примере API ПриватБанка для бизнеса.

Много кто пользуется приложением Сбербанк Онлайн, но немногие знают, как оно работает. Настало время приоткрыть завесу тайны – в этой статье мы расскажем о некоторых подходах, которые используем в разработке.

На форуме TechNet Microsoft каждый день появляются новые вопросы, касающиеся разработки для Exchange\Exchange Online. Актуальными на сегодняшний день являются два метода разработки: с использованием веб-сервисов (EWS Exchange и другие) и без их использования. В этой статье рассмотрим оба варианта и обозначим их плюсы и минусы.

В JS API Яндекс.Карт существует возможность создавать различные объекты на карте. Один из их них – многоугольник, с помощью которого можно улучшить интерактивность пользовательской карты: выделить отдельные области или отобразить местоположение неточечного объекта. К примеру, так можно показать план строительства нового квартала или зоны доставки пиццы.

У пользователей API Яндекс.Карт давно появился вопрос о добавлении подписей поверх многоугольников. Люди предлагали хитрые решения, чтобы добавить подпись на объект в нужном месте, скрыть ее, перекрасить и т.п., но такие решения получались сложными и негибкими.

К примеру, к нам пришел отдел исследований Яндекса с просьбой написать удобный инструмент для подписи многоугольников после того, как они сделали несколько исследований на карте мира.


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

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

Вам нравится процесс ожидания? Когда необходимо сидеть и ждать, пока одна из статистик/аналитик/метрик загрузится…

«Но у нас все нормально, — ответите вы. — У нас крутые спецы, наши страницы грузятся за доли секунд, мы даже кешировать умеем.»

А как на счет мобильного интернета? Когда приходится окунаться в прошлое, лет на 10 назад и можно угадать элементы верстки по мере рендеринга страницы?

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

В эпоху Интернета вещей (Internet of Things, IoT) все более актуальными становятся задачи обработки, фильтрации и анализа данных как можно ближе к их источнику, поскольку это позволяет действовать удаленно вместо того, чтобы пересылать эти данные в центры обработки данных (ЦОД) или облака для фильтрации и анализа.

Еще одна причина для развертывания инструментов аналитики на периферии сети заключается в том, что сегодня появляются все новые варианты применения Интернета вещей, и во многих случаях объем данных, генерируемых на периферии, предъявляет такие высокие требования к полосе пропускания и вычислительной мощности, что доступные ресурсы не способны их удовлетворить. То есть ЦОД, предназначенные для решения более традиционных корпоративных задач, могут не справляться с потоками данных от интеллектуальных устройств, датчиков и т. п.

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

10 апреля 2018 года компания GlobalSign объявила о присоединении к консорциуму Cloud Signature и партнёрской программе Adobe Cloud Signature. Оба соглашения предусматривают, что фирменный сервис облачных подписей Digital Signing Service теперь напрямую интегрирован с решением для подписи документов Adobe Sign в облаке Adobe Document Cloud.

Adobe Document Cloud — это полный комплект решений для работы с цифровыми документами, ускоряющих и упрощающих бизнес-процессы за счёт перевода всей бумажной работы в цифровое защищённое пространство. Сюда входят сервисы Adobe Sign, Acrobat DC, веб-приложения и мобильные приложения, которые работают в автономном режиме или встраиваются в существующие рабочие процессы. Система интегрирована и нормально работает с программами Microsoft, Salesforce, Workday, SAP Ariba, Dropbox и прочими, а служба Adobe Sign (теперь и GlobalSign) является предпочтительной службой подписи документов в приложениях Microsoft.