Написание языкового API-интерфейса?

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

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

Решение, с которым я мог столкнуться, это наличие C ++ API, как я первоначально предполагал, для C ++ напрямую и языков CLI (C #, F и т. д.), а затем своего рода документ и исполняемая комбинация. Если ожидаемый ввод описан в документе, а затем запускается исполняемый файл (через консоль /терминал), я бы дал параметры, указанные в качестве команд запуска. Это теоретически работало бы, но не звучит как стандартное решение тоже меня. Как это делается в другом программном обеспечении для настольных ПК?

6 голосов | спросил user3797758 3 +03002017-10-03T21:17:40+03:00312017bEurope/MoscowTue, 03 Oct 2017 21:17:40 +0300 2017, 21:17:40

3 ответа


8

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

Наиболее очевидной (и вездесущей) формой будет RPC, например gRPC или Thrift (или, если вы используете Windows, COM ).

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

ответил Jerry Coffin 5 +03002017-10-05T07:52:00+03:00312017bEurope/MoscowThu, 05 Oct 2017 07:52:00 +0300 2017, 07:52:00
5

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

В процессе

  • Важное соображение

    • Внутренний код специфичен для архитектуры. Это означает, что 32-разрядные и 64-разрядные не могут смешиваться в одном и том же процессе Windows.
    • Хотя чистый .NET IL может быть выполнен в 32-разрядных или 64-разрядных средах, собственный код должен быть скомпилирован отдельно для каждой архитектуры.
    • Если эти ограничения являются показами-стопорами, вы должны вместо этого использовать внепроцессный подход.
  • Win32 DLL

    • Экспорт C-вызываемых функций.
    • Может передавать целочисленные значения, значения с плавающей запятой, массивы примитивов (включая байтовые массивы) и т. д.
    • Будьте осторожны с «структурами», убедитесь, что две части коммуникационного программного обеспечения согласуют выравнивание полей структуры для каждой структуры.
    • Пользователи .NET могут использовать P /Invoke для вызова DLL. Это можно преобразовать в .NET-оболочку, которая может полностью скрыть собственный аспект базовой реализации.
  • Microsoft COM
    • Зрелые, рекомендуемые
  • .NET Interop с использованием C ++ /CLI
    • Рекомендуется, если большинство пользователей находятся на .NET.

Вне процесса, один и тот же компьютер, не сообщающийся (без обмена информацией в середине исполнения)

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

Вне процесса, тот же самый компьютер, сообщающий

  • Выбор работы в качестве приложения Windows или службы Windows
  • Приложение командной строки плюс любой выбор межпроцессного взаимодействия. Обратитесь к межпроцессной коммуникации в документации Windows.
    • Совместно используемая память или файл для обмена данными между процессами
    • Подпроцессы синхронизации между процессами (только для нужд синхронизации или семафора)
    • Межпроцессные трубы
    • В файловой системе. Синхронизация (передача вручную) должна выполняться одним из других способов. В качестве альтернативы, многократно сканируйте папку для изменения файла с периодическими интервалами.
  • WCF

Вне процесса, разные машины, сообщающие

  • Архитектуры
    • Архитектура сервера серверов
    • Распределенная архитектура
  • Написание веб-службы, работающей под IIS
  • Работает как служба Windows, которая обменивается данными через TCP /IP
  • Работает как служба Windows, которая обменивается данными через WCF
ответил rwong 4 +03002017-10-04T13:46:14+03:00312017bEurope/MoscowWed, 04 Oct 2017 13:46:14 +0300 2017, 13:46:14
4

Привести в дискуссию «старомодную», но вполне зрелую технологию:

CORBA позволяет вам определять объектно-ориентированные API не зависящим от языка способом (определяет собственный язык определения IDL = интерфейса). Языковые сопоставления доступны для действительно всех основных языков (и даже многих экзотических).

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

В нашей компании мы по-прежнему используем его для критически важных случаев, и совместимость всегда работала (с использованием смесей Java, C, C ++, C # и CommonLisp). Мы использовали CORBA для интерфейсов для компаний-партнеров, часто даже не зная, какой язык программирования они использовали.

И, возможно, вы уже использовали его, не зная. Например. Java RMI /IIOP эффективно CORBA.

ответил Ralf Kleberhoff 4 +03002017-10-04T22:33:18+03:00312017bEurope/MoscowWed, 04 Oct 2017 22:33:18 +0300 2017, 22:33:18

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132