Меня все сильнее раздражает, сколько людей готовы записывать в REST API любой интерфейс на основе HTTP. Сегодня приведу в качестве примера SocialSite REST API. Это же вызовы удаленных процедур (RPC). Он просто выкрикивает RPC. Связность между элементами на экране настолько сильная, что это творение заслуживает рейтинга X.
Если через ваш API исполняются операции, которые имеют последствия для пользователей или партнёров (в частности, стоят денег), то вам необходимо иметь тестовую версию этого API. В тестовом API реальные действия либо не происходят совсем (например, заказ создаётся, но никем не исполняется), либо симулируется дешёвыми способами (например, вместо отправки SMS на номер пользователя уходит электронное письмо на почту разработчика).
Однако во многих случаях этого недостаточно.
Это глава 30 моей бесплатной книги про API.
К сожалению, многие разработчики API уделяют справочной документации прискорбно мало внимания; между тем документация является ни много ни мало лицом продукта и точкой входа в него. Проблема усугубляется тем, что написать хотя бы удовлетворительную с точки зрения разработчиков документацию невероятно сложно.
Прежде, чем мы перейдём к описанию видов и форматов документации, хотелось бы проговорить очень важную мысль: пользователи взаимодействуют со справкой по вашему API совершенно не так, как вы себе это представляете. Вспомните, как вы сами работаете над проектом: вы выполняете вполне конкретные шаги.
Весной мы добавили новую подсказку о том, в какую сторону выходить из вагона метро. Меня зовут Влад, я программист С++, и на примере этой подсказки хочу рассказать, из чего состоит жизненный цикл релиза новых фич в 2ГИС. И сколько всего происходит, когда добавляешь — казалось бы — небольшую новую строку с текстом.
Недавно выдалось свободное время и я сделал простой проект про specialty-кофейни на Кипре: сайт и телеграм-бот по всем канонам "большой" разработки. Люблю хороший кофе 😊
Делюсь своим процессом разработки и рекомендациями как сделать всё задуманное без потери времени.
В этом посте я хочу поделиться интересным опытом работы с неразмеченными данными при помощи открытого ресурса opentripmap.
Задача
По исходным данным определить является ли конкретное фото, сделанное пользователем туристическим или нет. А так же масштабировать и автоматизировать алгоритм решения на любой регион Российской Федерации, избегая ручную работу.
Микросервисная архитектура популярна. Даже если речь идет о создании одного небольшого приложения, как правило его реализуют в виде пачки микросервисов, которые запущены отдельно и как-то реплицируются. Как они между собой будут взаимодействовать?
В этой статье поговорим о том, какие бывают способы общения в микросервисной среде. Расскажу на пальцах, какие обычно предъявляются требования к общению сервисов, почему большинство использует REST API, даже при том, что у него тоже хватает минусов, и при чем тут Kafka.
Рассчитываю на новичков, но если у вас есть интересный опыт в этих вопросах - добро пожаловать в комментарии.
Поскольку API — программный продукт, разработчики фактически будут задавать вопросы о работе того или иного фрагмента кода, который они пишут. Этот факт сам по себе задирает планку требований к качеству специалистов поддержки до очень высокого уровня, поскольку прочитать код и понять причину проблемы может только разработчик же. Но это полбеды: другая сторона проблемы заключается в том, что, как мы упоминали в предыдущих главах, львиная доля этих запросов будет задана неопытными или непрофессиональными разработчиками, что в случае любого сколько-нибудь популярного API приводит к тому, что 9 из 10 запросов будут вовсе не про работу API.
Всем привет. В своей истории я хотел бы поделиться опытом поиска и анализа московской биржи и историей реализации библиотеки для получения данных из нее. И что по итогу вышло.
Все случилось одним летним тёплым днем. Когда меня озарило, или солнечный удар случился, что надо вложиться в деньги. Пошарив по закромам, я даже нашёл небольшую финансовую подушку с остатками моей стипендии. Отлично, начало положено, теперь надо что-то купить, чтобы стать богатым.
Привет, меня зовут Юрий, и я фулстек-разработчик в DataLine. В компании занимаюсь созданием и развитием внутренних и внешних ИТ-сервисов: Сервисдеска, мастер-справочников, учета оборудования.
Но, как говорится, каждый разработчик в жизни должен сделать 3 вещи: развернуть дерево, распарсить DOM и вырастить своего чат-бота. О последнем и поговорим: расскажу, как делал своего первого чат-бота для нашего Сервисдеска, какие задачи и как решал, с какими трудностями и способами преодоления столкнулся.
Задача отсеивания нежелательных запросов, в общем случае, состоит из трёх шагов:
- идентификация подозрительных пользователей;
- опционально, запрос дополнительного фактора аутентификации;
- вынесение и применение решения об ограничении доступа.
Большое количество задач, с которыми сталкиваются аналитики – интеграционное взаимодействие между различными системами. Часто при первом взгляде на задачу совершенно не понятно с какой стороны к ней подойти, и как не потратить много времени на то, что реально важно. Ниже я приведу несколько примеров из своего опыта по реинжинирингу интеграционных процессов и выделю несколько основных скиллов, которые будут полезны аналитику при работе над подобными задачами.
В начале апреля состоялся онлайн-марафон идей Spotlight Digital Challenge. На нем встретились 260 участников и участниц из Кыргызстана, Казахстана, Таджикистана, Узбекистана и Туркменистана. Всё ради необычной задачи — команда организаторов предложила хакнуть социальные проблемы, связанные с гендерной проблематикой.
Возможно ли создать интерфейс для получения любого типа данных одинаковым способом?
Это исследование данных. Как внутри программы мы получаем данные, создаем, трансформируем и передаем.
Мой опыт разработки под iOS с 2008 года, примеры на языке Swift.
Привет! Меня зовут Руслан, я разработчик ноды Waves Enterprise. Одна из особенностей нашей платформы — это использование контейнеризированных смарт-контрактов, что позволяет писать их на любом языке и таким образом легко входить в блокчейн-разработку со знакомым стеком. В этом посте я расскажу, как у нас запускаются и валидируются смарт-контракты, как они работают и взаимодействуют с нодой. И что, наверно, интересней всего — как организовано их согласованное параллельное исполнение.
В контексте работы с API мы говорим о двух видах пользователей системы:
пользователи-разработчики, т.е. ваши партнёры, разрабатывающие код поверх вашего API;
конечные пользователи, которые будут работать с приложениями, написанными партнерами с использованием вашего API.
Со временем использование API приобретает все более повсеместный характер. BFF (Backend For Frontend) — общепринятый подход, DDD набирает обороты, а принципы проектирования API встречаются повсеместно. Несмотря на все это, мы продолжаем наблюдать, как организации, придерживающиеся всех этих практик, с трудом осваивают новые каналы.
И мы заметили тенденцию к усложнению, которая кроется в нашем BFF-канале. Эта проблема снижает скорость выхода на рынок с каждым новым каналом, который мы добавляем, или с каждым изменением в нашем клиентском опыте.
Обычное использование httr2 — это создание обёртки над каким нибудь API и предоставление его в виде R пакета, в котором каждая конечная точка API (то есть URL-адрес с параметрами) становится функцией. Эта статья поможет разобраться, как начать с очень простого API, не требующего аутентификации, а затем постепенно приводимые примеры будут усложняться.
