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

Цель этой статьи - показать вам основы httr2. 

httr2 - переосмысленная реализация пакета httr, т.е. интерфейс для работы с HTTP запросами на языке R.

Из статьи вы узнаете, как создавать и отправлять HTTP-запросы и работать с полученными HTTP-ответами. httr2 разработан для точного сопоставления с базовым протоколом HTTP, который я объясню по мере продвижения. Для получения дополнительных сведений я также рекомендую ознакомиться со статьёй "An overview of HTTP" от MDN.

Начало этой истории тут:

https://habr.com/ru/post/492524/

 Вступление

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

Если выделить самый главный совет, то он будет следующий:

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

Каждый C++-разработчик хотя бы слышал о Boost – это, пожалуй, наиболее распространенный набор внешних библиотек, используемый в мире C++. Истоки большинства стандартных библиотек восходят к Boost, поскольку многие разработчики Boost также входят в состав комитета по стандартам C++ и именно они определяют, в каком направлении будет развиваться язык – поэтому можете считать Boost своеобразным дорожным указателем. Возвращаясь к заголовку этой статьи - 'Boost' содержит много популярного функционала, вспомогательных библиотек, так, что, если вы столкнулись с какой-нибудь распространенной проблемой – первым делом обращайтесь к Boost, так как велики шансы, что там для вас найдется готовое решение.

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

Open Telekom Cloud - самый крупный европейский публичный облачный сервис основанный на Openstack. Платформа создана для компаний и стартапов, которые работают с европейскими пользователями, чьи данные должны храниться в пределах Евросоюза. По структуре сервисов и API запросам он больше всего похож на Amazon Web Service / Huawei Cloud / SberCloud.

Если вам интересна тема, то добро пожаловать под кат!

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

AmoCRM одна из самых популярных CRM, при этом ее API один из самых странных, по моему субъективному мнению. Понадобилось передавать формы с сайта в crm. Использовать CRM Формы вместо своих дизайнерских не хочется. Было бы здорово открыть статейку в гугле, подставить ключ и не париться особо, но на удивление не нашел ни одной статьи с актуальной инфой, где-то версия api уже не актуальна, где-то вместо использования дефолтных полей контакта, создаются кастомные. В общем решил поделиться своим решением, для тех, кому сложно/лень вникать в их API.

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

Как же быстро летит время... Прошло почти 2 месяца с момента публикации моей первой статьи о работе с TINKOFF INVEST API – Разработка торгового робота на JAVA. Часть 1, в которой мы начали свое знакомство с инструментарием автоматизации торговли, предоставляемым брокером ТИНЬКОФФ.

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

Если нет желания вникать в код и читать статью, то можете сразу мотать к разделу "Демонстрация работы приложения".

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

Для решения такого рода проблем в ASP.Net Core существует механизм версионирования API – когда контроллеры и их методы могут существовать одновременно в разных версиях. В таком случае, те сервисы, которым достаточно существующего состояния используемых ими API, могут продолжать использовать определенные версии этих API, а для сервисов, которые требуют модернизации логики контроллеров, мы можем создавать новые параллельные версии, и все эти версии могут работать в нашем проекте одновременно.

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

К старту курса по тестированию на Python при помощи шаблона Read the Docs, пакетов restclient, ob-restclient и Org Mode в Emacs напишем красивую, полезную документацию API, которая генерируется автоматически и легко отображается на статическом сайте.

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

Hola, Amigos!

Меня зовут Артем, и я TeamLead. Сегодня расскажу, как мы настроили процессы взаимодействия с командой и заказчиками внутри команды, и об инструменте, с помощью которого все реализовали. Итак, поехали!

Я начал поиск информации о возможностях автоматизации получения данных с сайта...

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

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

В ходе разработки проекта надо было подключить fb api для того что бы менеджеры сайта смогли общаться с клиентами сайта не только из админки, но и из своих профилей fb messenger.

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

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

Я не буду углубляться на тему создания чата на сайте. По этому вопросу много написано в просторах интернета.

Допустим у нас есть сайт, с уже созданным чатом (node.js, socket.io).

Давайте разделим статью на 2 части.

1. Ресурсы, которые нужны.
2. Написание кода.

Это две последние главы раздела «Обратная совместимость» моей книги о проектировании 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 тестирование целой подсистемы —  есть где развернуться, проявить изобретательность!