API *

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

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

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

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

О том, как найти баги в любом API за 5 минут и чем поможет Swagger Spec First + Schemathesis там, где генерация API контрактов из кода не предусмотрена или невозможна.

Как спарсить исторические данные 2017-2021 годов с Google Scholar и сохранить их в CSV, SQLite используя Python и SerpApi.

Привет, хабровчане!

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

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

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

Началось все как обычно: одним прекрасным утром ко мне подошел менеджер и спросил, не хочу ли я заняться одной интересной задачей. К тому времени у меня уже был опыт организации перфоманс-тестирования и вообще улучшения процессов в команде, так что я, конечно, согласился. А когда он объяснил, чем именно предстоит заняться, глаза у меня загорелись!  Только подумайте: построить HA тестирование целой подсистемы —  есть где развернуться, проявить изобретательность!

Привет! Я Алексей, Java-разработчик. В статье поделился опытом внедрения подхода Contract-First в backend. 

Под катом подробности:

— что такое Code-First и зачем переходить на Contract-First,

— как перестать писать API-объекты руками и сэкономить 12 человеко-недель в спринт,

— как поддерживать однотипный код и API, если у вас 100+ микросервисов и 60 бэкендеров.

К старту флагманского курса по Data Science делимся туториалом по библиотеке Terality, которая сильно облегчит работу с действительно большими наборами данных даже на маломощных машинах. За подробностями приглашаем под кат.

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

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

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

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

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

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

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

В конце декабря 2019 года передо мной стояла задача разработки агрегатора культурных событий. Решение предполагало создание 2х инструментов: для добавления мероприятий на сайте, для сбора и предъявления актуальных данных о планируемых событиях.

В обзоре я кратко опишу основные этапы разработки, сложности реализации проекта.

Интеграция систем в сложном IT-ландшафте всегда вызывает боль, мы уменьшаем нашу боль посредством абстрактного слоя - Enterprise API.

Enterprise API – это набор API, которые покрывают основные бизнес домены и являются decoupling слоем между системами.

Эта статья является текстовой версией доклада c конференции ArchDays'21, a доклад в свою очередь базируется на опыте построения слоя Enterprise API для Deutsche Telekom.

И так, что нас ждет в статье:

Зачем нам нужен Enterprise API?

Как мы в Deutsche Telekom IT Solutions построили процессы управления Enterprise API?

Какие архитектурные и организационные решения были приняты?

И конечно, большая часть статьи будет посвящена нашему CI/CD Pipeline, который автоматизирует основные этапы жизненного цикла API.

Привет! Продолжаем делиться интересными выступлениями с митапов наших гильдий. Вслед за фронтендерами приходит очередь архитекторов. Митап 9 декабря открыл наш коллега Дмитрий Зыков с рассказом об автоматизации управления. Дмитрий Бардин из Croc Code продолжил выступлением об оценке модернизации. И завершил основную часть Егор Слесаренко из Leroy Merlin, поделившись опытом перестройки магазинов в локдаун с помощью composable architecture. Основные тезисы всех выступлений — в этом посте.

2 дня унижения в чатах, пачка Ново-Пассита, но я выдержал это испытание и узнал, что до сих пор думают о фронтенд разработчиках «другие» разработчики. Будет интересно.

Всем привет, меня зовут Денис. Я хотел бы рассказать о своем опыте разработки навыка для голосового помощника "Маруся".

«Маруся» — голосовой помощник, разработанный в компании Mail.ru Group. Запущен 17 июня 2019 года в тестовом режиме.

Пункт 1: ознакомление с API Маруси.

С полной схемой взаимодействия с Марусей можно ознакомиться в документации. Здесь я опишу основные моменты:

Фаза вызова скилла строится по следующей схеме.

В предыдущих статьях мы подробно разобрали работу сериалайзера на основе классов BaseSerializer и Serializer, и теперь мы можем перейти к классу-наследнику ModelSerializer.

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

• автоматическое создание полей сериалайзера на основе данных о корреспондирующих полях модели;
• автоматическое включение в поля сериалайзера тех же валидаторов, которые есть в полях модели, а также при определённых условиях метавалидаторов;
• заранее определённые методы create и update.

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

Несколько месяцев назад на моем пути возник GraphQL.

Это произошло, когда я присоединилась к одному из наших проектов, где был не только привычный REST, но и GraphQL API. Это было моё первое знакомство с ним. Я понятия не имела, что он собой представляет, в чем его особенности, а самое главное для меня, как QA инженера – не знала, как его тестировать. 

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

Привет! Недавно мы провели небольшой митап для фронтендеров, куда пригласили троих интересных спикеров. Наш коллега Игорь Борзунов рассказал о том, как решать проблемы с плохим качеством изображений. Даниил Водолазкин из X5Tech поведал о неочевидных сложностях работы с GraphQL. И завершил программу Георгий Конюшков из «Леруа Мерлен» с темой «Time to market: микрофронтенды». В этом посте мы свели основные тезисы всех трех докладов.

16 декабря сего года, команда разработчиков ReactOS, спустя долгое время после последнего релиза (с последнего прошло почти полтора года) выпустила новую версию под номером 0.4.14. Это все еще альфа-версия.

В данной статье мы рассмотрим основные новшества как со стороны разработчиков, так и со стороны сообщества.

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

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

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

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