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

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

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

В этот раз дело начиналось после закрытия методов audio в методе execute.

Я решил посмотреть, как получают музыку сайты, которые предоставляют возможность ее скачать. Меня заинтересовал сайт vrit.me.

Я залез во вкладку network и увидел интересный запрос:


То есть, можно подделать POST запрос к этому сайту, и использовать его, как API для музыки vk, что я сразу и реализовал:

Введение

Прошел тот период, когда каждая вторая статья на Habrahabr была посвящена написанию своего телеграмм-бота. Также прошел период времени, когда бота без трудностей можно было разместить на своем компьютере или хостинге в России. Еще полгода назад мой бот запускался просто на ноутбуке и не испытывал никаких проблем с подключением к API. Но сейчас, когда я задумался над тем, чтобы вернуть его в работу, я понял, что это будет не так легко. Не хотелось искать и настраивать прокси-сервер и тем более за рубежом. Также до этого я писал бота на Wolfram Language и не имел представления о том, как язык работает с прокси-серверами, так как до сих пор их не использовал. И тут появилась замечательная идея! Использовать Wolfram Cloud. В этой статье я хочу показать, как очень просто с регистрацией, но без смс можно запустить своего простого телеграм-бота, написанного на Wolfram Language. Из инструментов понадобится для этого только браузер.

Введение

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

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

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


Источник

Что делать?

nanoCAD Механика является вертикальным решением для машиностроительного проектирования, базирующимся на платформе nanoCAD Plus от российского разработчика – компании «Нанософт». Помимо богатого функционала для оформления конструкторской и технологической документации по ЕСКД и ЕСТД, программа располагает всеми основными инструментами цифрового проектирования.

Основной формат программы, DWG, самый популярный в мире инженерного проектирования, с 90-х годов прошлого века остается наиболее распространенным и в проектных компаниях нашей страны. Активное участие компании «Нанософт» в консорциуме Open Design Alliance (www.opendesign.com) позволяет обеспечить своевременную поддержку актуальных версий формата. Работа с DWG осуществляется напрямую – в отличие от многих приложений, работающих через импорт/экспорт этого формата.

Что же такое JSON API ?

Наверняка многие в курсе.

JSON — Текстовый формат обмена данными JSON
API — Программный интерфейс приложения API

Ключевые слова здесь: интерфейс обмена данными.

A, что же тогда JSON-RPC?

Как все начиналось:

Дело было вечером, делать было нечего… И я решил полазить по методам vk_api.

Наткнулся на интересный метод «execute».

Получилось отправить себе подарок:


А дальше мне пришла мысль, что если внутри этого метода можно вызывать методы, которые в официальном API вызывать нельзя, то наверное, можно вызвать метод audio.get.

Многие используют SoapUI для того, чтобы тестировать как сам API, так и приложения, обращающиеся к API. Довольно гибкий инструмент, позволяющий, например, экспортировать swagger файл API и сгенерировать Mock-service на его основе.

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



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

Часто в рамках проверки Pull Request, помимо, собственно, code review, возникает необходимость проделывать набор рутинных проверок. Некоторые проверки могут касаться оформления PR. Другие — проверять смежные условия, которые составляют основу процесса принятия изменений.
Если рутинные проверки не автоматизированы, человек может начать их забывать или обходить. Потому, что рутина — это скучно.

Visual Studio Team Services предлагает довольно удобную инфраструктуру для обработки Pull Request. Сюда входят настраиваемые политики merge builds, назначение ревьюеров, правила слияния принимаемых изменений. Все это дополненной удобной системой обсуждения и комментирования кода.

Мощнейшим инструментом расширения процесса Pull Request являются внешние подключаемые политики.

Об их создании и использовании и поговорим (и посмотрим код)

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

Изучил типизацию и тонкости спецификации OpenAPI, мне он понравился линейностью и возможностью описывать структуру и типы любой сущности на 1-3 уровня глубиной. Так как на тот момент уже был знаком с Laravel (до него юзал Yii2, CI но они были менее популярны), а так же с json-api форматом вывода данных — вся архитектура улеглась в голове связным графом.



Давайте перейдем к примерам.

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

Сегодня вы узнаете:

1. Как получать более одного ответа, пусть и колхозно
2. Как подключить к этому яндекс переводчик
3. И как писать пользователю что он сделал всё неправильно

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

Нам понадобятся:

1. Python
2. VK Api
3. Желание

Данная страница будет полезной для тех, кто решил взять заказ на парсер аудио-треков VK и резко понял, что ничего не понял.

В чем проблема

Знакомо?

https://m.vk.com/mp3/audio_api_unavailable.mp3?extra=AeL2rMfFyZzlD3HkyvfnvNvLx1KOqw5UDfuXCOTvttm4ts1OBJnYELvHyxvODI9fnM9YztD5A3iOyI14sxv2mNiXt3iTzdLInduXzvG9C2uVr3b5mezinfj2lJbpDhGYC25rDxbwsOPQmg1eu2Pbyxr3ntPowNLhDMrrDs8XnKu2sOuOyO8XzMf1otDmBtL6BNvllNjZx3aZuLHpq3aOBvvhzenJnZKTzKnMuwfKBI4TquffrtzKv2nymMyVDu1LzJnuwMLxwMm/BeTcserWlun3ExLVBG#AqSZntu

Если да — то вы пытались парсить мобильную версию сайта и успешно доставали ссылки. Неверные ссылки. Ссылки на 25-секундный голос, сообщающий что все идет не по плану.

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

Этой осенью Яндекс.Маркету исполняется 18 лет. Все это время развивается партнерский интерфейс Маркета. Если кратко, то это админка, с помощью которой магазины могут загружать каталоги, работать с ассортиментом, следить за статистикой, отвечать на отзывы и т.д. Специфика проекта такова, что приходится очень много взаимодействовать с различными бэкендами. При этом данные не всегда можно получить в одном месте, из одного конкретного бэкенда.

Уроки, которые мы вынесли из организации первого хакатона Naviaddress. И проекты, которые нам больше всего понравились.

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

Меня зовут Андрей Поляков, я руководитель группы документирования API и SDK в Яндексе. Сегодня я хотел бы поделиться с вами докладом, который я и моя коллега, старший разработчик документации Юлия Пивоварова, прочитали несколько недель назад на шестом Гипербатоне.


Светлана Каюшина, руководитель отдела документирования и локализации:
— Объемы программного кода в мире в последние годы сильно выросли, продолжают расти, и это влияет на работу технических писателей, которым приходит все больше задач на разработку программной документации и документирования кода. Мы не могли обойти стороной эту тему, посвятили ей целую секцию. Это три взаимосвязанных доклада, посвященных унификации разработки программной документации. Я приглашаю наших специалистов по документированию программных интерфейсов и библиотек Андрея Полякова и Юлию Пивоварову. Передаю им слово.

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

Что такое RESTful API?

Это миф.

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

Привет, Хабр! Меня зовут Николай Ижиков, я работаю в компании «Сбербанк Технологии» в команде развития Open Source решений. За плечами 15 лет коммерческой разработки на Java. Я коммитер Apache Ignite и контрибьютор Apache Kafka.

Под катом вас ожидает видео и текстовая версия моего доклада на Apache Ignite Meetup о том, как использовать Apache Ignite вместе с Apache Spark и какие возможности мы для этого реализовали.

Преамбула

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

GraphQL замечательный инструмент. Думаю, о его преимуществах уже знают и понимают многие. Тем не менее, есть некоторые нюансы, которые следует знать, когда вы строите свои API на основе GraphQL.

Например, GraphQL позволяет возвращать потребителю (пользователю или программе) запросившем данные только ту их часть, в которой этот потребитель заинтересован. Тем не менее, при построении сервера довольно легко совершить оплошность, которая приводит к тому, что внутри сервера (который может быть, в том числе, — распределенным) данные будут курсировать полными "пачками". В первую очередь это связано с тем, что "из коробки" сам GraphQL не предоставляет удобных инструментов для разбора входящего запроса, а те интерфейсы, которые в нем заложены недостаточно документированы.

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