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

Банкам не хватает просмотрового API

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

Я каждый месяц выбираю категории кешбека и переключаю карты в приложениях. Например, вкусвилл — в этом месяце он у меня на ВТБ (категория супермаркеты). Средний заказ в ВВ — 3000 рублей и важно чтобы на карте было не меньше, потому что жена заказывает без предупреждения:)

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

Смотреть за это глазами очень неудобно и у меня глаза ленивые, забывчивые и вообще мне доверять что-то помнить нельзя. Поэтому у нас с женой частое сообщение — "Антон, пополни карту для ВВ".

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

В комментах к посту в моем тг-канале кинули ссылку на новость от ЦБ, что 2026 у крупных банков должно будет быть API, а потом у всех МФО. Жду этого, возможно, даже больше чем полностью электронные документы для езды за рулем (права, доки на авто).

Всем привет!

Я уже писал о пользе стандартизации на примере формата данных для сохранения информации о сборке - cyclonedx. А недавно в посте про работу с исключениями упоминал библиотечку для возврата ошибок в API - jdoctor.

Так вот - стандартизация добралась и сюда)

Во-первых, как выяснилось - уже с 2016 года есть стандарт "Problem Details for HTTP APIs"
Во-вторых - в Spring Boot 3, т.е. с 2021 года, появилась его имплементация. Вот неплохое описание у baeldung
Если вкратце - ответ при ошибке будет иметь стандартизированный вид похожий на такой:
{
"type": "about:blank",
"title": "Bad Request",
"status": 400,
"detail": "Invalid request content",
"instance": "/sales/calculate"
}

Библиотеки, решающие подобную задачу в Java, уже были:

1. уже упомянутый jdoctor

2. error-handling-spring-boot-starter

   Но думаю, что именно данное решение - от Spring, да еще по стандарту - имеет шансы популяризовать данную практику.

Что еще хочется отметить:

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

2. еще в 2018 году в Сбере формат ответа для REST был стандартизирован. Но, увы, формат отличается от RFC, а область применения ограничена взаимодействием с фронтом.

МТС представила платформу для бесшовной интеграции сервисов. Это собственная разработка компании — Интеграционная платформа (Integration Platform), которая позволяет бесшовно интегрировать сервисы в экосистему и обеспечивать их взаимодействие друг с другом.

На первом этапе платформа объединяет все API экосистемы в единый стек и позволят строить сложные интеграционные сценарии запуска сервисов, в том числе без привлечения разработчиков, через citizen developers — специалистов, которые создают сложные IT‑продукты, не имея глубинных знаний в области программирования.

Проект Integration Platform поддерживает широкий спектр индустриальных протоколов и стандартов, использует встроенные инструменты Low/No‑code и технологии искусственного интеллекта.

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

«Раньше создание новых продуктов требовало разработки новых API, команды искали актуальную документацию на существующие API, решения дублировались, подписание требовало согласований и обсуждений, был необходим единый реестр c полной документацией и понятным UX для подключения и публикации. Интеграционная платформа решила эту задачу. Это разработка МТС превосходит зарубежные аналоги по надежности, производительности и масштабируемости», — пояснил первый вице‑президент по технологиям МТС Павел Воронин.

Хакер под ником emo выложил в свободный доступ (при оплате) базу данных пользователей сервиса управления проектами Trello (trello.com).

Известно, что информация хакером получена с помощью запросов к официальному API сервиса, а не в результате взлома.

ИБ-исследователи выяснили, что хакер использовал открытый API Trello для связывания почтовых адресов с профилями пользователей. В итоге хакер подготовил список из 500 млн адресов электронной почты и направил их через открытый API, чтобы определить, связаны ли они с аккаунтами Trello. Злоумышленник заявил, что закупил прокси для ротации соединений и запросов через API непрерывно. После этой атаки API Trello был усилен и стал требовать аутентификации, хотя он по-прежнему доступен любому, кто создаст бесплатный аккаунт.

«У Trello был открытый API-эндпоинт, который позволял любому неаутентифицированному пользователю связать адрес электронной почты с аккаунтом Trello, — пишет emo. — Изначально я собирался отправлять эндпоинту только письма из баз данных com (OGU, RF, Breached и так далее), но потом решил продолжать [проверять] email'ы, пока не надоест».

В опубликованной хакером базе данных содержится 15 115 945 строк, включая:

• адрес эл. почты;

• имя/фамилия;

• логин;

• ссылку на аватар.

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

Чем занимаются Go-специалисты в Островке?

У нас 10 команд, использующих Go, как основной язык. Для примера возьмём команду интеграций с поставщиками отелей. Вот что делают разработчики в этой команде:

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

• Поддерживают и правят существующие интеграции. Протокол сменился, или (куда реже) коды ошибок стали другие — всё надо держать в актуальном состоянии и при необходимости править.

• Уменьшают технический долг. Это задачи, связанные с библиотеками и рефакторингом. Есть правило — на одну итерацию должно приходиться 75% продуктовых задач и 25% техдолговых.

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

• Обмениваются знаниями внутри компании. В Островке есть активности, напрямую не связанные с работой. Например, канал в слаке #dev-golang и еженедельный книжный клуб.

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

Приглашаю на вебинар компании Вебмониторэкс 28 июня в 12:00, посвященный предотвращению утечек API и новым функциям в продукте «ПроAPI Структура».

Ведущие вебинара - Антон Будник, инженер продаж и Сергей Одинцов, системный аналитик Вебмониторэкс.

На этом вебинаре раскроем темы:

О предотвращении утечек API:

• Основные методы взлома API

• Описание рисков утечки данных через API: ключевой вопрос кибербезопасности

• Изучение последствий взлома API

• Разбор крупных инцидентов утечек данных через API

• Методы защиты API с помощью компонента «Обнаружение утечек AP» продукта «ПроAPI Структура» платформы «Вебмониторэкс»

О новых функциях продукта «ПроAPI Структура»:

• Настройка чувствительности определения роута на трафике

• Очистка построенной структуры API

• Создание правил для параметров роута

Кому полезно:

• Специалистам, участвующим в разработке критичных для бизнеса веб-приложений

• Руководителям подразделений по информационной безопасности- Специалистам Application Security Почему полезно:

• Увидите пример реализации борьбы с утечками секретов и токенов на платформе «Вебмониторэкс»

• Увидите новые функции защиты API на платформе «Вебмониторэкс»

Регистрируйтесь по ссылке

Скорее подписывайся на специальный Telegram-канал, в котором команда Вебмониторэкс рассказывает все об API Security, Web Security, трендовых уязвимостях и публикует анонсы об изменениях в продуктах.

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

Приглашаю на вебинар 30 мая в 12:00, посвященный превентивной защите REST API.

Ведущие вебинара — Вадим Шепелев, инженер по информационной безопасности Вебмониторэкс и Лев Палей, CISO Вебмониторэкс.

О чем расскажем на вебинаре:

• Польза от спецификации API и как её собрать на основании трафика

• Какие типы уязвимостей это позволит обнаружить

• Как уменьшить поверхность атаки при помощи «ПроAPI Защита»

Регистрируйтесь по ссылке.

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

Компания Вебмониторэкс приглашает на вебинар 30 мая в 12:00, посвященный превентивной защите REST API.

Ведущие вебинара — Вадим Шепелев, инженер по информационной безопасности Вебмониторэкс и Лев Палей, CISO Вебмониторэкс.

О чем расскажем на вебинаре:

• Польза от спецификации API и как её собрать на основании трафика

• Какие типы уязвимостей это позволит обнаружить

• Как уменьшить поверхность атаки при помощи «ПроAPI Защита»

Кому полезно:

• Специалистам, участвующим в разработке критичных для бизнеса веб-приложений

• Руководителям подразделений по информационной безопасности

• Специалистам Application Security

Почему полезно:

• Актуальная проблема защиты REST API обусловлена участившимися атаками на веб-ресурсы российских компаний

Регистрируйтесь по ссылке.

Google сообщила разработчикам, что начинает взимать плату за использование Gemini API. С 30 мая 2024 года платным становится доступ к Gemini 1.5 Pro, с 14 мая плата будет взиматься за использование Gemini 1.0 Pro.

Вместе с этим компания ещё раз напомнила про более доступный тариф Gemini 1.5 Pro. В рассылке для разработчиков подчёркивается, что платным становится только доступ к языковой модели через API, в Google AI Studio с нейросетями можно будет работать бесплатно.

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

Компания Вебмониторэкс ответит на этот и другие вопросы на своем вебинаре 16 мая.
Теорию подкрепит практический кейс заказчика.

 О чем расскажем на вебинаре:

- На что обратить внимание при обеспечении безопасности API в современных условиях. - Изменения в инфраструктуре. Что дальше?
- Защита и управление API. Почему это важно.
- Подходы по защите API. От зрелости к эффективности: Знать. Защищать. Не допускать. - Реализация на платформе «Вебмониторэкс»: компоненты для защиты и управления API.  

Ведущий вебинара — Лев Палей, CISO Вебмониторэкс. Специальный гость — Кирилл Ильин, CISO «СберАвто». Он честно и открыто расскажет о задачах, практике и результатах защиты API в своей компании.  

Кому полезно:

- Специалистам, участвующим в разработке критичных для бизнеса веб-приложений
- Руководителям подразделений по информационной безопасности
- Специалистам Application Security  

Почему полезно:

- Узнаете о современной концепции управления API
- Увидите пример ее реализации на платформе «Вебмониторэкс»
- Услышите от CISO об успешном опыте защиты и управления API на примере компании «СберАвто»  

Регистрируйтесь по ссылке.

Вебинар про защиту API 16 мая в 12:00

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

Обо всём этом они рассказали в своей статье на Хабре. Рекомендую почитать.

Вебмониторэкс приглашает вас 17 апреля в 12:00 (мск) на вебинар, во время которого мы раскроем тему значимости обеспечения безопасности API в современных условиях.

Ведущие вебинара - Лев Палей, CISO и Сергей Одинцов, системный аналитик Вебмониторэкс.

Расскажем об изменении ландшафта угроз и отражении этих изменений в OWASP API Security.
Подробно рассмотрим обеспечение безопасности веб-приложений в наиболее атакуемых отраслях (телекоммуникационные компании и интернет платформы).
Покажем, как платформа «Вебмониторэкс» решает задачи по защите веб-приложений и API.

Почему полезно:
  - Узнаете о новых уязвимостях в OWASP API Security и вариантах их эксплуатации
  - Получите рекомендации по защите своих API
  - Увидите примеры, иллюстрирующие изменения OWASP API Security

Продолжительность вебинара 1 час 30 минут!
Регистрируйтесь на вебинар по ссылке.

Интересно, читают ли посты на Хабре. Вот сейчас и проверим — у нас две хорошие новости про YandexGPT.

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

Во-вторых, готовимся к запуску бета-тестирования новых возможностей Алисы на базе YandexGPT 2. Чтобы записаться в бета-тестеры, нужно отправить заявку на сайте.

Обновление библиотеки WT Amo CRM для Joomla v.1.2.0

Небольшая нативная PHP библиотека для создания интеграций Joomla и Amo CRM. Для разработчиков.

Что нового?

• Joomla 5 ready. Работа библиотеки успешно протестирована с Joomla 5.

• Удаление старого refresh token. В параметры плагина добавлена кнопка для удаления старого refresh-токен из базы данных.

• Языковые константы. Параметры плагина переделаны на использование языковых констант Joomla. Добавлена английская локализация.

Страница расширения GitHub

Telegram-канал Joomla сообщества

​​Как тестировать internal методы и классы в C# — InternalsVisibleToAttribute

Представьте, что вы разрабатываете библиотеку, которой будут пользоваться тысячи людей ?. Чтобы убедиться в стабильности — нужно всё хорошенько покрыть тестами. Все мы любим инкапсуляцию, верно (я надеюсь)? Поэтому мы не разрешаем использовать всё подряд из нашей сборки, а с умом используем модификаторы доступа и позволяем использовать только public классы и методы. 

В C#, есть 7 модификаторов доступа, основные: 

- private —  доступ только внутри текущего класса

- protected —  доступ внутри текущего и дочерних классов

- public — классы и методы доступны где угодно, также из сборок, использующих текущую

- internal — публичный API, внутри текущей сборки. Как public, но нет доступа из сборок использующих текущую

- остальные можно посмотреть тут

Но, C# — не JavaScript, и для тестов создаётся отдельная сборка, а internal методы в ней не доступны.

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

[assembly: InternalsVisibleToAttribute("YourProject.UnitTests")]

https://t.me/cherkashindev/127

Если кратко, то BFF - это когда для каждого типа клиентов (мобилки, веб, что-то еще...) есть свой API Gateway для оптимизации взаимодействия с конкретным типом клиентов.
Interesting: Если у нас есть UI (react/angular) и для него написан backend на nodejs - не факт, что это BFF ;)

https://full-stack.blog/api-gateway-bff-patterns.html

В новом подкасте Kotelov digital finance Александр Волков (возглавляет разработку API в Тинькофф Инвестициях) рассказал, как устроена работа в компании, с какими сложностями сталкивается крупный брокер в IT и каковы особенности API в современной торговле.

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

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

Казалось бы, при чём тут GraphQL?