Открытые api: public-apis/public-apis: A collective list of free APIs for use in software and web development.

Современный мир держится на API / Блог компании Software AG / Хабр

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

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

Всего несколько лет назад взаимодействие между разными подразделениями одного и того же бизнеса обычно обеспечивалось через интеграционную шину. Но модель взаимодействия через API-портал — портал, на котором публикуются 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 прямо сейчас и расскажите нам о своих впечатлениях.

как создать Альфа версию с первой попытки – Картина дня – Коммерсантъ

АО «АЛЬФА-БАНК» и компания Aviakassa.com при поддержке системного интегратора «Синимекс» запустили туристический сайт travel.alfabank.ru на базе платформы с использованием открытых API. О реальном опыте работы с открытыми API, тонкостях запуска и перспективах развития проекта на их основе рассказывают руководитель направления управления развития систем процессингового центра Альфа-Банка Михаил Лисовский, руководитель проекта Aviakassa.com Елена Тиунова и заместитель директора по работе с ключевыми клиентами компании «Синимекс» Павел Мышев.

Для начала давайте поясним, что такое открытые API и почему банки начали работать с ними?

Михаил Лисовский: Банковские открытые API позволяют разработчикам и финтехкомпаниям создавать приложения, работающие с данными клиентов банка: историей выполненных транзакций, счетами, заведением операций по ним и прочее. Открытые API — одно из перспективных направлений, которое развивается в странах Европы в рамках обновленной платежной директивы PSD2. Эта директива выпущена Европарламентом с целью обеспечения большей прозрачности и открытости рынка платежей в странах Евросоюза, поддержки инноваций, конкуренции и безопасности. В России идеи PSD2 активно поддерживает Центральный банк.

Мы в Альфа-Банке довольно часто говорим о предоставлении доступа к своим открытым API, однако данный проект первый, и он разработан нами в достаточно короткий срок. Всего за 2,5 месяца был проведен полный комплекс работ от идеи до первой карты: аналитика, разработка и внедрение. Рынок меняется очень быстро, поэтому все игроки стремятся сократить срок вывода продукта. В этих условиях задержка даже на неделю может стать критичной, так что приходится постоянно следить за происходящим и оперативно реагировать на потребности и вызовы рынка.

Какая задача стояла перед компанией Aviakassa.com?

Елена Тиунова: Задача заключалась в том, чтобы предоставить клиентам сервис по бронированию туристических услуг с возможностью оплаты баллами лояльности карты Alfa Travel. Это наш партнерский проект с Альфа-Банком, соответственно, нам нужно было найти совместный способ, позволяющий обмениваться данными, накапливать баллы и оплачивать ими приобретаемые у нас туристические услуги.

Проект с Альфа-Банком — очень интересный и амбициозный. Полный цикл его реализации занял 2,5 месяца. При этом доступ к API мы получили за 20 дней до старта проекта. Когда речь идет о том, чтобы предоставить клиентам возможность оплачивать покупку частично деньгами, частично баллами, реализация проектов, как правило, занимает довольно много времени. Однако предложенный «Синимекс» очень простой интерфейс позволил реализовать проект очень быстро. Важно, что эта простота применена отнюдь не в ущерб надежности и безопасности. Используемые в проекте технологии защищают как банк, так и клиента. Коллегами из «Синимекс» была предоставлена исчерпывающая документация с примерами на популярных языках программирования — это серьезно повлияло на скорость разработки.

Павел Мышев

Какова роль компании «Синимекс» в этой истории?

Павел Мышев: Нашей задачей было обеспечить доступность open API. Мы реализовывали интерфейсы на open API, а также компоненты, связывающие open API с системами процессинга банка. В рамках проекта Альфа-Банком были сделаны доработки на стороне процессинга, чтобы поддержать инфраструктуру и бизнес-процессы, поскольку ИТ-составляющая — это не весь процесс, есть еще карты и документы, которые необходимо подписывать. Компания «Синимекс» спроектировала открытые интерфейсы и обеспечила простоту работы с ними. API как таковые банк выставлял и раньше, а сейчас появилась платформа, заточенная под то, чтобы делать открытые API.

Разработанные вами сервисы универсальные, ими могут в будущем пользоваться и другие компании?

Михаил Лисовский: Этот проект — первая попытка предложить стандартизированный вариант взаимодействия с партнерами, который можно использовать многократно. Использование открытых API обеспечивает легкость запуска проекта и возможность вывода на рынок проекта в самые кратчайшие сро

Как открытые API банков меняют финансовый мир / Хабр

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

Раскрытие банковских данных

Тренд зародился в Европе, так, например, в Германии с 2010 года развивается Open Bank Project – проект, поддерживающий раскрытие банковских данных и пользующийся поддержкой крупнейших банков страны.

В Великобритании в сентябре 2015 года при поддержке органов государственной власти была выдвинута инициатива Open Banking Standard, которая направлена на повышение конкуренции и доступности услуг на финансовом рынке. Согласно инициативе, банки должны предоставить 3-им лицам (т.н. финансово-техническим компаниям) данные о балансе клиентов и доступ к их расчетным счетам. Применение принципа открытых банковских данных стало обязательным для 9 крупных банков Великобритании, которые обслуживают более 80% граждан страны.

Использование технологии API

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

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

Возможности и выгоды открытого банковского API

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

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

Мульти-банковское приложение позволяет:

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

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

Открытый доступ к банковскому API выгоден и банкам:

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

Как видим, решение об открытом банковском API приносит выгоды всем сторонам процесса. Теперь рассмотрим, как эта концепция применяется в разных странах мира.

Опыт применения открытого банковского API

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

В США государственное регулирование вопроса открытых API банков отсутствует. Тем не менее, благоприятная финансовая обстановка привела к созданию банковского агрегатора компании Mint, сайтом которой уже в 2016 году пользовались около 20 млн. жителей США и Канады.

В Сингапуре денежно-кредитное управление (MAS) поддерживает принципы открытого банковского API. Ассоциация банков Сингапура (ABS) и MAS подготовили документ Finance-as-a-Service: API Playbook, содержащий информацию и рекомендации для финансового сектора и призванный обеспечить эффективный обмен финансовой информацией, а также создать почву для запуска инновационных банковских проектов.

В Индии была создана информационная платформа открытых API India Stack, которая включает в себя такие системы и сервисы, как: Aadhaar – крупнейшую в мире систему цифровой биометрической идентификации; Национальная платежная корпорация Индии; Digital locker – платформа для формирования и верификации документов в цифровом виде и др.

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

Опыт применения открытого банковского API в России

В России в 2016 году по инициативе Сбербанка, Альфа-банка и других финансовых компаний была создана организация ФинТех, целью которой является развитие финансовых технологий в стране. Также в России развивается ФинтехСмарт — ассоциация-профсоюз, занимающаяся развитием среды для финансовых стартапов и сообщество RusFinTech, организующее семинары и конференции на тему финансовых технологий.

Говоря о перспективах развития открытых банковских API в России, стоит упомянуть инициативу, запущенную Банком России совместно с финтех организациями.

Данное направление предполагает проработку сценариев применения открытых API, проведение пилотных проектов, а также разработку стандартов и документов по применению открытых API в России. Уже сейчас крупнейшие банки страны, такие как Сбербанк, Альфа-Банк, ВТБ 24, Газпромбанк и Банк Открытие готовы предоставить свои API сторонним организациям.

Тенденции развития открытых банковских API говорят о том, что направление по разработке мобильных приложений для бизнеса финтех организаций, а именно — мульти-банковских приложений в России станет актуальным в ближайшее время. По данным исследовательского агентства Markswebb, на территории РФ мобильными банками пользуются 18 млн человек, что составляет около 33% от общей интернет-аудитории страны. Хотя бы одним интернет-банком пользуются 35,3 млн человек, или 64,5% всех российских интернет-пользователей. Возраст пользователей интернет и мобильного банкинга ранжируется от 18 до 64 лет.

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

Опыт Wellsoft в разработке мобильных приложений для банков позволяет реализовывать подобные решения в данный момент при желании клиента.

Open API – от бесплатных до премиальных. Банки и финтех открывают новые возможности – для себя и для клиентов

Сегодня весь мир движется в сторону открытого банкинга. Он способствует взаимодействию между участниками финансового рынка и других отраслей. С каждым днем все больше банков, страховых компаний, стартапов и финтехов разрабатывают новые приложения и цифровые решения. С одной стороны, это усиливает конкуренцию, но с другой – чем больше сервисов, тем сильнее размывается внимание и доверие клиентов. И чтобы сделать следующий шаг в развитии, игрокам нужно объединить усилия в создании общих интерфейсов и налаживании обмена данными о клиентах и технологиях – уверена Татьяна Жаркова, генеральный директор Ассоциации ФинТех.

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

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

В чем же преимущества открытых API для банков? Зачастую крупные игроки не готовы делиться данными с другими участниками рынка, особенно с прямыми конкурентами. Согласно исследованиям ВТБ, 21% российских банков вообще не планирует использовать API, а 20% опрошенных банков критически относятся к внешним API.

Однако нередко компании просто недооценивают возможности API. Часто банки резонно спрашивают: мы открываем доступ к нашим данным, но что получаем взамен? По мнению главы финансового стартапа Gini Рэя Уайанда (Ray Wyand), у кредитных организаций есть огромные массивы неструктурированных данных о своих клиентах. И привлечение узкоспециализированных финтехов и других участников с четко сегментированной аудиторией позволит эти данные упорядочить и обогатить. Также банки получают доступ к новейшим технологическим сервисам, не тратя время и свои внутренние ресурсы на их разработку.

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

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

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

Клиенты банков (физические и юридические лица) благодаря открытым API получат новые услуги и приложения, которые значительно упростят их жизнь, а качество и скорость уже существующих услуг возрастут. Мобильные банковские приложения превратятся в финансовых советников, которые будут предоставлять клиентам информацию о счетах и продуктах в разных банках, основных статьях расходов, помогать совершать регулярные платежи и расширять возможности для инвестирования. При этом пользователь сам будет управлять своими данными: именно он решит, какой информацией и с каким банком поделиться, на какой срок разрешить доступ. Открытые API – ключ к созданию доверительной среды как между банками и финтехами, так и между компаниями и их клиентами, а сегодня доверие клиентов стало самым редким и дорогим активом.

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

Один из возможных сценариев – это создание т. н. премиальных API. В отличие от общедоступных, «входной билет» в этот сегмент будет для финтехов платным. Благодаря этому британские банки смогут реализовать различные модели монетизации API. Это могут быть модели freemium (оплата API только при превышении определенного лимита), revenue sharing (разделение выручки от продаж между партнерами), cost per action (оплата при совершении клиентом покупки) и другие. Главное – соблюсти баланс между общедоступными и премиальными API, чтобы открытый банкинг оставался по-настоящему открытым для финтех-компаний, для которых преобладание платных API станет барьером.

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

В России открытые API только выходят на большую повестку. На площадке Ассоциации ФинТех (АФТ) была разработана «Концепция открытых API», где описаны различные аспекты их разработки и внедрения, определены типы открытых API и составлен список рекомендованных открытых API – в настоящий момент эта концепция находится на рассмотрении Банка России. Также на площадке АФТ уже заработал пилотный проект по обмену информацией о счетах юридических лиц через открытые API.

5 бесплатных и забавных API-интерфейсов для обучения, личных проектов и многого другого!

Публичные API — это круто!

Только в публикации Towards Data Science есть более 50 статей, посвященных API, поэтому я не буду вдаваться в подробности введения. API в основном позволяют вам взаимодействовать с некоторыми инструментами или услугами (которые могут быть предоставлены буквально кем угодно).

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

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

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

Давайте приступим!

  Holy crap, это коза, созданная PlaceGoat

Я думал, что начну с очаровательного козленка.

Это действительно простой GET API, с помощью которого вы можете создавать изображения коз. Хотел бы я сказать больше, но это действительно так. Вот ссылки на основной сайт и репозиторий Github.

PlaceGOAT основной сайт

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

http://placegoat.com/width/height

Если вы просто хотите протестировать библиотеку requests на Python, это будет отличным местом для начала. Если вам нужна идея, попробуйте написать сценарий, чтобы ежедневно получать изображение козы и каждое утро отправлять его своей второй половинке (или своей маме), чтобы напоминать им о том, как сильно вы заботитесь о них. Это будет лучший вариант завтрака в постели.

PokéApi главная страница

Покемон! Надо * получить их всех, покемон!

RESTful PokéApi бесплатен для использования и позволяет ПОЛУЧАТЬ информацию из всеобъемлющей базы данных обо всем, начиная с игр Pokémon, от первых выпусков Red и Blue до Sword and Shield.

База данных действительно обширна. Вы можете получить что угодно: от способностей покемонов до триггеров эволюции и твердости ягод. Проверьте главный сайт PokéApi и документацию для получения дополнительной информации. Если вас интересует оболочка для конкретного языка, проверьте раздел «Библиотеки оболочек». Например, вы можете установить интерфейс Pokebase Python для использования непосредственно в ваших скриптах Python, вместо того, чтобы вызывать API с библиотекой requests.

PokéApi документы

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

https://pokeapi.co/api/v2/berry-firmness/

Результаты твердости ягод в формате JSON  

Обычно, когда вы вызываете конечную точку API, вы также должны указать идентификатор или имя, чтобы получить информацию о конкретной точке данных. В PokéApi говорят, что если вы вызываете конечную точку без идентификатора или имени, вы получите список по умолчанию, содержащий до 20 ресурсов, доступных для API. В этом случае существует 5 возможных результатов для конечной точки «твердость ягод», поэтому вы увидите, что все они возвращаются в формате JSON, когда вы вызываете ссылку выше.

Пришло время отметить, что при использовании полностью открытых API-интерфейсов следует помнить о том, как часто вы вызываете конечные точки службы. PokéApi удалил ограничение скорости (конфигурация API, определяющая, сколько запросов может быть выполнено за интервал времени), но по-прежнему напоминает пользователям ограничивать частоту их запросов, чтобы снизить расходы на хостинг. В своей политике добросовестного использования они говорят, что люди должны локально кэшировать запрошенные ресурсы и что DDoS-атаки приведут к постоянной блокировке IP-адресов. Будьте ответственным!

Главный сайт Rick and Morty API

Рик и Морти!

Этот API является RESTful и позволяет использовать GraphQL для запроса к нему. Они также удобно связывают вас с документами GraphQL, если вы новичок в языке запросов. Вы можете использовать API, запрашивая метаданные GET о персонажах, местах и ​​эпизодах шоу.

Документы API Рика и Морти

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

https://rickandmortyapi.com/api/character/5

  JSON результаты Джерри Смита

Здесь поставка «5» дает нам информацию о персонаже Джерри Смита. Вы также видите в конце связанное изображение персонажа, поэтому, если вы хотите попрактиковаться в загрузке файлов из API, это может быть хорошим местом для начала.

Посетите основной сайт и документацию для получения дополнительной информации. Существует также множество библиотек- оболочек для разных языков от нескольких авторов, так что проверьте их, если вы предпочитаете их. Его реализацию на Python можно найти здесь. Кроме того, если вы знакомы с JavaScript и заинтересованы в участии в проекте с открытым исходным кодом, вы можете ознакомиться с API Рика и Морти на Github.

icanhazdadjokes главный сайт

Кто не любит отцовские шутки?

Я не уверен, учитываются ли мои каламбуры, связанные с API, но я определенно люблю всевозможные «плохие» шутки.

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

icanhazdadjokes API документация

curl — это удобный инструмент, который можно использовать со своего терминала для передачи данных на сервер или с сервера. В этом случае вы можете проверить это, используя HTTP для ПОЛУЧЕНИЯ определенного URL. Например, вы можете попробовать в своем терминале следующее:

curl -H "Accept: text/plain" https://icanhazdadjoke.com/

icanhazdadjoke curl вывод

Аргумент командной строки -H позволяет включать один параметр, который в данном случае является «Accept: text/plain», из дополнительного заголовка в запросе. Эта модификация позволяет вам указать тип вывода вашего запроса, который здесь будет просто текстом. Вы также можете установить его в JSON ( Accept: text/html) или HTML ( Accept: Application/json), если вам это нужно.

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

документация icanhazdadjoke API

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

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

Главный сайт Evil Insult Generator

… этот сайт подлый.

Предпосылка действительно проста: вы вызываете API и получаете оскорбление.

Документация по API Evil Insult Generator

Как и в случае с API козла, мне особо нечего сказать здесь.

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

https://evilinsult.com/generate_insult.php?lang=es&type=json

Результат вызова API Evil Insult Generator

«Mala leche» буквально переводится с английского как «плохое молоко». В разговорной речи вы используете его, чтобы описать кого-то, кто действует недобросовестно, или кого-то в плохом настроении.

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

И это все!

Я надеюсь, вы попробуете поработать с одним из них, когда начнете знакомиться с API или просто ищете что-то интересное для работы. Обязательно ответственно обращайтесь к API, поскольку они общедоступны и предназначены для бесплатного использования всеми. Слишком частое пингование их может привести к блокировке вашего IP-адреса, что, если вам нравятся картинки с козами (или какой-либо другой сервис, который вы используете), не будет хорошо.

Безопасность REST API от А до ПИ / Хабр

Введение

Умение реализовать грамотное REST API — полезный навык в наше время, т.к. все больше сервисов предоставляют свои возможности с помощью API. Но разработка REST API не ограничивается реализацией HTTP запросов в определенном стиле и формированием ответов в соответствии со спецификацией. Задача обеспечения безопасности REST API не так очевидна, как, например, обеспечение безопасности баз данных, но ее необходимость не менее важна.
В настоящее время многие онлайн системы с помощью API передают приватные данные пользователей, такие как медицинские или финансовые. Текущая же ситуация с безопасностью в веб-приложениях весьма печальна: по данным Comnews порядка 70% содержат кри­тичес­кие уязвимости. Поэтому всем, кто участвует в проектировании, реализации и тестировании онлайн систем, важно иметь общую картину по существующим угрозам и способам обеспечения безопасности как всей системы, так и используемого REST API.

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

Стандарты безопасности

Начнем со стандартов. Существует несколько стандартов, которые помогут нам сформулировать список требований к безопасности API:

OWASP (Open Web Application Security Project) известна своими списками рисков в разных программных технологиях. Нам интересен список «10 наиболее опасных уязвимостей при разработке API»:

• API1:2019 Broken Object Level Authorization (Недостатки контроля доступа к объектам). Другое название этого риска: Insecure Direct Object References (Небезопасные прямые ссылки на объекты)
• API2:2019 Broken User Authentication (Недостатки аутентификации пользователей)
• API3:2019 Excessive Data Exposure (Разглашение конфиденциальных данных)
• API4:2019 Lack of Resources & Rate Limiting (Отсутствие проверок и ограничений)
• API5:2019 Broken Function Level Authorization (Недостатки контроля доступа на функциональном уровне)
• API6:2019 Mass Assignment (Небезопасная десериализация)
• API7:2019 Security Misconfiguration (Некорректная настройка параметров безопасности)
• API8:2019 Injection (Внедрение)
• API9:2019 Improper Assets Management (Недостатки управления API)
• API10:2019 Insufficient Logging & Monitoring (Недостатки журналирования и мониторинга)

Добавлю пункты, которые не вошли в Top10, но относятся к нашей теме:
А также уязвимости из списка другой организации Common Weakness Enumeration (CWE): CWE Top 25 Most Dangerous Software Errors:

• CWE-79 Cross-site Scripting (XSS) (Межсайтовое выполнение сценариев)
• CWE-352 Cross-Site Request Forgery (CSRF) (Межсайтовая подмена запросов)

И несколько пунктов из других найденных списков:

• Insecure Cookies and Local Storage (Небезопасные Cookies и Local Storage)
• Insecure HTTP Headers (Небезопасные HTTP заголовки)
• Improper Cross-origin resource sharing (Неправильное использование CORS)
• Clickjacking (Подмена кликов)

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

API2:2019 — Broken User Authentication (Недостатки аутентификации пользователей)

Тема аутентификации пользователей идет на втором месте в списке OWASP, но я ее поставил на первое, т.к. с этого все начинается. Современные стандарты аутентификации и авторизации я уже рассматривал в своей статье про OAuth 2.0, OpenID Connect, WebAuthn. Здесь кратко опишу основные схемы безопасности и рассмотрим более подробно наиболее надежную на данный момент схему, основанную на токенах.

API key

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

Basic Authentication

В Basic Authentication используется аутентификация по двум строкам, например логину/паролю.

Для передачи информации используется HTTP заголовок ‘Authorization’ с ключевым словом Basic далее пробел и base64 закодированная строка username:password. Например:

Authorization: "Basic dXNlcm5hbWU6cGFzc3dvcmQ="

Cookie-Based Authentication

Cookie-Based Authentication использует механизм передачи Cookies в HTTP запросах. В ответ на запрос клиента сервер посылает заголовок Set-Cookie, который содержит имя и значение cookie, а также дополнительные атрибуты: expires, domain, path, secure, httponly. Пример отправки cookie:

Authorization: Set-Cookie: JSESSIONID=123456789; Path=/; HttpOnly

После этого клиент автоматически будет посылать заголовок Cookie при каждом запросе:

Cookie: JSESSIONID=123456789

Для реализации этого механизма необходимо на сервере организовать хранение и проверку сессий пользователей. Подробнее использование Cookies рассмотрено в разделе «Insecure Cookies and Local Storage»

Token-Based Authentication

Также называют Bearer Authentication.

Token-Based Authentication использует подписанный сервером токен (bearer token), который клиент передает на сервер в заголовке Authorization HTTP с ключевым словом Bearer или в теле запроса. Например:

Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjI4Y

При получении токена сервер должен проверять его на валидность — что пользователь существует, время использования не прошло и т.д. Token-Based Authentication может использоваться как часть OAuth 2.0 или OpenID Connect протоколов, так и сервер сам может сформировать токен.

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

Алгоритм Token-Based Authentication

Разберем подробнее последнюю из описанных схем. На схеме представлен упрощенный алгоритм Token-Based Authentication на примере реализации возможности «Зайти с помощью Google аккаунта»

1. Пользователь заходит на сайт и нажимает кнопку «Зайти с помощью Google аккаунта»
2. Сервер посылает запрос на Google.
3. Google показывает пользователю свою форму логина.
4. Пользователь вводит логин/пароль.
5. Google проверяет логин/пароль и отправляет на наш сервер приложений access token и refresh token.
6. Для аутентификации сервер расшифровывает token или получает информацию о пользователе по Google API.
7. Далее сервер находит пользователя в своей базе, сообщает об успешной аутентификации и сохраняет токены в локальном хранилище пользователя для реализации возможности «Запомнить меня на этом устройстве». В каком конкретно: Local Storage, Session Storage или Cookies, решается в зависимости от требований бизнеса и безопасности. OWASP склоняется к Cookies с реализацией дополнительных механизмов безопасности: JSON Web Token Cheat Sheet. Нужно ли генерировать дополнительный «session token», где его хранить и как использовать — также должно определяться бизнесом, для которого реализуется система.
8. После этого при каждом запросе к серверу клиент будет передавать access token в запросе, а наш сервер проверять его на валидность в Google и только после этого передавать запрошенные данные.
9. При окончании срока действия access токена сервер использует refresh токен для получения нового.

Какие плюсы Token-Based Authentication для сервера приложений:

1. Не надо хранить пароли в базе данных на сервере, таким образом сразу избавляемся от уязвимости Insecure Passwords.
2. В некоторых случаях можно вообще избавиться от базы данных на сервере и получать всю необходимую информацию из Google или других систем.
3. Нет проблем с безопасностью, характерных для остальных методов:

• При компрометации логина/пароля доступ к данным получается сразу и длится пока пользователь сам не заметит факт взлома, у токенов же есть время жизни, которое может быть небольшим.
• Токен автоматически не уйдет на сторонний сайт, как Cookie.
• Cookie-Based Authentication подвержена атаке Cross-Site Request Forgeries (CSRF) и, соответственно, необходимо использовать дополнительные механизмы защиты.
• Можно не хранить сессию пользователя на сервере, а токен проверять каждый раз в Google.

Минус видится один:

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

API1:2019 Broken Object Level Authorization (Недостатки контроля доступа к объектам)

Другое название этого риска: Insecure Direct Object References (Небезопасные прямые ссылки на объекты). Это самая распространенная проблема с API в настоящее время. Для иллюстрации приведу API, которое в дальнейшем использую еще для нескольких примеров уязвимостей.

Получить одного пользователя с userID:

GET /users/{userID}

Получить всех пользователей (может только администратор):

GET /users

Удалить пользователя c userID: DELETE /users/{userID}

DELETE /users/1

Итак, если вызывается команда удаления пользователя:

DELETE /users/1

То необходима проверка, что эту команду может вызвать только сам пользователь 1 или администратор, а не, например, пользователь 2 от своего имени, просто изменив значение ID в вызове команды. Чтобы избежать подобных проблем нужно:

• Проверять права доступа к объектам при каждом запросе.
• Проверять, что залогиненный пользователь имеет доступ только к разрешенным объектам.
• ID объектов должны быть сложными для подбора, например в виде UUID, а не простая последовательность 1, 2, 3.

OWASP рекомендует (Access Control Cheat Sheet) следующие модели обеспечения контроля доступа:

• Role-Based Access Control (RBAC)
• Discretionary Access Control (DAC)
• Mandatory Access Control (MAC)
• Permission Based Access Control

API5:2019 Broken Function Level Authorization (Недостатки контроля доступа на функциональном уровне)

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

GET /users/all

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

API3:2019 Excessive Data Exposure (Разглашение конфиденциальных данных)

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

GET /users/1

может вернуть не только имя / возраст, но и ответ на секретный вопрос, который пользователь задал во время регистрации:

{"userName":"Alex","age":25,"secretAnswer":"HelloWorld"}

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

API6:2019 Mass Assignment (Небезопасная десериализация)

В данном случае ситуация обратная предыдущему пункту Excessive Data Exposure — лишние данные передаются на сервер с целью несанкционированной замены значений. Как это понимать? Предположим у нас есть пользователь-хакер с ID 1 со следующими данными:

{"userName":"Alex","age":25,"balance":"150"}

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

Но наш сервер подвержен атаке Mass Assignment и без проверок источника записывает все пришедшие данные. Наш пользователь-хакер может отправить на сервер запрос на изменение возраста, в который добавляет дополнительный атрибут balance:

POST /users/1

{"userName":"Alex","age":26,"balance":"1000000"}

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

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

API4:2019 Lack of Resources & Rate Limiting (Отсутствие проверок и ограничений)

Необходимо защитить сервер от атак по подбору пароля (brute force attack). Для этого нужно реализовать следующие ограничения:

• Ограничить число неудачных попыток авторизации одного пользователя. Как вариант использовать reCapture или аналогичный механизм.
• Блокировать IP, если число неудачных попыток с него превысило определенное значение по всем пользователям.

Для JS существуют средства, позволяющие делать такие проверки автоматически (например, Rate limiter) и сразу посылать ответ «429 Too Many Requests», не нагружая сервер.

Необходимо защитить сервер и от отказа в обслуживании (DoS-атаки)

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

Например, сервер ожидает в параметре size число записей:

/api/users?page=1&size=100

Если на сервере отсутствует проверка size на максимальное значение, то передача в параметре злоумышленником, например, 1 000 000 может привести к исчерпанию памяти на сервере и отказу в обслуживании. Поэтому нужно проверять на сервере все значения параметров на допустимые, даже если на нашем клиенте есть такие проверки. Ведь никто не помешает вызвать API напрямую.

API7:2019 Security Misconfiguration (Некорректная настройка параметров безопасности)

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

• Используются дефолтные настройки приложений, которые могут быть небезопасны.
• Используются открытые хранилища данных.
• В OpenSourсe попала закрытая информация, например, конфигурация системы или параметры доступа.
• Неправильно используются регулярные выражения, что позволяет провести атаку ReDoS (Regular expression Denial of Service)
• Неправильно сконфигурированы HTTP заголовки (данная тема рассмотрена далее в разделе «Insecure HTTP Headers»).
• Аутентификационные данные (логин/пароль, токен, apiKey) посылаются в URL. Это небезопасно, т.к. параметры из URL могут оставаться в логах веб серверов.
• Отсутствует или неправильно используется политика Cross-Origin Resource Sharing (CORS) (данная политика рассмотрена далее в одноимённом разделе).
• Не используется HTTPS (использование HTTPS рассмотрено в разделе «Insecure Transport»).
• При эксплуатации промышленной системы используются настройки, предназначенные для разработки и отладки.
• Сообщения об ошибках содержат чувствительную информацию, например, трейсы стека.

Также необходимо уделять внимание конфигурации облачных сервисов:

• Для пользователей устанавливать только необходимые права доступа.
• Открывать только необходимые сетевые порты.
• Устанавливать безопасные версии патчей OS и приложений (подробно рекомендации рассмотрены в разделе «Using Components with Known Vulnerabilities»).

API8:2019 Injection (Внедрение)

Внедрение — это выполнение программного кода, не предусмотренного системой. Разделяют внедрения:

• SQL команд
• Команд OS

Атака будет успешна, если сервер выполняет полученные команды без проверки. Чем-то напоминает «небезопасную десериализацию», только используются не дополнительные атрибуты, а SQL код или команды OS. В результате SQL инъекции можно получить несанкционированный доступ к данным. С помощью инъекции команд OS можно получить доступ к серверу или вывести его из строя. Например, в строке ввода пользователь ввел имя каталога «name» и на сервер посылается команда:

GET /run

{"mkdir":"name"}

Если сервер выполняет команды без проверки, то злоумышленник может послать следующую команду с большой вероятностью вывода сервера из строя:

GET /run

{"mkdir":"name && format C:/"}

Для предотвращения подобных атак:

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

API9:2019 Improper Assets Management (Недостатки управления API)

API может иметь несколько точек входа (endpoints) с разными версиями и функциональными назначениями. Например:

http://localhost:5000/myAPI/v1

http://localhost:5000/myAPI/v2

http://localhost:5000/myTestAPI/v1

Необходимо обеспечить учет и контроль версий API:

• Нужно вести список имеющихся API, их версий, назначение (production, test, development) и кто имеет к ним доступ (public, internal, partners).
• Необходимо управлять жизненным циклом API и своевременно запускать новые версии, снимать с поддержки старые.
• В открытом доступ выставлять только актуальные версии API.
• Не оставлять в открытом доступе endpoints, предназначенные для отладки.

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

API10:2019 Insufficient Logging & Monitoring (Недостатки журналирования и мониторинга)

Чтобы выявить атаку или подозрительное поведение пользователей, систему надо мониторить, а события логировать с достаточным уровнем подробности:

• Логировать все неудачные попытки аутентификации, отказы в доступе, ошибки валидации входных данных.
• Обеспечить целостность логов, чтобы предотвратить возможность их подделки.
• Мониторить надо не только приложения и вызовы API, но и инфраструктуру, сетевую активность, загрузку OS.
• Необходимо обеспечить не только мониторинг, но и оперативное оповещение о нарушениях штатной работы системы.
• Общие советы по мониторингу можно посмотреть в статье Monitoring Done Right

Insecure Transport (Небезопасный транспортный уровень)

Если не шифровать трафик между клиентом и сервером, то все HTTP данные и заголовки будут передаваться в открытом виде. Чтобы предотвратить утечку данных, надо использовать протокол HTTPS (Hyper Text Transfer Protocol Secure) или реализовывать шифрование самостоятельно. Для использования HTTPS нужен SSL-сертификат. Сайты в интернете должны получать такие сертификаты в доверительных центрах выдачи сертификатов CA (Certificate Authority). Но для целей шифрования данных между нашим клиентом и сервером можно поступить проще:

• Самостоятельно сгенерировать, так называемый, self-signed сертификат.
• На сервере настроить использование HTTPS протокола.
• С клиента формировать запросы, начинающиеся с https.

Браузер, конечно, будет ругаться, что сертификат сервера подписан не известно кем, но мы-то можем сами себе доверять).

Обеспечить поддержку HTTPS можно также средствами Apache, Nginx или других веб-серверов.

Insecure Passwords (Небезопасные пароли)

С этой темой все просто:

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

Insecure Cookies and Local Storage (Небезопасные Cookies и данные в Local Storage)

Cookies должны использоваться безопасно:

• Нельзя использовать дефолтные имена.
• При создании Cookies следует устанавливать следующие опции:

secure - браузер будет отправлять cookies только по HTTPS протоколу.
httpOnly - браузер будет отправлять cookies только по HTTP или HTTPS и не отправлять при запросах из JavaScript, что предотвратит атаки Cross-site Scripting (XSS).
domain - определяет domain cookie.
path - определяет path cookie.
expires - определяет дату устаревания cookies.
SameSite - браузер будет отправлять cookies только тому сайту, который их установил.

• Европейские сайты должны явно спрашивать разрешение у пользователя о применении Cookies. Так как, например, если в Cookies записать последовательность действий пользователя на сайте, то это уже считается персональной информацией.

Общие правила безопасности для Cookies и Local Storage:

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

Using Components with Known Vulnerabilities (Использование компонент с известными уязвимостями)

Компоненты, такие как библиотеки и framework-и выполняются с теми же привилегиями, что и приложение. Поэтому если среди используемых библиотек окажется небезопасный компонент, то это может привести к захвату или выводу из строя сервера. Для проверки безопасности компонент используются специальные приложения, например, для JavaScript можно использовать Retire.

CWE-79 Cross-site Scripting (XSS) (Межсайтовое выполнение скриптов)

Межсайтовое выполнение скриптов считается самой опасной web-атакой. Суть ее в том, что вредоносный скрипт может быть внедрен в нашу страницу, а результат выполнения может привести к утечке конфиденциальных данных или к повреждению сервера. Чтобы защититься от атаки в запрос надо включить HTTP заголовок, который включает Cross-site scripting (XSS) фильтр:

X-XSS-Protection : 1; mode=block

или

Content-Security-Policy: script-src 'self'

CWE-352 Cross-Site Request Forgery (CSRF) (Межсайтовая подмена запросов)

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

Финансовый сайт успешно проверяет валидность Cookies и выполняет несанкционированную транзакцию. Для защиты от атак CSRF надо:

• На сервере реализовать механизм «CSRF токенов». Это такой механизм, когда для каждой сессии пользователя генерируется новый токен и сервер проверяет его валидность при любых запросах с клиента.
• На сервере проверять заголовки Origin и Referer, в которых содержится адрес источника запроса. Но эти заголовки могут отсутствовать.
• Также можно всегда требовать от пользователя подтверждать критические действия вводом пароля или вторым фактором аутентификации, но возможность таких мер зависит от бизнеса.
• При создании Cookies выставлять параметр SameSite, но этот механизм поддерживают не все браузеры.

Cross-origin resource sharing (CORS) (Кросс-доменное использование ресурсов)

CORS — это механизм безопасности, который позволяет серверу задать правила доступа к его API. Например, если на сервере установить заголовок:

Access-Control-Allow-Origin: *

то это позволит использовать API без ограничения. Если это не публичное API, то для безопасности надо явно устанавливать Origin-ы, с которых разрешен доступ к API, например:

Access-Control-Allow-Origin: https://example.com:8080

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

Access-Control-Allow-Methods: GET, POST, DELETE, PUT

И задать список заголовков, которые сервер может принимать:

Access-Control-Allow-Headers: Origin, Content-Type, Authorization

Insecure HTTP Headers (Безопасность HTTP заголовков)

HTTP протокол включает в себя большое число заголовков, которые можно использовать в HTTP запросах/ответах. Для того, чтобы определить наиболее важные заголовки с точки зрения обеспечения безопасности, я использовал несколько списков:
Далее рассмотрим основные заголовки:

X-Powered-By

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

X-Powered-By: Express

Отсутствие этого заголовка, конечно, никого не остановит, но сразу давать такую подсказку не стоит. Поэтому передачу этого заголовка надо запретить.

HTTP Strict Transport Security (HSTS)

Strict-Transport-Security заголовок запрещает браузеру обращаться к ресурсам по HTTP протоколу, только HTTPS:

Strict-Transport-Security: max-age=31536000

max-age=31536000 — это год в секундах. Рекомендуется выcтавлять этот заголовок, т.к. он предотвратит атаки, связанные с принуждением браузера перейти на HTTP протокол и начать передавать информацию (например cookies) в открытом виде, которую может перехватить злоумышленник. Запрос к серверу по HTTP и атака возможна только при первом обращении к серверу, при последующих браузер запомнит настройку Strict-Transport-Security и будет обращаться только по HTTPS.

X-Frame-Options (защита от Clickjacking)

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

X-Frame-Options: deny

или разрешить использование только в нашем домене:

X-Frame-Options: sameorigin

А лучше для предотвращения атаки Clickjacking использовать более современный механизм и установить правильную политику безопасности Content-Security-Policy

Content-Security-Policy

Позволяет защититься от атаки Cross-site scripting и других кросс-сайтовых инъекций, в том числе Clickjacking. Требует вдумчивого конфигурирования, т.к. параметров много. Но надо хотя бы поставить дефолтную политику, что предотвратит возможность атаки Cross-site Scripting:

Content-Security-Policy: default-src 'self'

Подробно значения заголовка Content-Security-Policy разбираются, например, по ссылке.

X-Content-Type-Options

Установка данного заголовка запрещает браузеру самому интерпретировать тип присланных файлов и принуждает использовать только тот, что был прислан в заголовке Content-Type. Без этого возможна ситуация, когда, например, посылается безобидный на вид txt файл, внутри которого вредоносный скрипт и браузер его выполняет как скрипт, а не как текстовой файл. Поэтому устанавливаем:

X-Content-Type-Options: nosniff

Cache-Control

Cache-Control позволяет управлять кешом на стороне клиента, рекомендуется запретить кеширование, чтобы в кеше случайно не оставались приватные данные:

Cache-Control: no-store

Заключение

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

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

Ссылки на использованные списки:

Желаю всем легкодоступных, но безопасных API! )

It’s only the beginning!

чего ждать банкам? » Журнал ПЛАС №9

Тема открытого банкинга все чаще становится предметом активной полемики среди экспертов. В рамках митапа, организованного Frank RG, на тему перспектив открытого банкинга, свое мнение высказали ряд наиболее активных игроков рынка.

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

APIBank: если думать не глобально,
внедрение открытых банковских API невыгодно

Алексей Петров
сооснователь и CEO открытой банковской платформы APIBank

Мы часто сталкиваемся с подменой понятий: что такое Oрen Banking и что такое Open API. Последнее – это инструмент, который может быть использован для любого банковского блока: розницы, работы с МСП или транзакционного бизнеса. А понятие Open Banking в восприятии банка должно быть связано с отдельным направлением деятельности, у которого свой собственный KPI. И зарабатывать оно будет с помощью инструмента Open API.

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

Или когда мы общаемся с представителем среднего банка, у которого есть KPI по количеству клиентов, он сужает понятие открытых банковских API до еще одного источника пополнения своей базы, при этом вся иде­ология открытого банкинга сводится к лидогенерации. Когда мы объясняем, что платформа открытых API не поставляет лиды, большинство все равно воспринимает наше решение именно в этой парадигме.

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

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

Пока банки не станут воспринимать Oрen Banking в более широком смысле и не включат его в свои стратегии развития как отдельное направление бизнеса, цифровой революции в банковском секторе России не случится.

Что касается регулирования и работы по стандартизации Open API, которая сейчас ведется Ассоциацией Финтех совместно с Банком России, – эти инициативы направлены на создание единых и прозрачных правил игры, что, конечно, значительно облегчит взаимодействие между всеми игроками. Не нужно будет каждый раз изобретать велосипед: все бесконечные итерации по согласованию договоров сведутся к подписанию стандартного пакета документов. Компания сможет самостоятельно интегрироваться с банком или с платформой, стать частью их экосистемы или создавать свой финансовый продукт на инфраструктуре банка или открытой банковской платформы.

Тинькофф Инвестиции: Open API позволяет
повышать конкурентоспособность банка

Павел Пермяков
руководитель отдела архитектуры интеграционных решений Тинькофф Инвестиции

Open API – создание дополнительной ценности для клиента. Если компания не имеет средств для создания какой-либо части своего будущего продукта и не хочет инвестировать в ее разработку, то именно в таких целях можно использовать открытые API. Открытый интерфейс с успехом может применять молодой банк, у которого нет собственного мобильного приложения, хорошего веб-интерфейса, он может имплементировать протокол, который разрабатывается АФТ или регулятором. И в результате – получать качественный интерфейс для своих продуктов, продавать их на чужой площадке, тем самым повышая свою конкурентоспособность.

TalkBank: регулятор не должен
все время объяснять банку, «куда бежать»

Михаил Попов
CEO, основатель TalkBank

Open Banking для нас – возможность расширять сотрудничество с банками, увеличивать диверсификацию бизнеса, чтобы не быть привязанным к одному конкретному банку. Я хотел бы отметить, что чрезмерная регуляция этого вопроса, на мой взгляд, излишня. Ситуация, когда регулятор должен все время объяснять банку, «куда бежать», тормозит процесс развития. Должны работать рыночные механизмы, когда банк сам заинтересован развивать API. По идее, сам бизнес должен рекомендовать стратегию и выбор правильного вектора движения.

Также я бы разделял Open API и просто API. В первом случае можно быстро подключиться к API и без лишних согласований начать работать. Во втором случае необходимо согласование, прежде чем начнется работа через API. Если говорить о TalkBank Platform, то мы к В2C-направлению в 2019 году добавили B2B. Мы предоставляем API и услугу Bank as a Service (BaaS, банк как услуга) заинтересованным сторонам (финтех, ритейл, агрегаторы, маркетплейсы). Поскольку к нашей платформе подключены несколько банков, то нашим партнерам мы можем предложить самую гибкую систему API, интеграцию различных платежных методов. Это позволяет строить удобные банковские решения для партнеров и их конечных клиентов.

АФТ: в первой версии спецификации
мы планируем выпустить набор из 15 API

Игорь Рамазанов
руководитель направления
«Развитие открытых API» Ассоциации ФинТех

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

Безусловно, среди экономически выгодных моментов – стоимость и скорость внедрения новых партнерских сервисов, возможность развития новых инструментов управления в банках, bank as a service, возможность передачи персональных данных именно с правовой точки зрения, а также в плане обеспечения безопасности.

В 2017 году Банк России выпустил документ «Основы управления развитием финансовых технологий», который, по сути, стал неким фундаментом для развития технологий в России, таких как ЕБС, СБП, цифровой профиль гражданина. В дорожной карте есть и пункт, связанный с открытыми API. В августе 2019 года Наблюдательный совет Ассоциации ФинТех согласовал концепцию развития открытых API, которая определяет все нюансы дальнейшего развития технологии.

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

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

Мы хотим этот стандарт апробировать на реальных кейсах с бан

API OpenAI

FAQ

Почему OpenAI решила выпустить коммерческий продукт?

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

Мы также считаем, что безопасное развертывание мощных систем искусственного интеллекта в мире будет непросто. Выпуская API, мы тесно сотрудничаем с нашими партнерами, чтобы увидеть, какие проблемы возникают, когда системы ИИ используются в реальном мире.Это поможет нам понять, как будет разворачиваться будущее систем искусственного интеллекта и что нам нужно сделать, чтобы они были безопасными и полезными для всех.

Почему OpenAI решил выпустить API вместо того, чтобы открывать исходный код моделей?

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

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

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

Что конкретно OpenAI будет делать в случае неправильного использования API, учитывая то, что вы ранее говорили о GPT-2?

Что касается GPT-2, одной из наших основных проблем было злонамеренное использование модели (например, для дезинформации), которое трудно предотвратить, если модель имеет открытый исходный код. Что касается API, мы можем лучше предотвратить неправомерное использование, ограничив доступ одобренными клиентами и вариантами использования. У нас есть обязательный производственный процесс проверки, прежде чем предлагаемые приложения могут быть запущены. В производственных обзорах мы оцениваем приложения по нескольким направлениям, задавая такие вопросы, как: Поддерживается ли этот вариант использования в настоящее время? , Насколько открыто приложение? , Насколько рискованно приложение? , Как вы планируете бороться с потенциальным злоупотреблением? и Кто являются конечными пользователями вашего приложения? .

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

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

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

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

Смягчение негативных последствий, таких как вредная предвзятость, является сложной задачей всей отрасли, которая чрезвычайно важна. Как мы обсуждали в документе GPT-3 и модельной карточке, наши модели API демонстрируют предвзятость, которая будет отражена в сгенерированном тексте. Вот шаги, которые мы предпринимаем для решения этих проблем:

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

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

Обновлено 18 сентября 2020 г.

.

230 API открытых данных (2020)

.

разработчиков / API | Открытая библиотека

Open Library разработала набор API, чтобы помочь разработчикам начать работу с нашими данными. Мы призываем заинтересованных разработчиков присоединиться к списку рассылки ol-tech, чтобы быть в курсе последних новостей, или погрузиться в нашу собственную команду разработчиков в нашем трекере ошибок или в нашем репозитории исходного кода GitHub.

API

Open Library имеет RESTful API , который лучше всего использовать для связи с данными Open Library в JSON, YAML и RDF / XML.Также существует более ранний JSON API, который сейчас устарел. Это сохранено только для обратной совместимости.

Вы также можете вернуть библиографические данные, просто добавив расширение .rdf / .json / .yml в конец любого библиографического идентификатора OL. На страницах также есть ссылки на RDF и JSON-версии работ, редакций и авторов.

Читать API

Массовый доступ к записям

Наш API не должен использоваться для массовой загрузки данных из открытых библиотек. Если вам нужен дамп полных данных, ознакомьтесь с вариантами массовой загрузки или напишите нам по адресу info @.

Открытая библиотека в дикой природе

Несколько разработчиков создают удивительные вещи с помощью API открытых библиотек:

• Trove от Национальной библиотеки Австралии
  Trove — это новое открытие, ориентированное на Австралию и австралийцев. Он дополняет то, что предоставляют поисковые системы, надежной информацией из учреждений памяти Австралии. Система переходит в открытую библиотеку, когда в результатах поиска появляются общедоступные книги, и отображает ссылки на открытую библиотеку.

• Koha
  Koha — это библиотечная система с открытым исходным кодом для публичных библиотек, которая включает поиск по каталогам и организацию участников. Он использует обложки Open Library, отображает темы, связанные с OL, и электронные книги, которые можно взять напрокат с помощью Read API.

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

• read.gov by Библиотека Конгресса
  Хорошо, это не совсем открытая библиотека, но все равно потрясающе! Библиотека Конгресса изменила программу чтения книг Интернет-архива, чтобы она идеально вписывалась в свой сайт коллекции редких книг.

• Подключаемый модуль OpenBook для WordPress от John Miedema
  OpenBook полезен для всех, кто хочет добавить обложки книг и другие данные о книгах на веб-сайт WordPress.OpenBook ссылается на подробную информацию о книге в Open Library, основном источнике данных, а также на других книжных сайтах. Пользователи имеют полный контроль над отображением с помощью шаблонов. OpenBook может ссылаться на записи библиотеки, настроив преобразователь OpenURL или через ссылку WorldCat. OpenBook вставляет COinS, чтобы другие приложения, такие как Zotero, могли получать данные книги.

• Подключаемый модуль поиска для Firefox с открытой библиотекой от Джефф Каплан
  Поиск в открытой библиотеке с панели инструментов Firefox!

• Umlaut by Jason Ronallo
  Umlaut — средство определения ссылок OpenURL среднего уровня, которое добавляет функции и услуги в коммерческое программное обеспечение для разрешения ссылок.

• Виртуальная полка , автор Джонатан Брейтбарт и Девин Блонг (Информационная школа Калифорнийского университета в Беркли)
  Виртуальная полка — это визуализация, созданная двумя студентами Информационной школы Калифорнийского университета в Беркли. Проект включает в себя магистерскую диссертацию студента с исследованием моделей поиска и просмотра посетителей библиотеки. RESTful API Open Library использовался во время проекта в качестве источника метаданных для пользовательского интерфейса.

• RDC UI Toolkit от Rural Design Collective
  Эта группа создала набор инструментов, которые облегчают создание локализованных пользовательских интерфейсов для книг, находящихся в свободном доступе.RDC использовал API Open Library Covers и Internet Archive Book Reader в своей онлайн-демонстрации, адаптированной для OLPC XO.

Используете ли вы API открытых библиотек? Мы будем рады услышать об этом! Напишите нам по адресу info @.

.