В рубрике интересные наборы данных, большой набор данных по распознаванию еды [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

В рубрике полезных инструментов для публикации данных 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] https://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 Японии https://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