Ivan Begtin
8.03K subscribers
1.75K photos
3 videos
101 files
4.45K links
I write about Open Data, Data Engineering, Government, Privacy, Digital Preservation and other gov related and tech stuff.

Founder of Dateno https://dateno.io

Telegram @ibegtin
Facebook - https://facebook.com/ibegtin
Secure contacts ivan@begtin.tech
Download Telegram
Как государства предоставляют данные и сервисы бизнесу? Через систематизированные каталоги 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://publielectoral.lat/begtin/3550
[2] https://publielectoral.lat/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
В рубрике полезных инструментов для публикации данных roapi [1] фреймворк по публикации статических наборов данных, написан на Rust, а внутри использует Apache Arrow и Datafusion. Автор описывает его как то что не надо написать ни строчки кода что, не совсем так, вместо кода надо писать конфиг на YAML, но даже при этом возможности весьма немалые. Фактически, из коробки, получаем REST API, GraphQL и SQL (через HTTPS и протокол Postgres Wire) для доступа к выбранному набору данных.

Можно делать API на основе файлов CSV, JSON, NDJSON (JSON lines), Parquet, баз SQLite и MySQL.

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

Я помню как ещё 10 лет назад командой data.gov публиковался простой PHP скрипт csv-to-api [2], а я лет 9 назад писал простой движок apiready [3] генерировавший чуть более продвинутое API выделяя отдельно справочные значения.

Через много лет лично я пришёл к архитектуре:
1) Положи все данные в СУБД
2) Используй обертку вокруг данных в СУБД
и написал и опубликовал движок apicrafter [4] позволяющий такую обёртку делать вокруг базы в MongoDB.

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

Ссылки:
[1] https://github.com/roapi/roapi
[2] https://github.com/project-open-data/csv-to-api
[3] https://github.com/ivbeg/apiready
[4] https://github.com/apicrafter/apicrafter

#datatools #api #openapi
В рубрике интересных открытых проектов Civitai [1] сообщество в котором пользователи делятся предобученными моделями для Stable Diffusion по генерации изображений самого разного типа։ людей, природы, предметов и многого другого.

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

Впрочем, более невинного применения этому тоже немало и примеров подобного также немало.

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

Проект с открытым кодом [2] и открытым API [3]


Ссылки։
[1] https://civitai.com
[2] https://github.com/civitai/civitai
[3] https://github.com/civitai/civitai/wiki/REST-API-Reference

#opendata #openapi #opensource #ai #generativeai
В рубрике интересных открытых данных каталог ресурсов с общедоступными API по стандарту OAI-PHM [1]. Это 6099 репозиториев с публикациями, как правило университетов и академических институтов. OAI-PHM версии 2.0 - это довольно давний стандарт [2] для работы с любыми цифровыми репозиториями контента. Его поддерживают, как ПО для публикации научных статей, так и сервисы и ПО для публикации исследовательских данных.

Наиболее популярные продукты с поддержкой OAI-PHM - это DSpace и EPrints, активно используемые для публикации научных статей в открытом доступе. OAI-PHM поддерживает портал Zenodo [3] и многие другие. Фактически этот интерфейс есть по умолчанию у многих продуктов используемых для публикации цифровых материалов, но не все знают что он есть

Ссылки:
[1] https://www.openarchives.org/Register/BrowseSites
[2] http://www.openarchives.org/OAI/openarchivesprotocol.html
[3] https://developers.zenodo.org

#opendata #datasets #openapi #oai-phm
Любопытный исследовательский проект ORKG [1] дословно The Open Research Knowledge Graph (ORKG) aims to describe research papers in a structured manner. With the ORKG, papers are easier to find and compare.

А в переводе на русский язык посвящённый структуризации научных публикаций. Обратите внимание, не упрощённое понятное понимание, а именно структуризация. Фактически - это перевод научной статьи в данные/граф знаний с привязкой к Wikidata. Делает его команда TIB – Leibniz Information Centre for Science and Technology которые под руководством Сорена Ауэра, команда которого когда-то создавала DbPedia. Фактически проект создаёт структурированную базу научных статей, задача эта очень непростая, но реалистичная и наукоёмкая.

Да, у них открытое API, точки подключения к SPARQL и много чего открытого.

Ссылки:
[1] https://orkg.org

#opendata #openapi #openscience #knowledge #science
Я уже несколько раз писал о том что государства по всему миру продолжают создавать каталоги API, по аналогии с сайтами для разработчиков предлагаемыми в коммерческом секторе. Новые каталоги API в тот же список:
- Каталог административных API Японии http://api-catalog.e-gov.go.jp/ открыт 31 марта 2023 г., 39 API
- Государственные API в Малайзии https://www.mygdx.gov.my/en/landing-page/architecture?theme=first-theme 130 API
- Портал API налоговой службы Австралии https://apiportal.ato.gov.au, 6 API
- Портал госAPI ОАЭ https://api.government.ae 29 API
- Портал API налоговой службы Новой Зеландии https://portal.api.business.govt.nz 30 API
- Каталог API Литвы https://api.gov.lt около 40 API

А также предыдущий список из 6 каталогов API.

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

#openapi #opendata #api #government
В рубрике интересных поисковых систем Openverse [1] поисковик по изображениям и аудио опубликованным под свободными лицензиями Creative Commons или в статусе Public Domain. Ищет по более чем 700 миллионам объектов, предоставляет открытое API [2], основные источники: Flickr, iNaturalist и Wikimedia Commons [3], а для реализация поиска используют индекс Common Crawl. У проекта полностью открытый код [4] (внутри Python, Django, Typescript, Vue). Данные собираются с помощью Apache Airflow, а внутри поисковика Elasticsearch и сотни контрибьюторов. Очень живой и развивающийся проект

До него существовал поиск на сайте Creative Commons, но теперь он превратился в мета-поиск с выбором одной из поисковых систем [5].

Ссылки:
[1] https://openverse.org
[2] https://api.openverse.engineering/v1/
[3] https://openverse.org/sources
[4] https://github.com/WordPress/openverse
[5] https://search.creativecommons.org

#openapi #searchengines #opensource
Обновлённая подборка государственных каталогов открытых API. Последний раз я писал о них полтора года назад за это время список пополнился:
- API.GOUV.FR - каталог API, стандарты и рекомендации Франции
- API.GOVERNMENT.AE - каталог API Объединённых Арабских эмиратов
- API.GOV.UK - каталог государственных API Великобритании
- API.GOV.AU - австралийский государственный стандарт предоставления API и каталог общедоступных API
- DEVELOPER.VIC.GOV.AU - портал для программистов (каталог API) правительства штата Виктория, Австралия
- API.NSW.GOV.AU - портал открытых API Нового Южного Уэльса, Австралия
- PORTAL.API.IPAUSTRALIA.GOV.AU - портал API патентного ведомства Австралии
- DEVELOPER.HEALTH.GOV.AU - B2G (Business To Government) портал API Департамента здравоохранения Австралии
- DEVELOPER.TECH.GOV.SG - портал для разработчиков от Правительства Сингапура, API, документация и тд.
- ESERVICES.MAS.GOV.SG - портал открытых API главного монетарного управления Сингапура (аналог центробанка)
- MYGDX.GOV.MY - каталог API на малазийском государственном портале MyGDX

В реальности каталогов API сильно больше, не везде они сразу бросаются в глаза.

#api #openapi