The Open Banking Standard - свежий стандарт предоставления API британскими банками. Его активно продвигает ODI в последнее время и похоже что успешно продвинут #opendata #openapi

Это даже не новость, а непрерывный развивающийся тренд о котором нельзя не написать. Спецификация стандарта для публикации API - Swagger [1] в январе этого года вошла полностью в инициативу OpenAPI [2] и теперь развивается в при поддержке большого числа крупнейших ИТ игроков вошедших в консорциум.

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

Сссылки:
[1] https://swagger.io
[2] https://www.openapis.org

#opendata #opengov #openapi

Talend [1], разработчики ETL продуктов по работе с данными, покупают стартап Restlet [2] ориентированный на создание удобной документации и описания API по стандарту Swagger (Open API).

Как давний пользователь Restlet надеюсь что это послужит развитию сервиса, а не потерей им каких-либо текущих функций.

Ссылки:
[1] https://www.talend.com
[2] https://restlet.com/company/blog/2017/11/27/restlet-is-now-part-of-talend/

#opendata #opengov #openapi

В рубрике интересные наборы данных, большой набор данных по распознаванию еды [1] в рамках конкурса Food Recognition Challenge [2]. Конкурс тоже интересный, 10 тысяч швейцарских фунтов команде сделавшей алгоритм с точностью > 0.70.

А в наборе данных 1.16ГБ из 24,119 изображений с 39,325 сегментами для 273 различных классов. Всё под лицензией CC-BY 4.0

Проект делается по инициативе Digital Epidemiology Lab [3] и у них же огромный проект по краудсорсингу сведений о еде, The Open Food Repo [4] с охватом 374,104 продуктов из 5-х стран США, Швейцария, Италия, Германия, Франция. У проекта нет наборов данных, но есть общедоступное API, активно применяемое пользователями.

Ссылки:
[1] https://www.aicrowd.com/challenges/food-recognition-challenge/dataset_files
[2] https://www.aicrowd.com/challenges/food-recognition-challenge
[3] https://www.digitalepidemiologylab.org
[4] https://www.foodrepo.org/

#opendata #food #datasets #openapi

OpenAI, разработчики языковой модели GPT-3 о которой так много писали и пишут и которую активно используют в многочисленных демо проектах и экспериментах основанных на понимании языка, убрали лист ожидания к своему API [1] для списка поддерживаемых или стран. Это хорошая новость. Плохая новость в том что России в этом списке стран нет [2]. Вернее даже что из всего постсоветского пространства там нет России, Украины, Киргизстана, Таджикистана, Туркменистана и Беларуси, но есть Казахстан и Армения, к примеру. Китая, кстати, тоже нет в списке.

Чем вызван такой выбор стран непонятно.

Ссылки:
[1] https://openai.com/blog/api-no-waitlist/
[2] https://beta.openai.com/docs/supported-countries

#ai #openapi #openai

Я регулярно пишу о том что у многих информационных систем и иных публичных ресурсов государства есть много недокументированных API. Причём эти API имеют, как правило, две истории происхождения:
a) API сделанные разработчиками для работы каких-то компонентов и ни разу не документированные, например, если сайт сделан с использованим Ajax технологии.
б) API предусмотренное изначально создателем платформы выбранной разработчиками. Например, API использованной CMS.

Приведу примеры того в какой форме такое API бывает.

Сайт Финансового университета fa.ru сделан на Sharepoint, CMS от Microsoft чаще используемой для внутри-корпоративных сайтов и реже для сайтов в Интернете. У последних версий Sharepoint доступ к данным осуществляется через API по ссылке "/_api". Для Финуниверситета это www.fa.ru/_api/ и по этой ссылке можно далее, особенно если почитать документацию на Sharepoint, осуществлять навигацию по сайту. Обычно это начинается со ссылки www.fa.ru/_api/web где по расширенному протоколу Atom отдаётся описание хранящихся в списках сайта материалов.

Сайт Рособрнадзора obrnadzor.gov.ru сделан на CMS Wordpress. Wordpress - это одна из наиболее популярных CMS в мире, скорее всего наиболее популярная. Вот уже несколько версий в этой CMS есть специальная ссылка "/wp-json/" позволяющая получать данные содержимого сайта (не вёрстки, а контента!) в машиночитаемом виде. Поэтому и содержание сайта Рособрнадзора можно выкачать специальным краулером по адресу obrnadzor.gov.ru/wp-json/ . Кроме Рособрнадзора на Wordpress созданы сайты ещё многих сайтов.

У Санкт-Петербургского государствнного университета есть система Архива публичного доступа dspace.spbu.ru как кто-то уже догадался, сделанный на платформе DSPace используемой тысячами научных и иных организаций по всему миру. У DSPace есть API, вполне документированное, но не выносимое на главные страницы инсталляции платформы, доступное по ссылке "/rest/". В случае СПбГУ это ссылка на API dspace.spbu.ru/rest/.

DSPace используется не только ВУЗами, но и межгосударственными организациями такими как Всемирная организация здравоохранения. ВОЗ публикует свои материалы в системе IRIS, Институциональное хранилище для обмена информацией. IRIS, также, создано на базе DSPace и открыто его API apps.who.int/iris/rest/

Недокументированные API оставленные разработчиками присутствуют, например, на сайтах Мэра и Правительства Москвы www.mos.ru и портала Электронный бюджет budget.gov.ru из-за чего они плохо индексируются поисковыми системами. Сами API можно выявить просматривая запросы браузера к страницам сайтов.

Федеральная пробирная палата отдаёт все страницы на своём официальном сайте probpalata.ru из-за использования в качестве CMS движка для документооборота. Об этом я писал отдельно https://t.iss.one/begtin/3283, до сих пор удивляюсь этой истории.

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

Из всего этого я обращаю внимание на следующее:
1) Фактическая доступность данных часто выше чем наблюдаемая (документированная) доступность.
2) Системной работы над доступностью данных и програмнных интерфейсов из госсистем у нас в стране всё ещё нет. Нет аналогов платформ API как в других странах.
3) Конечно, API, не заменяет возможно массовой выгрузки (bulk download) данных. Иногда, даже при доступности такого API, чтобы выгрузить данные надо делать миллионы запросов к системе, что может занимать долгое время при медленном отклике от системы.

#openapi #api #data #govwebsites

В рубрике больших наборов данных архив Github в некоммерческом проекте Github Archive[1]. Ежедневно, ежечасно там собирается слепок данных о 20+ событиях по репозиториям в Github. Я писал о нём ранее и всегда актуально напомнить о нём потому что данные из этого архива присутствуют уже на нескольких крупных платформах.

Их слепок на декабрь 2020 года есть на Clickhouse [2] (проект Яндекса) и с ними можно работать онлайн через веб интерфейс [3] или API. Там же у них есть есть полный слепок этих данных в виде архива на 83GB, хороший тестовый набор живых данных для тех кто хочет работать с Clickhouse с большим статическим объёмом данных.

Доступ к данным из этого архива есть и через Google BigQuery [4], он появился ещ в 2016 году если не раньше, но, судя по описанию в каталоге BigQuery не обновлялся с 2019 года. Интересно обновляется ли набор Яндекса? Кстати, надо бы проверить.

Всё это возможно потому что Github предоставляет открытое API для доступа к данным. Его я использовал когда-то для анализа открытого кода органов власти [5]. Я этот анализ в первый раз проводил 5 лет назад и повторял потом несколько раз, но со временем делать несколько сотен тысяч запросов к API для получения статистики стало утомительно и планировал перейти на работу через API поверх GH архива, но для этого нужно чтобы данные там были актуальны.

А также не могу не напомнить презентацию исследователей [6] ещё с 2012 года о том как можно анализировать данные Github'а для расчёта разных метрик в привязке к языкам разработки, лицензиям, организациям и тд.

А также напомню что в России немного государственного кода на Github есть в репозитории [7] который я давно поддерживаю.

Ссылки:
[1] https://gharchive.org
[2] https://ghe.clickhouse.tech/
[3] https://gh-api.clickhouse.tech/play?user=play
[4] https://console.cloud.google.com/bigquery?p=bigquery-public-data&d=github_repos&page=dataset&project=test1-162811
[5] https://data.world/ibegtin/open-source-government-project
[6] https://www.igvita.com/slides/2012/bigquery-github-strata.pdf
[7] https://github.com/infoculture/awesome-gov-opensource-russia

#opensource #opendata #openapi #datasets

В рубрике интересных наборов данных OpenSanctions [1] проект о котором я уже писал в сентябре 2021 года [2] добавил интеграцию с Wikidata [3], одним из проектов фонда Викимедиа. В Wikidata собраны многие профили политиков и теперь эти профили импортируются в OpenSanctions. В пример, ожидаемо, приводят профиль Владимира Путина [4] и Дональда Трампа [5].

Проект активно развивается, раскрывает исходный код и данные в виде наборов данных и API. У него ограничивающая лицензия CC-BY 4.0 NC и коммерческое лицензирование для бизнес пользователей. С оговоркой что для журналистов и активистов лицензия CC BY 4.0 [6]. Это не вполне открытая лицензия, но учитывая плотный рынок due diligence и того что эти правила заданы на старте проекта, вполне приемлемая.

А то что теперь подгружаются данные из Wikidata даёт шанс что проект со временем превратится в большую базу PEPs (персон с политическим влиянием) по аналогии с LittleSis.org [7], но если LittleSis был с самого начала проектом ориентированным на США, то OpenSanctions довольно универсален.

Ссылки:
[1] https://www.opensanctions.org
[2] https://t.iss.one/begtin/3074
[3] https://www.opensanctions.org/articles/2022-01-25-wikidata/
[4] https://www.opensanctions.org/entities/Q7747/
[5] https://www.opensanctions.org/entities/Q22686/
[6] https://www.opensanctions.org/licensing/
[7] https://littlesis.org

#opendata #opengov #sanctions #datasets #openapi

Один важный и очевидный продукт за отсутствие которого можно и нужно критиковать Минцифры России, как и вообще критиковать чаще за то что _не делается_ чем то что делается, это отсутствие портала api.gov.ru. Кто-то скажет что есть СМЭВ, что делается НСУД, а по факту СМЭВ и НСУД для государственного внутреннего потребления с некоторым доступом крупному бизнесу.

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

А примеры такого API собраны в коллекции документации на Postman [1] где можно найти примеры API на сайте Пр-ва Москвы, статистики госзакупок, сайте Госуслуг, портала Электронный бюджет, портала bus.gov.ru, портала pravo.gov.ru и так далее. Это примеры, а в реальности документированных и недокументированных API десятки.

Собственно я не раз уже писал что большой объём данных в DataCrafter'е выгружен через такие открытые API. Причём API нужны чаще бизнесу чем рядовым гражданам, но как-то вот нет ощущения что с доступность данных для бизнеса в повестке государства. Так что приходится собираться информацию самостоятельно, а на появление api.gov.ru пока не рассчитывать.

А вот у французов на api.gouv.fr уже собрано 112 государственных API [2] и они даже документированы и протестировать можно прямо на месте. То есть можно, если захотеть?

Ссылки:
[1] https://www.postman.com/infoculture/workspace/infoculture-public/documentation/1428203-a769e0a6-0cc9-4de4-bdcc-5f8a0fa06e36
[2] https://api.gouv.fr/rechercher-api

#openapi #opendata #government #api

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

Такие каталоги API есть во многих странах, кроме Франции и портала api.gouv.fr который я ранее упоминал, они также есть:
- В Индии API Setu apisetu.gov.in [1] - 1343 точки подключения всех уровней власти
- В Бразилии Catálogo de APIs Governamentais www.gov.br/conecta/catalogo [2] - более 40 точек подключения
- В США API Data api.data.gov [3] - сотни API по единому ключу
- В Великобритании api.gov.uk [4] более 70 API на едином портале
- В Австралии api.gov.au [5] доступно 16 API

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

Ссылки:
[1] https://apisetu.gov.in/
[2] https://www.gov.br/conecta/catalogo/
[3] https://api.data.gov/
[4] https://www.api.gov.uk
[5] https://api.gov.au

#opendata #openapi #api #government

Итого проголосовало 104 человека из которых большинство, 71% за то что нужен api.gov.ru и что хорошо бы Минцифре РФ его создать (наконец) и около 16% за то что только если в рамках частной инициативы.

По моему запрос вполне очевиден.

#opendata #openapi #government

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

Я приведу несколько примеров API на порталах органов власти и их информационных систем.

Росрыболовство
Официальный сайт органа власти (fish.gov.ru) создан на бесплатной CMS Wordpess. Сайт установлен без доп. настроек и с настройками по умолчанию, поэтому из сайта доступно техническое API Wordpress'а [1] через которое можно автоматически выгрузить все их новости, веб-страницы и тд. Похоже на неотключенную возможность у CMS.

Автоматизированная система транспортного комплекса (АСУ ТК)
Сайт АСУ ТК (asutk.ru) создан на базе CMS Sharepoint, по умолчанию API к спискам на сайте и к веб-страницам доступно по технической ссылке [2]. Не видно что API используется где-то на сайте, скорее не отключенная возможность CMS.

Портал уполномоченного органа в сфере электронной подписи
Сайт Минцифры России со сведениями о УЦ и УП (e-trust.gosuslugi.ru) предоставляет недокументированное API, например, для получения списка аккредитованных УЦ [3]. Похоже на API сделанное разработчиками для скорости отображения данных на веб-страницах которые подгружают данные через Ajax запросы.

Цифровой мастер-план города Байкальска
Не совсем государственный, скорее государством заказанный сайт (план.байкальск.рф) отображает данные с помощью Graphql API [4]. Похоже это основной принцип работы сайты через отображение данных через запросы к бэкэнду Graphql.

Я привёл 4 примера из нескольких сотен, именно недокументированных API. Как такие API появляются? Почему часто владельцы данных сами о них не знают?

Основные причины таковы:
1. Неотъемлимая часть CMS или веб-фреймворка. CMS вроде Sharepoint'а или Wordpress предоставляют API по умолчанию, позволяющее скачивать весь общедоступный контент автоматизировано. Аналогично делают некоторые компоненты для существующих CMS.
2. Разработчикам так удобнее. Разработчики привыкшие делать внутренние или закрытые веб-приложения часто переносят эти практики для приложений в открытом доступе и отображают данные через Ajax запросы.
3. Внутреннее API не для всех. Значительно реже, API делается для себя/каких-то команд которые работают с данными, но не документируется, не описывается и тд. Часто можно найти в документах техзаданий к госконтрактам.

Есть порталы где API декоративно и запросы автоматически блокируются после 5-10 обращений в минуту. Есть порталы где API - это основной способ предоставлять информацию. В одном только портале электронного бюджета более 100 API к данным.

Ссылки:
[1] https://fish.gov.ru/wp-json/
[2] https://asutk.ru/_api/Web/
[3] https://e-trust.gosuslugi.ru/app/scc/portal/api/v1/portal/ca/list
[4] https://api-dmp-baykalsk.chg.one/v1/graphql

#opendata #openapi #api #government

Я довольно много писал про недокументированные API госорганов [1] и упоминал похожий гражданский проект в Германии [2].

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

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

Всех этих API великое, нет огромное количество.

Какое-то время назад я размещал на сервисе Postman коллекцию с документацией таких API [3]․ Там их немного, 6 государственных систем, около пары-тройки десятков точек подключения. Все они идут по 1-й или по 2-й категории API, а есть немало API которые просто являются частью продукта и вот их примеры.

Есть такой продукт DSpace используемый ВУЗами для создания репозиториев научных результатов. Он много где установлен в мире, в основном университетами, но даже открытые библиотека НАТО и Мирового банка тоже работают на DSpace. В России он используется, например, в СПбГУ.

У DSpace по умолчанию есть интерфейс раскрытия данных по стандарту OAI-PMH, это такой стандарт архивации научных и библиотечных знаний. Поэтому, к примеру, у инсталляции DSpace есть API интерфейс для доступа [4], подробнее о нём и как работать с протоколом OAI-PMH легко гуглится. Специалисты, как правило, о таких интерфейсах знают заранее. Неспециалисты очень удивляются когда неожиданно обнаруживают.

Другой пример, у Wordpress есть API, идущее практически по умолчанию в новых инсталляциях. Оно сводится к точке подключения /wp-json/ через который можно выкачать. Это полезно, например, для цифровой архивации. Я специально для такого сделал утилиту wparc [5] позволяющую архивировать данные из инсталляций Wordpress. В России, например, Wordpress, используется на сайте Госкомиссии по Арктике и, конечно, wp-json там активирован [6].

Таких примеров много, они не описываются на порталах открытых данных и инициативах вроде bund.dev или нашей коллекции госAPI.

Ссылки:
[1] https://t.iss.one/begtin/3550
[2] https://t.iss.one/begtin/4194
[3] https://www.postman.com/infoculture/workspace/infoculture-public/documentation/1428203-a769e0a6-0cc9-4de4-bdcc-5f8a0fa06e36
[4] https://dspace.spbu.ru/oai/
[5] https://github.com/ruarxive/wparc
[6] https://arctic.gov.ru/wp-json/

#api #openapi #government #undocumented