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

Прошлой части мы спарсили 500+ видов физических упражнений, сохранили в БД и написали логику поиска по ним. Теперь настало время поговорить о второй составляющей чат-бота - дневник питания (он же калькулятор калорий). В данной статье мы научимся получать список продуктов питания из цельной строки наподобие "3 вареных яйца, 20 грамм майонеза и 1 помидор" посредством API одного из популярных сервисов. А далее 'вытянем' подробную информацию по каждой позиции: калории, белки, жиры, углеводы и подробный список из 150+ нутриентов по каждой позиции (сахар, соль, витамины, минералы и т.д.)

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

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

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

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

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

Отправка HTTP-запросов, создание тестов, организация запросов в коллекции, работа с переменными - все это лишь часть функциональности Postman, которая облегчает процесс тестирования и повышает его эффективность. Если вы только начинаете свой путь в изучении этого инструмента, не волнуйтесь! Этот гайд поможет вам разобраться с базовыми принципами работы с Postman и покажет, как сделать ваш процесс тестирования API гораздо более эффективным и приятным.

Готовы начать? Давайте вместе погрузимся в увлекательный мир тестирования API с Postman!

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

План статьи:

— Проблематика черного ящика и почему его вообще нужно вскрывать.
— Варианты решения проблемы.
— Подробно про мок-сервер, как один из вариантов решения проблемы: зачем нужен, в чём польза и как выбрать между готовыми и самописными решениям.
— Как написать свой мок-сервер.
— Посмотрим как он работает на реальной задаче. 
— Закрепляем материал в блоке «Польза мок-сервера».

Этот текст - перевод статьи из нового портала документации для разработчиков Joomla, раздел "Основные концепции". Ранее уже был опубликован перевод раздела, описывающего принципы Dependency Injection Containers в Joomla 4.

В тексте даны примеры PHP-кода по работе с Joomla 4 REST API. Примеры даны как с использованием API Joomla (HttpFactory), так и для non-Joomla сайтов - на чистом cURL.

Как измерить покрытие автотестами? Данный вопрос всегда вызывает жаркие дискуссии в рядах тестировщиков. Измерять покрытие становится сложнее, когда мы движемся вверх по пирамиде тестирования и уровень наших тестов растет. Как здорово на уровне Unit тестов, там отлично показывается сколько строк кода покрыто, процент и т.д. Вот если бы подобный отчет можно было сделать для end-to-end тестов или UI, то сразу было бы понятно реальное тестовое покрытие и каких тестов не хватает. К счастью, есть такой инструмент, который позволяет строить подробный отчет по покрытию Python сервисов.

В новом уроке мы с вами поговорим о настройке хуков и напишем свой первый обработчик команд.

В первом уроке я вам рассказывал что такое хуки, давайте повторим:

Hooks (Хуки) — это способ общения с программой, по средствам отправки данных от сервера — клиенту. То есть при определённых изменениях в программе, сервер (приложение) будет отправлять данные на указанный URL скрипта клиента.

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

Для регистрации хука нужно выполнить 2 правила:

Прежде, чем я начну своё повествование о процессе, хочу отметить, что выступаю не в качестве специалиста в области сервисов Amazon, а в качестве разработчика, которому пришлось в моменте столкнуться с технологией, и к сожалению, некогда было детально разбираться c довольно громоздкой панелью управления. Гайд подойдёт для тех, кто ещё не сталкивался с AWS, но хотел бы попробовать его для своих личных проектов, либо обучиться самим технологиям. Мы рассмотрим с вами создание простого пользователя IAM, необходимую конфигурацию для работы, и простой пример работы с библиотекой Boto3.

Введение в состав SDK UI-компонентов обогащает и так не самую простую конструкцию из клиент-серверного API и клиентской библиотеки дополнительным измерением: теперь с вашим API взаимодействуют одновременно и разработчики (которые написали код приложения), и пользователи (которые используют приложение). Хотя это изменение на первый взгляд может показаться не очень значительным, с точки зрения дизайна API добавление конечного пользователя — огромная проблема, которая требует на порядок более глубокой и качественной проработки дизайна программных интерфейсов по сравнению с «чистым» клиент-серверным API. Попробуем объяснить, почему так происходит, на конкретном примере.

Статья-туториал от ведущего разработчика "ITQ-Group" Александра Берегового, в которой мы рассмотрим применение обобщенного подхода при разработке WEB API.

Привет, меня зовут Александр Беляков, я инженер по тестированию Альфа-Банка. В 2021 году пришёл в IT из медицины и четыре месяца стажировался в Альфа-банке. Хотел бы рассказать о внедрении автотестов REST API с JSON-schema на проекте, на котором я стажировался с нуля и без опыта: с чего начать, как подготовиться, что необходимо знать и как быть с ошибками. Статья будет полезна начинающим тестировщикам, как я, которые только хотят начать работать в тестировании. Но и начинающим лидам я скромно рекомендую уделить статье время. У вас уже достаточно опыта и вы всё знаете, но, возможно, не помните, каково это ничего не знать.

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

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

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

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

Ручное взаимодействие может быть удобно, если количество сделок относительно невелико. Например, если я хочу однажды купить Bitcoin (или акции Microsoft) и держать их на долгий срок, оптимальный вариант - воспользоваться веб-интерфейсом или мобильным приложением.

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

Многие криптобиржи предлагают API-доступ к своим сервисам. По моему опыту, примерно 110 из 220 активных в настоящее время бирж (согласно coinmarketcap) в том или ином виде поддерживают публичные API. То есть вы можете автоматизировать торговлю на половине имеющихся криптобирж (но не на всех).

Аббревиатура «SDK» («Software Development Kit»), как и многие из обсуждавшихся ранее терминов, не имеет конкретного значения. Считается, что SDK отличается от API тем, что помимо программных интерфейсов содержит и готовые инструменты для работы с ними. Определение это, конечно, лукавое, поскольку почти любая технология сегодня идёт в комплекте со своим набором инструментов.

Тем не менее, у термина SDK есть и более узкое значение, в котором он часто используется: это клиентская библиотека, которая предоставляет высокоуровневый (обычно, нативный) интерфейс для работы с некоторой нижележащей платформой (и в частности с клиент-серверным API). Чаще всего речь идёт о библиотеках для мобильных ОС или веб браузеров, которые работают поверх HTTP API сервиса общего назначения.

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

Задача выглядела несложной - из Binance API забираем последние сделки и шлём в Телеграм - работы на пару часов. Но на практике это превратилось в квест в котором 90% времени ушло на изучение особенностей работы с Binance API, их довольно странную логику и жесткие лимиты.

В итоге, родился минималистичный скрипт на 40 строк кода и новый интересный проект о котором упомяну в конце статьи. Скрипт можно запустить на своем компьютере и все сделки на вашем счете превратятся в уведомления типа BUY BTCUSDT volume: 0.01 или CLOSE BTCUSDT profit: 10$

У меня есть несколько групп в ВК, в которые нужно периодически публиковать посты. В целом мое желание можно описать фразой «А когда мне это делать, если я все время не хочу». Мотивация в моем случае это лень. Я не являюсь разработчиком, но решил набросать скрипт, который будет публиковать посты.

Всем привет! Продолжаем наш цикл статей о внедрении подхода Design API First на проектах нашей компании. Ранее мы рассмотрели использование этого подхода, описали плюсы и минусы, узнали, как на практике выглядит проектирование API на примере сервиса аутентификации. Сегодня расскажем о том, как мы встраиваем Design API First в наш конвейер разработки, подробно остановимся на инструментах, помогающих с технической точки зрения организовать этот процесс. Объясним, как реагировать на изменения требований и обеспечивать версионность, а также что использовать для мокирования данных. Рассмотрим различные варианты применения: для нового проекта, для существующего проекта (где изначально был Code First).

4 часть: Как генерировать модели интерфейсов на основе спецификации на стороне frontend-приложений

5 часть: Design API First. Кодогенерация Roslyn

Вот несколько неловкое предположение, которое я сделал относительно setState, когда начал изучать Flutter почти 4 года назад.

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

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

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

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

Это главы 39 и 40 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.