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

Чек-лист для проектирования API

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

1. Проектировать для потребителя

   • Ориентироваться на потребности клиентов API, а не на простоту реализации или устройство базы данных. Об этом, кстати, подробно написано в отличной книге Лоре Арно “Проектирование веб-API”.

   • Учитывать интересы всех клиентов. Не забывать, что могут появиться новые клиенты.

   • Сложную логику реализовывать на сервере. Искать баланс между универсальностью API и нагрузкой на клиента, исходя из реалий проекта.

2. Проектировать понятные API-схемы

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

   • Избегать обобщающих наименований, типа “flag”. Описывать в названии, какой бизнес-смысл несет этот параметр или метод. Например, флаг с признаком пустой упаковки можно назвать “isEmpty”.

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

   • Отдавать адекватные текстовые коды ошибок, из которых будет однозначно понятно, что поправить в запросе для успешного его выполнения. Например, отдавать не 400 BAD_REQUEST, а 400 PRODUCT_NOT_FOUND.

3. Принять конвенции и придерживаться их

   • Использовать везде либо snake_case, либо camelCase, либо kebab-case, не менять правила от метода к методу.

   • Стандартизировать формат ошибок - во всех методах отдавать их в одинаковой структуре.

   • Если это HTTP, то зафиксировать, в каких случаях какие коды ответов будут возвращаться. Например, иногда возвращается всегда 200, а потребители ориентируются только на тело ответа.

   • Договориться о формате версионирования API.

   • Стандартизировать типы данных: формат дат, UUID и пр.

4. Думать о безопасности, производительности и надежности

   • Использовать аутентификацию, авторизацию и ACL. Разграничивать доступ на уровне конкретных методов и даже параметров.

   • Оценивать количество запросов и объем ответов.

   • Индексировать БД по тем полям, по которым собираются выборки данных для API.

   • Использовать асинхронное взаимодействие, если задача на сервере выполняется ощутимое количество времени.

   • Делать обратную совместимость везде, где это возможно.

5. Документировать

   • Сначала писать документацию, а только потом разрабатывать. Такой подход минимизирует количество ошибок и проблем с API.

   • Помечать изменения тегами задач и, при необходимости, цветом.

   • Описывать логику работы методов/топиков/очередей. При необходимости добавлять диаграммы последовательности и маппинги данных.

6. Мониторить и анализировать

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

   • Смотреть в консоли разработчика на проде, как быстро отрабатывают те или иные запросы и т.д.

   • По возможности настраивать системы мониторинга и алертинга. Это помогает прогнозировать рост нагрузки и отслеживать эффективность системы.

У каждого API‑проектировщика со временем появляется свой набор правил. Было бы интересно сравнить — добавляйте свои пункты в комментариях.

Другие мои материалы можно почитать в телеграм-канале breakfront.

Задача о габаритном файле и ошибке

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

Условие

В компании «Доки.Онлайн» выкатили обновление: теперь пользователи могут загружать PDF-файлы с отсканированными договорами. Все работало отлично в локальной среде — разработчик протестировал загрузку больших файлов, убедился, что API обрабатывает их корректно, и спокойно отправил изменения в продакшн.

Но радость была недолгой. На боевом сервере при попытке загрузить файл система выдавала ошибку 413 Request Entity Too Large. Причем происходило это до того, как пользователь получал какой-либо отклик от самого приложения.

Разработчик Геннадий Завров начал искать причину. Он проверил логи всех четырех компонентов системы:

• фронтенда;

• API Gateway (определяет, в какой микросервис послать запрос);

• микросервиса загрузки файлов;

• микросервиса обработки документов.

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

Геннадий начал подозревать сетевые сбои, перегрузку API Gateway и баг в коде фронтенда. Однако простые тесты с маленькими файлами работали стабильно. Проблема проявлялась только при загрузке чего-то «потяжелее».

В какой-то момент он задал себе вопрос: а точно ли запрос доходит до приложений?

Задача

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

Делитесь своим ответом в комментариях. А посмотреть полное решение можно в Академии Selectel.

Представлен ресурс (Context7 MCP - Up-to-date Code Docs For Any Prompt) из 9000 API с документацией для автоматического подключения к любым нейросетям. Поддерживается: Cursor, Windsurf, VS Code, Docker, Claude.

Безопасная разработка API на практике

Как устроен ваш цикл разработки приложений? Проверяются ли API на наличие уязвимостей до их публикации? И есть ли вообще для этого процесса какая-то методология?

Вместе с экспертом команды Вебмониторэкс, участвующим в совместной работе с ИСП РАН, подробно разберём, как выстроить эффективный процесс тестирования API, и чем отличаются различные его виды.

Когда? 23 апреля в 14:00

Спикер: Динко Димитров, руководитель продуктового направления, Вебмониторэкс

Зарегистрироваться на мероприятие 

Ждем вас на вебинаре!

Как писать REST API — 9 правил

REST API (Representational State Transfer Application Programming Interface) — это архитектурный стиль взаимодействия между клиентом и сервером через HTTP. Он определяет принципы построения API, обеспечивая стандартизированный и эффективный обмен данными между различными системами.

1. GET-запросы не должны что-то сохранять, удалять или изменять. Нельзя менять какие-либо данные на стороне сервера при GET-запросе. Почему? GET-запросы часто кешируются на стороне клиента.

2. POST запросы для загрузки/создания сущностей, PUT для изменения в сущности, а PATCH - для мелких изменений в сущности.

3. Наименование эндпоинтов. Должен присутствовать единый стиль, и желательно во множественном числе, ибо это более лаконичнее. Например, эндпоинт /users. Можно и единственное число использовать, но обосновано.

4. Иерархия. Нужно соблюдать единую иерархию для построения запросов. Конструкции /users/1/friends/3/items/4 будет неудобно использовать разработчикам клиентских приложений. Нужно избегать такую иерархию, нужно конкретно указывать что нам нужно, не перезагружать данными.

5. Соблюдайте версионирование API. Допустим: /api/v1/get_all_users и /api/v2/get_all_users. При выходе новой версии не всегда разработчики готовы переписать логику клиентских приложений, и для этого нам нужно разделять версии API

6. Чувствительные данные. Очень важный момент. Например, передача различных паролей в Query-параметрах запрещено, только в теле запроса.

7. Из 6 вытекает 7е правило: не логируйте персональные и прочие секретные данные. Было несколько случаев, когда из-за логирования параметров утекали данные пользователей.

8. Расширение ответов. Во-первых, не передавайте массивы в самом верхнем уровне ответа. JSON-ответ от сервера не должен быть массивом, только словарь (ключ-значение). Если мы будем возвращать список, в будущем нам будет неудобно расширить ответ сервера, добавив дополнительные параметры. А также иногда в API разработчики делают обязательные параметры, например помимо самих данных параметр success и error, чтобы клиентское приложение могло понять, что произошла ошибка, или наоборот, успешно выполнилось.

9. Работа с датой и временем. Есть два метода - использование Unix Timestamp (количество секунд прошедших с 1 января 1970 года). Это в какой-то степени более удобно для машины, но менее удобно для клиентского разработчика. И второй метод как раз делает формат даты и времени более понятным - это ISO 8601 (2025-04-05T12:00:00.100Z). Этот метод более удобный, т.к. мы понимаем дату и часовой пояс, точное время.

10. Бонусное правило, лично мое. Относится не только к REST API, но и в принципе к программированию. Пишите код так, как будто эта поэма, книга. Попробуйте сами поработать со своим API, будто вы его не писали. Разделение ответственности, единая точка отказа, Don't Repeat Yourself и даже Keep It Simple, Stupid. Все это конечно-же вариативно.

Полезные расширения для vsCode | просмотр JSON в виде дерева | Json Tree editor

Всем привет, этим постом начинаю серию постов с полезными плагинами для vsCode

🚀 Наименование: Json Tree editor

✍️Описание: расширение VSCode для визуализации данных JSON в виде дерева, с возможность выбора, перемещения и сортировки.

🔗 Ссылка на плагин: https://marketplace.visualstudio.com/items?itemName=GregChamblin.vscode-json-editor

Extension id: GregChamblin.vscode-json-editor

➕Плюсы:

• Можно работать с большими файлами json

• Есть отдельная кнопка на панели задач

• При перетаскивании в дереве элементов, сам json также изменяется онлайн

➖Минусы:

• Не выявлено

🚀Делитесь своими плагинами в комментариях.

#vsCode #JSON

Подписывайтесь на меня в телеграмм, там ещё много интересных плагинов @sa_chulan

[RFC] Открытый формат обмена данными об условиях кешбэка COIN

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

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

Предлагаемое название для подобного формата "COIN" (Cashback (details) Open Interchange - открытый обмен данными о кешбэке).

В качестве формата хранения данных предлагается JSON. Прототип формата опубликован в репозитории.

Демо-сервис базовых возможностей использования формата COIN Кашевар-онлайн

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

Основные темы вебинаров:

• Защита веб-приложений (WAF)

• Защита интеграций между сервисами (API Security)

• Тренды развития рынка защиты веба

• Безопасная разработка

Для кого:

CISO

ИБ-специалисты

ИТ-специалисты

DevOps

Приготовьтесь к морю полезной информации, лучшим практикам и встрече с ведущими экспертами отрасли. Мы расставим все точки над «и».

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

 Ссылка на регистрацию 

До встречи!

Генерация команд для создания сервера

Теперь при заказе конфига можно тут же сгенерировать команду для инструмента автоматизации, — Terraform, cURL или twc-cli. Вот краткий обзор каждого из них:

• Terraform. Помогает быстро разворачивать серверы, сети и управляемые сервисы в облаке.

• сURL. Утилита для управления ресурсами в облаке через API с помощью HTTP-запросов.

• twc-cli. Через терминал создает виртуалки, настраивает сети, кластеры и базы данных.

Чтобы сгенерировать команду, просто нажмите на кнопку рядом с «Заказать» → выберите один из способов автоматизации → скопируйте и вставьте команду в терминал или в файл.

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

Автоматизировать управление сервером →

Как мы сокращали количество запросов по фичам в API

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

Одна из основных сущностей в коде — это BotUser. То есть пользователь, который появился в приложении (зашёл хотя бы раз), имеет имя и Telegram ID

За ~полгода проекта у нас добавилось много фич, привязанных к пользователю. Практически все сопоставляются 1 к 1 по ключу User ID. Например, квизы, бонусные дни, купленные страницы, купленный карточки апгрейдов, тариф и т.д.

Раньше для каждой новой фичи мы добавляли новый запрос в API с фронтенда. И вот мы заметили, что на каждый заход пользователя стало уходить >10 запросов в API ⚠️.

Примерно вот так:

GET /users/user
// Response
{
  "tgUsername": ...,
  "tgId": ...,
  ...
}

GET /users/features/quizzes/completed
// Response
{
  "completedQuizzes": ...,
}
   
GET /users/features/pages/bought
// Response
{
  "boughtPages": ...,
}
   
GET /users/features/rates/rate
// Response
{
  "userRate": ...,
}

При этом, на каждый запрос мы проверяли авторизацию. В Telegram это делается с помощью хеша от Telegram + проверка подписи токеном бота

Следовательно, на каждый запрос мы делали JOIN пользователя, брали бота (сущность Bot) из кэша и мэтчили подпись (+ логгировали). Это лишняя нагрузка

Сейчас подсобрали все фичи в один запрос. Теперь, на каждый заход пользователя получается только один GET /app/account/data, который возвращает данные пользователя вместе с данными фичей:

GET /app/account/data

// Response
{
  ...
  "user": ...,
  "completedQuizzes": ...,
  "boughtPages": ...,
  "currentRate": ...,
  ...
}

За одно перепроверили, что:

• не подгружаем связанные сущности, где не нужно (one-to-one, one-to-many);

• если подгружаем сущности, всегда делаем это одним JOIN'ом (а не бегаем по 2-3 раза в БД, как любит делать Hibernate);

• берём общие часто запрашиваемые данные из кэшей.

Это позволило снизить нагрузку на сервер и БД. К посту прикрепляю график загрузки части наших серверов по CPU до и после оптимизации.

---

Если вам понравился пост или оказался полезным, поставьте, пожалуйста лайк ❤️. Это мотивирует делиться опытом из разработки. И, как полагается, у меня есть Telegram-канал, в котором я рассказываю про разработку, развитие SaaS-сервисов и управление IT проектами.

Коллеги, добрый день!

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

По ссылке ниже мы предлагаем пройти небольшой опрос, который займет не более 10 минут.
https://t.me/wmx_xdrbot

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

Joomla Web Services Collection For Postman

Разработчикам мобильных и WEB-приложений (и не только) весьма и весьма пригодится готовая коллекция для Postman. В коллекцию добавлены endpoint для REST API Joomla, с параметрами и примерами запросов.

Коллекция составлена трудами французского Joomla-разработчика Alexandre J-S William ELISÉ.

Смотреть коллекцию

Чат русскоязычного Joomla-сообщества

Добавляем подписку с Telegram Stars в свой апп

Я очень радовался 14.08.2024 из‑за выхода очередного релиза Телеграм, в котором они анонсировали подписки за звезды, потому что это сильно облегчало мое взаимодействие с клиентами: они один раз подписываются и далее не имеют проблем с повторными платежами, вместо этого звезды тихонько списываются у них с счетов. В этом посте я расскажу, как прикрутил подписку в звездах к своей Telegram Mini App (TMA).

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

Свои подписки можно посмотреть у себя в профиле. Это выглядит так:

https://storage.googleapis.com/memes-repo/tutorial/100000998111.png

Отменить подписку можно, если вы зайдете в ее детали.

https://storage.googleapis.com/memes-repo/tutorial/1000009980.png

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

1. Создать счет на подписку.

2. Подтвердить оплату.

3. Принять первое и последующие сообщения об оплате.

### Создание счета

Для создания счета вызываем метод createInvoiceLink.

    def create_invoice(admin_chat_id: str, 
                       channel_id: str, 
                       title: str, 
                       description: str,
                       tariff_id: int, 
                       tariff_price: int,
                       ) -> dict:

        data = {
            "chat_id": admin_chat_id,
            "title": title,
            "description": description,
            "payload": json.dumps({"t": tariff_id}), 
            "provider_token": "",  # Empty
            "currency": "XTR", # required
            "prices": [{'amount': tariff_price, 'label': title}],
            "subscription_period": 2592000,
        }

        r = requests.post(f"{TG_API_URL}{TG_OP_SEND_INVOICE}", json=data)

Вещи, на которые обращаем внимание:

1. provider_token пустая строка

2. currency обязательно строка XTR

3. subscription_period обязательно 2 592 000

4. prices содержит только один элемент

### Подтверждение оплаты

Для получения подтверждения оплаты счета вам нужно добавить в ваш webhook (allowed_updates) подписку на pre_checkout_query. После этого вы начнете получать update c данным полем и структурой.

Когда вы получаете такой апдейт, вам нужно отреагировать на него в течение 10 секунд: принимаете или отклоняете (например, если этот счет уже был оплачен и другие краевые условия).

Данная структура также позволяет вам понять, что было оплачено в рамках счета, путем чтения поля payload (которое было записано при создании счета).

        pre_checkout_data: PreCheckoutData = {
            "id": packet["pre_checkout_query"]["id"],
            "currency": packet["pre_checkout_query"]["currency"],
            "total_amount": packet["pre_checkout_query"]["total_amount"],
            "invoice_payload": json.loads(packet["pre_checkout_query"]["invoice_payload"])
        }

Для подтверждения или отклонения оплаты счета используйте метод answerPreCheckoutQuery.

### Принять сообщения об оплате

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

Обратите внимание! В структуре SuccessfulPayment есть параметр is_first_recurring, и я думал, что он True для первого платежа подписки и False для последующих, но! в последующих его просто нет (это допустимо, так как это необязательный параметр).

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

P.S. Вы всегда можете обновлять срок подписки при получении данного сообщения, читая поле subscription_expiration_date. Если successful_payment перестал приходить, то и подписка не обновится.

Ваш Дима из TG Defender, защита вашего Telegram канала от наплыва ботов на стиле.

Привет,Хабровчане ! Неожиданно решился на создание этой публикации – пусть она окажется полезной для кого-то из вас. Представьте ситуацию: рабочий день позади, включаем компьютер, запускаем музыкальное сопровождение и... прямо в кресле дивана нас уже сморит Морфей. Пробуждение же наполняет осознанием неразрешимой дилеммы – выключить ПК или переключить трек? Особенно когда репертуар оставляет желать лучшего!

Вот и приходится преодолевать себя, чтобы добраться до компьютера.

Так вот, в качестве решения этой проблемы разрабатываю приложение для Android с небольшим сервером на PC (начало только под Windows).

Основной фишкой станет регулировка яркости экранов, удаленное отключение ПК, переключение треков в плеере.

Телефонное приложение будет максимально чистым: без рекламы, подписок или дополнительных платежей.

Я – инженер(технарь), а не профессиональный программист, так что обещаю уделять больше внимания техническим моментам .

Все будет сделано в меру моих умений и возможностей. Благодарен за внимание! По мере продвижения работы буду дополнять этот пост новыми деталями.

А какого функционала не хватает вам ?

Сделал ещё несколько дэмок . 2 приложения на kivymd (python3) связь с сервером http запросами ,но вес приложения уменьшить не удалось . Попробовал на flutter спасибо Гуглу ,ии и другу разработчику ,связь. с сервером с помощью протокола mqtt.

$hyoo_lingua - удобный интерфейс перевода текстов.

В отличие от оригинального google translate, $hyoo_lingua не пытается транслитерировать английский текст при вводе в русское поле. В отличие от yandex translate, он не меняет языки сам как попало. В $hyoo_lingua ваш родной язык всегда слева, а чужой - справа, что очень удобно. Особенно, когда переводишь текст в обе стороны, чтобы убедиться в корректности перевода.

Ну и в отличие от обоих он не пытается переводить на лету текст в процессе ввода, вызывая мельтешение, изменение размера текста и исчерпание лимитов перевода, а ждёт сабмита (поддерживается и ctrl+enter).

Раньше он юзал нейронки с huggingface.co, но качество перевода было низким, а потом там закрутили гайки и всё сломалось.

Теперь используется гугловый движок через балансировку по шести бесплатным API с rapidapi.com, что даёт суммарный лимит в 10К переводов в месяц.

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

Программно же, в экосистеме MAM сейчас доступны следующие модули:

$mol_lang_iso639 - словарь всех 2-буквенных кодов языков и их названия на английском.

$mol_locale_select - компонент выбора языка.

$hyoo_lingua_translate( lang, text ) - перевод любого текста на заданный язык, используя веб-сервисы перевода.

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

Следите за остальными новостями из нашей экосистемы на канале @mol_news.

Теперь всем API-токенам можно ограничивать права. На уровне всех проектов сразу, или каких-то конкретных.

Можно выдавать права только на просмотр, на полное управление или полностью закрывать доступ к сервисам.

Это доступно как администраторам, так и доп пользователям — с учетом их собственных прав. При этом админ будет видеть, кто выпустил конкретный токен. А при блокировке доп пользователя автоматически удалятся и все выпущенные им токены.

Выпустить токен с ограничениями → 

Как в нативе: эти Web API поднимут ваше веб-приложение в стратосферу

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

- Web Share API – для обмена ссылками, текстом и файлами с другими приложениями на устройстве. К примеру, удобно отправить чек об оплате в мессенджере, не покидая банковское приложение. 

- Contact Picker API позволяет делиться контактами из своего списка. Можно использовать для перевода по номеру телефона. Не нужно вводить цифры вручную – поле автоматически заполнится контактом из телефонной книги. 

- Media Capture and Streams API в нашем случае позволяет отсканировать QR-код с помощью камеры устройства. Нажимаешь на “Сканировать QR” – открывается окно с камерой, она считывает код и переводит пользователя в дерево платежей.

- Web OTP API открывает возможность автоматически вставлять код из смс. Например, для подтверждения оплаты на телефон приходит сообщение. Внизу экрана появляется модальное окно с подтверждением вставки. И после нажатия на “Разрешить” код отображается в поле ввода.

Подробнее про этот опыт использования Web API мы рассказали в отдельной статье. Что вы думаете о Web API, какие используете? Расскажите в комментариях, будем взаимно полезны друг другу.  

Как в Авито устроено API-тестирование на Go?

В этом видео Глеб Дмитриев, инженер из команды Marketplace, рассказывает о проблемах, с которыми мы сталкивались на этапе выбора фреймворка для тестирования, и показывает, как работает наш собственный фреймворк на основе Testify.

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

Ранее Александр Трифанов, техлид Авито, рассказал о нашем подходе к сканированию данных в API.

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

В прошлом посте мы рассказали о нашем ПО Capsule для считывания, анализа и записи физиологических сигналов мозга и тела. Сегодня — про особенности интерфейса и API Neiry, которые нас радуют больше всего.

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

Мы храним необработанные мультимодальные данные в формате HDF5. С готовыми метриками можно работать в понятном для продукта виде. Когнитивная нагрузка со шкалой от 0 до 100 — пожалуйста, уровень усталости или расслабления в виде численного значения — запросто.

Нужно проверить гипотезу или разработать алгоритм «с нуля»? Потоковые сырые данные до фильтрации вам в помощь! Не хотите возиться с фильтрацией сигнала? Нет проблем, вот те же данные напрямую с АЦП, но после применения валидированных фильтров.

На устройстве небольшое количество электродов для снятия ЭЭГ, но мы постарались разместить их максимально разумно: два в затылочной области, два в височных, а референтный электрод и датчик ФПГ — на лбу.

Подробности расскажем и покажем на хакатоне BCI Hack Moscow 20–22 сентября. С помощью Neiry Headband Pro и API Neiry соберем игру на Unity, будем управлять устройствами умного дома, техникой и устроим брейн-ралли! Возможно даже покажем «Нейробуханку». Приходите, будет интересно.

Привет! На связи команда Neiry Tech, мы занимаемся разработкой BCI-устройств и алгоритмов для использования с ними. Расскажем про ПО Capsule, считывающее и записывающее мозговую активность, и другие физиологические сигналы пользователя. И Capsule API — он помогает нам строить на основе классифицированных метрик и индексов итоговые приложения).

По сути Capsule — библиотека для десктопных и мобильных платформ с собственным графическим интерфейсом. Для быстродействия написали её на C++. Для Capsule API выбрали C.

Для вывода в API на разных платформах иногда пишем нативный код на Android или iOS, ну и обертку на C, чтобы API мог использовать широкий спектр разработчиков — за родным ноутом и в лаборатории.

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

Головной боли добавляют особенности различных платформ — с плавающими задержками протокола BLE, или с реализацией вроде бы базовых вещей. Мы как-то обнаружили, что библиотека, занимающаяся быстрым преобразованием Фурье, нагружала новенькие Apple Silicon на 30%.

Сейчас Capsule и API позволяют работать с данными ЭЭГ и ФПГ на высоком для не лабораторного устройства уровне. Смотрим, радуемся и гордимся.

Хотите поработать с этими данными и нашим API? Присоединяйтесь к хакатону BCI Hack Moscow, регистрация до 15 сентября.