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

Поскольку API — программный продукт, разработчики фактически будут задавать вопросы о работе того или иного фрагмента кода, который они пишут. Этот факт сам по себе задирает планку требований к качеству специалистов поддержки до очень высокого уровня, поскольку прочитать код и понять причину проблемы может только разработчик же. Но это полбеды: другая сторона проблемы заключается в том, что, как мы упоминали в предыдущих главах, львиная доля этих запросов будет задана неопытными или непрофессиональными разработчиками, что в случае любого сколько-нибудь популярного API приводит к тому, что 9 из 10 запросов будут вовсе не про работу API.

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

Все случилось одним летним тёплым днем. Когда меня озарило, или солнечный удар случился, что надо вложиться в деньги. Пошарив по закромам, я даже нашёл небольшую финансовую подушку с остатками моей стипендии. Отлично, начало положено, теперь надо что-то купить, чтобы стать богатым.

Привет, меня зовут Юрий, и я фулстек-разработчик в DataLine. В компании занимаюсь созданием и развитием внутренних и внешних ИТ-сервисов: Сервисдеска, мастер-справочников, учета оборудования. 

Но, как говорится, каждый разработчик в жизни должен сделать 3 вещи: развернуть дерево, распарсить DOM и вырастить своего чат-бота. О последнем и поговорим: расскажу, как делал своего первого чат-бота для нашего Сервисдеска, какие задачи и как решал, с какими трудностями и способами преодоления столкнулся. 

Задача отсеивания нежелательных запросов, в общем случае, состоит из трёх шагов:

- идентификация подозрительных пользователей;

- опционально, запрос дополнительного фактора аутентификации;

- вынесение и применение решения об ограничении доступа.

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

Статья из серии "2х минутные заметки разработчика".

В начале апреля состоялся онлайн-марафон идей Spotlight Digital Challenge. На нем встретились 260 участников и участниц из Кыргызстана, Казахстана, Таджикистана,  Узбекистана и Туркменистана. Всё ради необычной задачи — команда организаторов предложила хакнуть социальные проблемы, связанные с гендерной проблематикой.

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

Это исследование данных. Как внутри программы мы получаем данные, создаем, трансформируем и передаем.

Мой опыт разработки под iOS с 2008 года, примеры на языке Swift.

Привет! Меня зовут Руслан, я разработчик ноды Waves Enterprise. Одна из особенностей нашей платформы — это использование контейнеризированных смарт-контрактов, что позволяет писать их на любом языке и таким образом легко входить в блокчейн-разработку со знакомым стеком. В этом посте я расскажу, как у нас запускаются и валидируются смарт-контракты, как они работают и взаимодействуют с нодой. И что, наверно, интересней всего — как организовано их согласованное параллельное исполнение.

В контексте работы с API мы говорим о двух видах пользователей системы:

пользователи-разработчики, т.е. ваши партнёры, разрабатывающие код поверх вашего API;

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

Со временем использование API приобретает все более повсеместный характер. BFF (Backend For Frontend) — общепринятый подход, DDD набирает обороты, а принципы проектирования API встречаются повсеместно. Несмотря на все это, мы продолжаем наблюдать, как организации, придерживающиеся всех этих практик, с трудом осваивают новые каналы.

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

Обычное использование httr2 — это создание обёртки над каким нибудь API и предоставление его в виде R пакета, в котором каждая конечная точка API (то есть URL-адрес с параметрами) становится функцией. Эта статья поможет разобраться, как начать с очень простого API, не требующего аутентификации, а затем постепенно приводимые примеры будут усложняться. 

Это глава 26 моей бесплатной книги «API».

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

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

Очевидный ключевой показатель эффективности (Key Performance Indicator, KPI) №1 — это количество конечных пользователей и количество интеграций (читай, партнёров, использующих API). В нормальной ситуации он является в определённом смысле барометром состояния бизнеса: если предположить, что на рынке наблюдается здоровая конкуренция между API разных поставщиков, и все находятся в более-менее одинаковом положении, то количество использующих API разработчиков (и как производная — конечных пользователей) и есть главный показатель успеха продукта.

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

Интерактивное дерево комиксов с связями и обложками, написанное на d3.js 6.
Данные берутся динамически по API Marvel.

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

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

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

В этой статье мы рассмотрим описание процесса тестирования программного обеспечения сквозь призму работы с API. Я попытался собрать полезные факты из книги “Hands on restful API design and the best practices” авторов Harihara Subramanian и Pethuru Raj. В книге подробно описываются этапы проектирования API и есть отдельная глава по тестированию RESTful сервисов в связке с API.

Можно читать в связке с моим предыдущим переводом “Стратегия тестирования REST API: что именно вам нужно тестировать?”. По ходу перевода я привожу примеры из личной практики (выделены курсивом), чтобы наглядно проиллюстрировать каждый этап из книги.

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

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

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

Естественно, в рамках нашей статьи мы не будем «выдумывать» целый сервис, но попробуем сделать систему общения с персоналом интернет-магазина удобной и защищенной от кражи персональных данных недобросовестными исполнителями. А поможет нам в этом Telecom API от компании MTT.

Сегодня мы с вами:

- используем API, для умной переадресации вызова;

- скроем номер звонящего, от некоторых сотрудников сервиса;

- разберемся с добавочными номерами;

- сделаем аудио сообщения из строки текста;

- обработаем вызовы REST API на сайте с помощью PHP;

- напишем на Kotlin простенький макет приложения для звонка.

Управление продуктом API требует выстраивания отношений и с бизнес-партнёрами, и с разработчиками. (В идеале и с конечными пользователями, но эта опция для провайдеров API крайне редко доступна.)