Як я можу написати набір функцій, які можна викликати з (майже) будь-якої мови програмування?

Я хотів би знайти спосіб написання API, до якого можна отримати доступ з будь-якої іншої мови програмування за допомогою прив'язки мови (або якоїсь іншої рамки). Чи можна це зробити? Якщо так, то яка програма програмування була б найбільш підходящою для написання API "міжмовної мови"? Моя мета - створити єдиний набір функцій, до яких я можу отримати доступ з будь-якої мови програмування, з якою я працюю, так що мені не потрібно буде вручну переписувати весь API на кожній мові.

У вас є кілька варіантів:

1. Створіть інтерфейс HTTP, майже все може говорити HTTP, щоб отримати багато мов.

2. Створіть щось, що може бути пов’язано з мовою виконання, це забирає багато часу, оскільки вам знадобиться знайти спосіб підключення його до багатьох різних мов.

Я думаю, що C або C ++ було б найбільш підходящим для вашої мети. Ви можете використовувати SWIG (спрощений генератор і інтерфейс) для створення мовних зв'язків з вашого C або C ++ API.

SWIG - це інструмент розробки програмного забезпечення, який з'єднує програми, написані на C і C ++, з різними мовами програмування високого рівня. SWIG використовується з різними типами цільових мов, включаючи поширені мови скриптів, такі як Perl, PHP, Python, Tcl та Ruby. Список підтримуваних мовтакож включає не-сценарії, такі як C #, Common Lisp (CLISP, Allegro CL, CFFI, UFFI), D, Go, Java, включаючи Android, Lua, Modula-3, OCAML, Octave та R. Також кілька інтерпретованих та складених схем реалізації (Guile, MzScheme / Racket, Chicken) підтримуються. SWIG найчастіше використовується для створення інтерпретованих або складених середовищ програмування на високому рівні, інтерфейсів користувача та як інструмент для тестування та прототипування програмного забезпечення C / C ++. SWIG, як правило, використовується для розбору інтерфейсів C / C ++ та генерування «коду клею», необхідного для вищезазначених мов для виклику в код C / C ++. SWIG також може експортувати своє дерево розбору у вигляді XML та s-виразів Lisp. SWIG - це вільне програмне забезпечення, і код, який створює SWIG, сумісний як з комерційними, так і з некомерційними проектами ...

Є майже два способи:

• API C. Практично будь-коли мова, яка там коли-небудь була, буде завантажувати бібліотеку С і викликати її функції. Як це зробити, залежить від мови джерела.
• якийсь механізм RPC. Це може бути API REST, що працює над HTTP, або бінарний інтерфейс, що працює над сокетом. Якщо ви не використовуєте найменший механізм загального знаменника (наприклад, сокет), ви ризикуєте не мати підпрограми доступу клієнта (наприклад, деякі мови не мають права клієнти SOAP викликати API, реалізований за допомогою SOAP, або є проблеми інтероперабельності). Дотримуйтесь найпростішого - або HTTP / REST-інтерфейсу, або сокета. Сокети мають перевагу в тому, що їм не потрібен сервер HTTP для відкриття інтерфейсу для клієнтів, і вони можуть легше працювати на тому ж сервері, що і клієнт, з кращою продуктивністю.

Робота, необхідна для цих змін, залежить від використовуваної системи, наприклад, буде працювати інтерфейс сокета, але бібліотеки на стороні клієнта мають тенденцію бути більш низьким рівнем порівняно з http-бібліотеками.

Ви можете спробувати знайти мережеву бібліотеку, яка підтримує всі мови, якими ви хочете користуватися, та реалізувати API з точки зору цієї бібліотеки - наприклад, використання ZeroMQ дає вам велику гнучкість, тому ви б писали свій API за допомогою інтерфейсів ZeroMQ та то будь-яка мова, яка хоче зателефонувати у ваш API, повинна використовувати для цього клієнтську бібліотеку ZeroMQ. Виберіть бібліотеку, яка підтримує широкий діапазон мов, а також дозволяє здійснювати як обробку, так і позасистемне спілкування для найкращої продуктивності.

Якщо продуктивність та затримка викликів не є проблемою, подумайте про надання всебічного інтерфейсу командного рядка (можливо, використовуючи мову сценаріїв поверх нього). ImageMagick може бути хорошим прикладом такого "API". Ще один хороший приклад - інструментарій Tk.

Під API, що саме ви маєте на увазі?

На багатьох платформах ви могли б зв’язатися з DLL або подібною конструкцією, але вам доведеться перекомпілювати для конкретної націленої цілі (Intel / ARM) або все-таки кваліфікованість? У певному бінарному інтерфейсі все ще можуть виникнути труднощі з певними мовами через проблеми або конструкції типу даних (вказівники, які намагаються повернутись до мов, які не підтримують їх добре), тому вам також доведеться врахувати дизайн самого API, щоб не щоб виключити деякі мови або зробити їх використання з цих мов громіздкими.

Щось таке портативне, як C та інтерфейс, заснований на бінарних кінцевих точках у DLL, може бути відмінним та загальним для дзвінка на більшості платформ та з більшості мов, але, можливо, його потрібно скласти по-різному та / або запропонувати в різних смаках або пов'язати з різними статичними бібліотеками.

Мені здається, що вибір мови, якою ви пишете свою бібліотеку чи службу, або що б там не було, за визначенням не суттєвий для цього питання, поки ви не дасте більше інформації про платформу / службу, яку API викриває. Якщо ви можете припустити, що мережевий стек доступний, а продуктивність на рівні прямого зв’язку функціонування на рівні виклику не є вимогою, API може бути легко заснований на HTTP з якоюсь хиткою для мови клієнта, щоб зробити запити прозорими.

Я думаю, що в цілому це питання є надто широким, щоб бути корисним у реальному світі, оскільки ви не дали вказівки щодо того, який тип API може бути придатним з огляду на тип послуги, що пропонується.

Додайте до вище відповідей, які пропонують використовувати механізм RPC. Ви можете використовувати Apache Thrift. ( Http://thrift.apache.org/ ). В основному це рамка RPC.

Відповідно до Вікі-ощадливості:

Програмне забезпечення Apache Thrift для розробки масштабних мовних послуг поєднує стек програмного забезпечення з механізмом генерації коду для створення служб, які ефективно і безперебійно працюють між C ++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C #, Какао, JavaScript, Node.js, Smalltalk, OCaml і Delphi та інші мови

Нехай будь-яка мова випише текстовий файл із функцією для дзвінка з парами для передачі. Попросіть додаток "Я погоджуюся з ким-небудь", щоб переглядати каталог, і як тільки він побачить процес-call.txt, перейдіть на роботу. Відсутність серверів або мережевих протоколів; навіть некомп'ютерний мовний метод може запускати функції. Навіть людина могла просто створити текстовий файл.

Вміст може виглядати так:

Call-method:  fdisk()
Params:  (string) "/root", (string) "write-back-file-expected.txt"

;) Ви можете зачекати вічно, щоб отримати відповідь. Вам просто потрібно просунути кілька байт до іншого процесу, але я впевнений, що це не вся специфікація.

OpenGL - хороший приклад того, що ви описуєте - це API, написаний на C, розроблений таким чином, що легко писати прив’язки іншими мовами

1. Бібліотеки C можна викликати з більшості мов програмування (як правило, як складені розширення або такі речі, як ctypesбібліотека PyPy тощо)

2. Усі функції приймають прості типи даних як аргументи (булева, ціла, плаваюча точка, константи, масиви), оскільки функції, що приймають покажчики, можуть бути незручними для перекладу на деякі мови

3. Маючи власні числові типи даних, які визначають точність та підписаність (тоді як int floatтощо можуть відрізнятися)

Отриманий API не обов'язково є найкращим у використанні API API, який ви могли написати, якщо націлювати лише на користувачів C. Однак це означає, що функції можуть бути майже безпосередньо піддані впливу іншої мови (наприклад, документи PyOpenGL перераховують відмінності, більшість з яких досить мінімальні)

Зверху на цей багатослівний API, ви можете написати ще "обгортки для розробників" навколо цього (ігрові рамки тощо)