Что такое api habr
Вы зарабатываете на информации (зачем нужен API и как его грамотно спроектировать)
Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик.
Информация — основа любого приложения или сервиса.
Более 10 лет назад я общался с владельцем покер-рума, и он показал мне страницу, приносившую около 10 000$ в день. Это была совершенно банально оформленная страница. На ней не было ни стилей, ни графики. Сплошной текст, разбитый заголовками, секциями и ссылками. У меня просто не укладывалось в голове — ну как вот это может приносить такие деньги?
Секрет в том, что «вот это» было одним из первых исчерпывающих руководств по игре в покер онлайн. У страницы был PageRank 10/10 (или 9, не суть), и в поисковой выдаче это было первое, на что натыкались.
Цель вашего приложения, какое бы оно ни было — донести (получить, обработать) некоторую информацию до пользователя.
Даже если это будет ужасный, некрасивый и неудобный сайт, пользователи всё равно найдут тот товар, который искали. Особенно, если вы торгуете чем-то достаточно уникальным (хотя бы в вашем регионе). Плюс поисковики вам помогут, выводя пользователя сразу к нужному товару.
Конечно, конверсия может быть ниже, или пользователь может быть не очень доволен опытом работы с сайтом, но, если сам товар будет именно тем, что он искал — всё остальное будет малозначимо.
Я не рассматриваю магазины, продающие «на эмоциях», и покупки, о которых пользователь может потом пожалеть.
Примеры могут варьироваться в зависимости от жанра и других параметров, но в целом пользователя интересуют такие вещи, как история мира, переписка/общение с союзниками, информация о текущих событиях, информация об его персонаже/деревне/корабле/чем-угодно-другом.
Очень часто способ доступа к этой информации уходит за пределы самого клиента игры. С помощью мобильного приложения можно проверить, не нападает ли на тебя кто, или выставить какие-нибудь товары на внутриигровой аукцион, даже не заходя в саму игру.
Пользователь хочет найти интересующую его музыку. Все обёртки, умные очереди, лицензионность и прочая шелуха мало кого интересует.
Конечно, хорошо использовать лицензионный контент, но если пользователь не может найти то, что искал — он уйдет и найдет это в другом месте. В интернете люди не запоминают информацию как таковую, они запоминают место, где эту информацию нашли. Поэтому, если на вашем сайте нет песен группы Х, но зато есть ссылка на страницу группы Х, где они продают свои альбомы, ваш сервис все равно в плюсе, потому что пользователь запомнил, где он взял информацию о группе Х и вернется к вам еще раз поискать информацию о группе Y.
Я работал в нескольких музыкальных проектах, и очень часто всё упиралось именно в наличие необходимых треков, несмотря на десятки терабайт данных.
Думаю, идею вы уже уловили. Примеры можно приводить бесконечно (вот ещё один: на википедию не за дизайном ходят. Более того, часть информации с википедии выводится сразу в поисковой выдаче, без открытия даже самого сайта), и если думаете, что в вашем случае это неприменимо — напишите в комментариях (или на почту / в личку), и я объясню, почему всё же применимо.
Так вот: чем бы вы ни занимались, первичной всегда будет информация. Хорошую, качественную информацию пользователи обязательно найдут и обратятся к вам.
Я расскажу, как организовать работу с информацией так, чтобы это было:
1. Масштабируемо — репликация, шардирование и т.п. настраивается БЕЗ вмешательства в работу приложения.
2. Удобно для пользователей — легко документировать, понятно как использовать.
3. Удобно для ваших разработчиков — быстрое прототипирование, возможности оптимизации только необходимого.
Данный подход не имеет смысла для вас, если у вас маленький проект с небольшим количеством компонентов и разработчиков.
В тексте статьи я использую ряд допущений: например, что у вас уже что-то имеется или реализовано.
Практически в каждый из вопросов можно углубляться бесконечно, по объему подробный разбор тянет на целый цикл подобных статей. Если какая-то информация не была указана — я посчитал, что для восприятия концепта она не важна.
Если считаете, что всё же чего-то не хватает — пожалуйста, сообщите, и статья будет дополнена в соответствии с пожеланиями.
Потребители информации
Потребителей информации можно разделить на две категории — внутренние и внешние.
Внутренние — это ваши же продукты и сервисы. Разница в том, что для «своих» API может предоставлять гораздо более широкий функционал с меньшими ограничениями. Например, те же карты гугла на собственном домене могли работать с применением webgl, и как следствие, значительно быстрее, а встраиваемые — нет (на текущий момент ситуация могла измениться, не проверял).
Внешние — конечные пользователи или продукты, не принадлежащие вашей компании. Например, для карт гугл вы являетесь внешним пользователем. Обычно доступ к информации извне сильно ограничен, и часто требуются специальные ключи доступа.
Как работать с информацией?
Для работы с информацией мы будем предоставлять web API. Реализовывать будем 2 слоя (внешний и внутренний). Слой подразумевает, как минимум, отдельное приложение.
API позволяет предоставлять данные в платформонезависимом виде. Не всегда известно, каким образом и где будут использоваться данные, и разработка API — хороший способ заявить «у нас есть информация — обращайтесь к нам».
Все примеры кодов — лишь один из многих вариантов реализаций. Это обеспечит возможность использования данных независимо от способов реализации конечного продукта (включая оффлайн приложения, при условии хотя бы единовременного выхода в сеть).
В первую очередь необходимо описать модели и коллекции данных. В случае если приложение реализуется на Javascript (nodejs на сервере), появится возможность использовать одни и те же модели и на клиентах, и на серверах.
Модель — описание некоей сущности (например, музыкальный трек): её поля, их свойства, способы доступа и предоставления информации. Модель может дублировать схему базы данных, но также может расширять её дополнительной информацией. Более того, модель может содержать информацию из нескольких таблиц/коллекций и представлять её как одну сущность. На сервере модель должна быть расширена описаниями по работе с таблицами, доступами к серверам и так далее. На клиенте модель расширяется адресами доступа к данным.
При обращении к данным модель может содержать также дополнительную метаинформацию о самом запросе (время выполнения, позиция записи в базе, связи), виртуальные поля (например, если в базе хранится path — относительный путь до файла, можно добавить виртуальное поле url, которое будет вычисляться «на лету»).
В качестве примера я приведу код, описывающий некий музыкальный сервис.
Примеры будут на Javascript, однако всё описанное применимо к любому языку. Я делал подобные вещи также на php, python и c++. Всё необходимо варьировать в зависимости от размеров проекта.
Чтобы не захламлять код, я опущу подробные описания проверок в примерах. При желании можно указывать любое количество критериев, тексты ошибок валидации и т.п.Валидация применима как на клиентах, так и на серверах.
Коллекция — набор сущностей (обычно одинаковой природы, то есть, к примеру, музыкальные треки). Набор данных также может содержать дополнительные, относящиеся к самому набору, данные. В качестве метаинформации может быть представлено количество выбранных треков, количество оставшихся (не выбранных) треков, номер страницы, количество страниц. Виртуальным полем может быть общая продолжительность всех треков.
Внутренний слой API
Этот слой будет доступен только нашим продуктам.
Так как наши модели уже содержат много информации, мы можем предоставить доступ к данным, используя минимальное количество кода.
Расширяем модель на сервере и клиенте, описывая название и путь. Общие реализации методов findOne, update, destroy и create описаны в абстракции модели и не требуют отдельной реализации, если принципиально не отличаются.
Расширяем модель только на сервере:
Расширяем модель только на внутреннем клиенте:
На этом слое мы имеем максимальную гибкость запросов.
В ответ получаем что-то типа:
Не обязательно именно так вкладывать информацию. Если боитесь дубликатов (хотя, если в плане трафика, то gzip с ними отлично справляется), можно собирать в отдельные поля в начальный result.
Внешний слой API
Внешний слой доступен непосредственно конечным клиентам. Он может представлять из себя веб-сайт или просто API для сторонних разработчиков.
На внешнем слое мы НЕ предоставляем такую гибкость, как на внутреннем, а только даем доступ к базовым возможностям: основной параметр запроса, отступ, количество и т.п. Причем всё это с ограничениями.
Отчасти он является прокси до внутреннего API с рядом важных дополнений.
Вместо «. » делаем необходимые проверки прав, модифицируем запрос, определяем формат. Данные возвращаются в том же формате и тем же путем, как были запрошены.
Т.е. для http и json данные так и вернутся. Для socket и xml ответ будет через сокет и в xml.
Таким образом мы можем полностью контролировать, что доступно извне, как, на каких условиях и так далее.
Оптимизация тяжелых запросов
До этого мы описывали работу с базой максимально абстрактно, и, само собой, подобные запросы будут выполняться значительно медленнее оптимизированных. С первым шагом мы обнаруживаем (с помощью профайлера, либо другим удобным вам способом), что какой-то из запросов работает медленно.
Допустим, мы обратили внимание, что медленно работает запрос, в котором выбирается трек вместе с информацией об альбоме и музыканте. Для оптимизации нам понадобится создать новый внутренний метод:
и меняем вызов на внешнем слое ко внутреннему на представленный. Всё. Для конечного клиента ничего не поменялось, и кэш, и пути, и получаемые данные — те же, но вот работать всё стало быстрее.
Пользователи
Основная задача при работе с пользователями — проверять их права.
Как только пользователь авторизуется (способ не важен: куки, ключ, другой вариант), мы делаем один запрос к внутреннему слою, удостоверяя личность и получая разрешения. Далее проверки мы будем делать на внешнем слое.
Масштабирование
Большие преимущества мы получаем именно на этапе масштабирования.
И внешний и внутренний слой API мы можем запускать в любом количестве экземпляров, разруливая нагрузку с помощью балансеров. За счет подобного разделения мы можем запустить множество приложений с внешним слоем максимально близко к конечному клиенту, получив собственную CDN сеть с кэшированием данных.
Базы данных расширяются классическими способами, зависящими от задачи.
Кэширование
Для внутреннего слоя мы кэшируем результаты запросов к базам данных, а на внешнем — результаты, полученные от внутреннего слоя. У конечного клиента тоже может быть кэширование.
В одном из предыдущих примеров была строка «cache: 1800» — она может предоставить кэш как на внешнем слое, запоминая результат на сервере на полчаса, так и на клиенте, сложив результат, например в localStorage (ну или другое хранилище клиента).
Версионирование
Организовать файлы и поддержку разных версий можно несколькими путями, например:
1. Сделать папки v1, v2 и поместить в них весь относящийся к ним код. При модификации одной из версий API другая не затрагивается.
2. Различные репозитории, функционируют как различные приложения.
Буду рад добавить в статью дополнительные разделы по вашему запросу.
Также, если хотите уточнить где-то код — напишу и приложу, спрашивайте.
Возможно, это начало большого цикла статей на различные темы (или начало уже было положено). Материала накопилось очень много, но он не систематизирован.
Я хочу создать полноценный курс по разработке веб проектов. Прямо с нуля и до full-stack.
По планам он будет включать: видеолекции + текстовые уроки, домашние задания, самостоятельные проекты, работу с ментором, различные интенсивы, кучу кода (в формате запуска/доработки онлайн) и так далее. В качестве особенности хочу сделать «сетевой» формат, а не последовательный. Т.е. после прохождения определённых тем открываются другие, и ученик может сам выбирать, что его интересует в данный момент. По предварительным оценкам длительность обучения будет в районе полугода полноценных занятий по паре часов в день.
Понятно, что подобный проект реализуется не так быстро. Потому подойти к его разработке я хочу именно с привлечения партнёра, на чьей базе его можно будет реализовывать / продавать. Т.к. если сопутствующие вопросы я возьму на себя, то срок реализации станет совсем запредельным. Ну и плюс у разных порталов различный инструментарий, который я хочу учесть.
Я уже писал ряду проектов типа coursera с описанием своей затеи, но не получил никаких ответов. Причем, что обидно, вообще никаких, даже отказов.
Рынок изучал и уверен, что то, что реализую, более чем конкурентоспособно.
Буду рад любым предложениям о партнёрстве или советам, к кому следует обратиться.
Современный мир держится на API
Сегодняшний мир держится на интерфейсах прикладного программирования — API. С ними стало возможным получать данные и потреблять услуги через веб-приложения, мобильные приложения и устройства, подключенные к сети. Все чаще взаимодействие в интернете выполняются именно через API. Благодаря API появляются новые модели ведения бизнеса, а интернет стал универсальной бизнес-платформой.
API не имеет индустриальной привязки, компании из разных сфер экономики видят в их использовании ценность для своего бизнеса. В свою очередь, рынок программного обеспечения для управления API стремительно развивается, об этом свидетельствуют отчеты Gartner и Forrester.
Всего несколько лет назад взаимодействие между разными подразделениями одного и того же бизнеса обычно обеспечивалось через интеграционную шину. Но модель взаимодействия через API-портал — портал, на котором публикуются API — оказалась настолько удобной, что теперь ее используют и внутри компаний.
Как же получилось, что, даже выбирая модель взаимодействия между подразделениями, компании склоняются сегодня к решениям на основе API? В чем суть актуальной технологической модели и каковы новые правила игры?
Открытые API — мода или необходимость?
В Европе интерес к инновациям в области финансовых потоков поддержала платежная директива Европарламента PSD2, выпущенная для создания более равномерного, прозрачного и открытого рынка платежей, который будет содействовать инновациям, конкуренции и безопасности. В России развитие открытых API официально признано ключевым элементом, необходимым для эффективной интеграции систем участников финансового рынка.
Российское государство и его финансовый сектор уже осознали необходимость открытого банкинга. Предоставление банковских API внешним организациям признано ключевым элементом, необходимым для эффективной интеграции систем участников финансового рынка, инициативы выпуска открытых API поддерживают Центробанк, портал Банки.ру, Московская биржа, «Национальный клиринговый центр» и «Национальный расчетный депозитарий». Отдельные банки уже сформулировали свою стратегию открытого банкинга, определились с моделью дальнейших действий, официально анонсировали доступ к своим системам и сервисам через открытые API и приступили к соответствующим работам.
Список API на webMethods API portal
Отечественные операторы мобильной связи тоже предлагают новые платформы с API для развития бизнесов своих партнеров. Это позволит телекоммуникационным провайдерам поддерживать своих партнеров, объединяя их предложения и расширяя для них рынок сбыта.
Российские банки и телекоммуникационные провайдеры — это именно те предприятия, которые первыми осознали себя как разработчики программного обеспечения, а рынок — как большую цифровую платформу для управления продуктами, настройки маркетинговых акций и взаимодействия с потенциальными клиентами. Продуктовые команды, заказчики, компании и клиенты понимают, что чем более открытыми они будут, тем более открытыми будут их продукты, и тем быстрее они будут интегрироваться в общую экосистему тех рынков, на которых они работают. Поэтому они и используют открытые API — разумный и эффективный способ взаимодействия разработчиков, который позволяет драматически сократить время выхода новых продуктов на рынок.
Кроме того, открытые API представляют своим партнерам такие разработчики программного обеспечения, как «Яндекс». Почта России тоже предлагает интеграцию с внешними приложениями через API, что позволяет встроить сервисы Почты России в сторонние сайты, приложения, системы учета и документооборота — например, добавлять на сайты функции отслеживания отправлений.
И, конечно, создание продуктов с открытыми API естественно для самих разработчиков программного обеспечения, таких как Software AG. Чем полнее их продукты будут документированы и чем лучше они будут управляться, тем больше будет у них пользователей.
Но управление открытыми API никому не дано свыше. Оно невозможно без соответствующего технологического стека.
Кто разрабатывает API-платформы и как они работают
Согласно вышеупомянутому «волшебному квадранту» агентства Gartner, лидерами на рынке систем управления полным жизненным циклом API являются компании Google, CA Technologies, IBM, Software AG, MuleSoft, Red Hat и TIBCO Software. Агентство Forrester в своем недавнем исследовании называет лидерами компании IBM, Google, Software AG, Rogue Wave Software и WSO2.
Согласно отчету Forrester: «API являются ключевой основой для цифровой трансформации. Они способствуют оптимизации клиентского опыта, создают интегрированные цифровые экосистемы клиентов и партнеров, позволяют компаниям извлекать выгоду из прорывных цифровых инноваций, повышать операционную эффективность и закладывают основу для платформенных бизнес-моделей… Решения для управления API играют центральную роль в управлении отношениями между поставщиками и пользователями API, разработчики и поставщики приложений должны рассматривать их как бизнес-приложения, исключительно важные для успеха цифрового бизнеса».
Интерфейс администрирования API
«Не обеспечив полноценного управления жизненным циклом API, нельзя создать платформу для цифровой стратегии, построить экосистему и запустить эффективные продукты», — добавляет в своем отчете Gartner.
Что же обеспечивают системы для управления полным жизненным циклом API? Обычно в технологический стек управления жизненным циклом API входят средства публикации API на удобном для чтения портале, основным пользователем которого являются сторонние разработчики, среда эксплуатации, потребления, обслуживания, управления версиями API и средства их вывода из эксплуатации. Некоторые разработчики (в их числе Software AG) предоставляют также средства планирования, проектирования, внедрения и тестирования API.
Мы в компании Software AG занимались управлением API, когда это еще называлось «внутренним взаимодействием». Мы расширяли и совершенствовали связующее программное обеспечение, решения для интеграции приложений, системы для создания сервисной шины предприятия и инструментарий для создания систем, основанных на сервисно-ориентированной архитектуре.
В 2004 г. в дополнение к нашей интеграционной шине мы создали продукт B2B Trading Networks, предназначенный для межпартнерского взаимодействия и обмена данными. В нем были реализованы вполне классические пользовательские сценарии межпартнерского взаимодействия, включая постоянный мониторинг, сервис, обмен данными по итогам операционного дня. Тогда это еще не называлось открытыми API.
Наконец, пять лет назад мы представили полный жизненный цикл управления API в рамках платформы управления API webMethods. В 2014 г. мы запустили webMethods API Portal для разработчиков API, а в 2016 г. объединили функционал API-шлюз webMethods API Gateway, портала и средств медиации и управления жизненным циклом в одну платформу. Эти средства поддерживают разработку API, их сборку, одобрение и публикацию в принятом технологическом стандарте и являются частью платформы Software AG Hybrid Integration & API.
Выбор спецификации API
Как выбрать API-платформу
Агентство Forrester считает, что при выборе решения для управления API нужно, в первую очередь, учитывать, является ли предлагаемое решение комплексным — то есть содержит портал для разработчиков API, портал для управления API и API-шлюз. Особо отмечено, что некоторые решения предоставляют дополнительные компоненты, такие как инструменты проектирования и разработки API, интеграционные платформы, платформы управления услугами в режиме реального времени и т. п.
Далее Forrester подчеркивает, что решение для управления API должно быть настоящим автономным продуктом, отделяемым от любых связанных с ним платформ, интеграционных продуктов или бизнес-приложений.
Наконец, авторы отчета считают, что стоит доверять тем разработчикам решений, которые имеют ряд полноценных внедрений. Клиентами решения Software AG для управления API являются Michael Kors (производитель и поставщик одежды и аксессуаров высокого класса), American Electric Power (одна из крупнейших североамериканских энергетических компаний), Outerwall (поставщик автоматизированных киосков для розничных продаж), Dick’s Sporting Goods (розничная сеть спортивных товаров), EDF (крупнейшая французская государственная энергогенерирующая компания и крупнейшая в мире компания-оператор атомных электростанций) и др.
К этому списку параметров стоит добавить еще несколько факторов, которые необходимо принимать во внимание при выборе API-платформы.
1. В разных отраслях экономика работает по-разному и имеет разные схемы монетизации. Оцените план развития API-платформы, которую вы рассматриваете. Отражает ли она реалии вашего сегмента бизнеса? Важно определить бизнес-задачу внедрения, сформировать список бизнес-требований к решению и из него вывести список функциональных и архитектурных требований. Возможно, этот список определит выбор не только API-решения, но и дополнительных компонентов.
Управление политиками API
2. Очень важно, чтобы ваша API-платформа соответствовала ожиданиям ваших заказчиков, а точнее — их ИТ-отделов. Платформа должна быть удобна для внедрения и работы, она должна поддерживать комфортную для заказчиков технологическую модель развертывания (облачную, на физических ресурсах или гибридную), ее функциональность должна соответствовать их текущим потребностям, а план ее развития — их будущим потребностям на год или два вперед.
3. API-портал должен иметь широкие возможности аналитики, тестовые интерфейсы для разработчиков, возможность генерировать документацию на основе метаданных API. Он должен обеспечивать социальное сотрудничество разработчиков, генерацию клиентских SDK и средства монетизации.
Генерация клиентских SDK
4. API-шлюз должен обеспечивать безопасность (аутентификацию, авторизацию, управление политиками безопасности, защиту от атак), медиацию сервисов, возможности маршрутизации и балансировки нагрузки.
Подтверждение регистрации пользователя
5. Средства управления жизненным циклом API должны обеспечивать и оценивать взаимосвязь внутренних и внешних сервисов, микросервисов и обычных служб, технических и бизнес-сервисов, а также поддержку разных типов «активов» в каталоге.
6. Очень важен вопрос общей стоимости владения решениями, которая зависит от скорости разработки продуктов и времени их вывода на рынок — а на это влияют и практики, принятые у разработчиков, и используемые ими технологии.
7. Вопрос, на который у разработчиков API-платформ часто нет ответа — каким образом будет создаваться контракт между заказчиком и партнером и как будет работать биллинг – скорее всего у вендора есть рекомендации по реализации технологической возможности создания контракта.
Что ж, на самом деле в API нет ничего нового — просто раньше они были внутренними. Из-за сегодняшней волны интереса к API многим уже кажется, что этой аббревиатурой всегда обозначались способы взаимодействия компаний через интернет, но на самом деле API предоставляют способы взаимодействия продуктов, технологических сервисов и их потребителей, которые могут принадлежать как разным игрокам рынка, компаниям и заказчикам, так и разным бизнес-группам внутри компании.
Наш интеграционный продукт существует и развивается много лет, он стабилен и зрел, его используют многие заказчики. Чтобы оценить его самостоятельно, посетите нашу веб-страницу бесплатного тестового программного обеспечения, где вы легко найдете различные компоненты платформы webMethods. Протестируйте webMethods API Cloud Free Trial прямо сейчас и расскажите нам о своих впечатлениях.