Схемы довольно крутые. Моя признательность за API-схемы как производителя инструментов проистекает из желания создавать инструменты, которые могут интегрироваться со многими системами и открывать новые возможности для использования API.
В большинстве случаев вариант использования схем API, который приходит на ум, — это создание документации. Преобразование машиночитаемой схемы в удобное для человека представление — это масштабируемый автоматизированный способ ведения надежной справочной документации. Хотя существует множество систем для создания документации непосредственно из кода, наличие промежуточного представления полезно для других случаев использования.
Генерация кода — еще одна важная задача. Такие компании, как Google и Amazon, обычно создают клиентские библиотеки на разных языках для своих многочисленных веб-API. Даже некоторые библиотеки для API GitHub генерируются, потому что их API стал настолько большим, что в противном случае это было бы непригодно. Это особенно важно в сообществе открытого исходного кода, где время сопровождающего является дефицитным ресурсом. Схемы экономят много времени, но найти схему для любого данного веб-API по-прежнему довольно редко.
Еще менее распространены схемы для невеб-API. В 2016 году Электрон начал выпускать схему JSON для всех своих API, что позволило мне построить мост для использования API Electron из Go. Я имел в виду этот прототип, когда начал проект macdriver, который был выпущен пару месяцев назад. Прямо сейчас мы вручную оборачиваем классы фреймворка Apple в типы Go, чтобы вы могли писать нативные приложения для платформы Apple, которые выглядят следующим образом:
Раньше такие привязки больше поддерживались Apple, о чем свидетельствуют файлы поддержки мостов, которые представляли собой XML-схемы их API. Однако они уже не очень хорошо поддерживаются. Более того, файлы поддержки моста были больше похожи на заголовки и не давали много документации.
Поэтому, если мы хотим сгенерировать API в macdriver, мы могли бы проанализировать заголовки Objective-C или попытаться использовать то, что доступно в файлах поддержки моста. Но мы также хотели бы создавать удобочитаемые описания и в идеале ссылаться на официальные документы.
Если схемы используются для создания документации, нет никаких причин, по которым вы не можете создавать схемы из документации.
Поэтому я создал инструмент, который мог разбирать документацию Apple на схемы. Поскольку в их документах также есть объявления для всего, нам даже не нужно использовать заголовочные файлы. Результатом является хороший документ JSON, описывающий их классы и другие сущности, подобные этому:
Исходя из этого, мы можем начать автоматизировать генерацию типов-оболочек в macdriver, но в качестве отдельной цепочки инструментов схемы, которые он создает, могут использоваться для написания привязок на языках, отличных от Go.
Подобные схемы также можно использовать в инструментах разработчика для самых разных вещей, таких как автозаполнение, или для помощи в создании интерфейсов визуального программирования.
Сегодня большинству инструментов «без кода» необходимо поддерживать интеграцию, чтобы оставаться конкурентоспособными, но все они пишут и поддерживают свои собственные интеграции. Фактически каждое приложение с программируемой пользователем интеграцией может извлечь выгоду из подобных схем. Поэтому я хотел бы увидеть больше.
Если это интересно, взгляните на созданный мной инструмент macschema, исходный код которого доступен на GitHub. Сейчас это всего лишь цепочка инструментов, но теоретически мы могли бы сгенерировать схемы для всех API Apple и поместить их в репозиторий таким образом, чтобы их можно было обновлять с помощью комбинации macschema и пользовательских патчей. Я позволю сделать это кому-нибудь другому.
Спасибо, что читаете, больше думайте о схемах и подумайте о спонсировании моей работы!
Первоначально опубликовано на https://dev.to 16 апреля 2021 г.
