Comment puis-je écrire un ensemble de fonctions pouvant être appelées depuis (presque) n'importe quel langage de programmation?

J'aimerais trouver un moyen d'écrire une API accessible depuis n'importe quel autre langage de programmation via des liaisons de langage (ou un autre framework). Est-il possible de faire cela? Si tel est le cas, quel langage de programmation conviendrait le mieux pour écrire une API "multilingue"? Mon objectif est de créer un ensemble unique de fonctions auxquelles je peux accéder à partir de n'importe quel langage de programmation avec lequel je travaille, afin de ne pas avoir à réécrire manuellement l'intégralité de l'API dans chaque langue.

Vous avez quelques options:

1. Créez une interface HTTP, presque tout peut parler HTTP, ce qui vous donnera beaucoup de langues.

2. Créez quelque chose qui puisse être lié à un environnement linguistique, cela prendra beaucoup de temps, car vous devrez trouver un moyen de le connecter à de nombreuses langues différentes.

Je pense que C ou C ++ conviendrait le mieux à vos besoins. Vous pouvez utiliser SWIG (Simplified Wrapper and Interface Generator) pour générer des liaisons de langage à partir de votre API C ou C ++.

SWIG est un outil de développement logiciel qui relie des programmes écrits en C et C ++ à une variété de langages de programmation de haut niveau. SWIG est utilisé avec différents types de langages cibles, y compris les langages de script courants tels que Perl, PHP, Python, Tcl et Ruby. La liste des langues supportéescomprend également des langages non scriptés tels que C #, Common Lisp (CLISP, Allegro CL, CFFI, UFFI), langage D, Go, Java comprenant Android, Lua, Modula-3, OCAML, Octave et R. Egalement plusieurs schémas interprétés et compilés les implémentations (Guile, MzScheme / Racket, Poulet) sont supportées. SWIG est le plus souvent utilisé pour créer des environnements de programmation interprétés ou compilés de haut niveau, des interfaces utilisateur et comme outil de test et de prototypage de logiciels C / C ++. SWIG est généralement utilisé pour analyser les interfaces C / C ++ et générer le "code d'enchaînement" requis pour que les langages cibles ci-dessus appellent le code C / C ++. SWIG peut également exporter son arbre d’analyse syntaxique sous la forme d’expressions s et Lisp. SWIG est un logiciel libre et le code généré par SWIG est compatible avec les projets commerciaux et non commerciaux ...

Il y a à peu près 2 façons:

• une API C. Pratiquement toutes les langues existantes chargeront une bibliothèque C et appelleront ses fonctions. Cela dépend de la langue source.
• un mécanisme RPC de quelque sorte. Cela peut être une API REST exécutée sur HTTP ou une interface binaire exécutée sur un socket. Sauf si vous optez pour le mécanisme du plus petit dénominateur commun (par exemple, un socket), vous courez le risque de ne pas avoir de routines d'accès client (par exemple, certaines langues ne disposent pas des clients SOAP appropriés pour appeler une API implémentée à l'aide de SOAP, ou en cas de problèmes d'interopérabilité). S'en tenir à la plus simple, soit une interface HTTP / REST, ou un socket. Les sockets ont l'avantage de ne pas nécessiter de serveur HTTP pour exposer l'interface aux clients et peuvent plus facilement s'exécuter sur le même serveur que le client offrant de meilleures performances.

Le travail requis pour cette tâche change en fonction du système utilisé. Par exemple, une interface de socket fonctionnera, mais les bibliothèques côté client ont tendance à être plus simples que les bibliothèques http.

Vous pouvez essayer de trouver une bibliothèque réseau prenant en charge toutes les langues que vous souhaitez utiliser et implémenter l'API en fonction de cette bibliothèque. Par exemple, utiliser ZeroMQ vous donne beaucoup de flexibilité pour écrire votre API à l'aide d'interfaces ZeroMQ. toute langue souhaitant appeler votre API doit alors utiliser la bibliothèque cliente ZeroMQ. Choisissez une bibliothèque prenant en charge un large éventail de langues et permettant une communication in-process ou out-of-process pour des performances optimales.

Si les performances et la latence des appels ne sont pas un problème, envisagez de fournir une interface de ligne de commande complète (probablement, en utilisant un langage de script par-dessus). ImageMagick peut être un bon exemple d'une telle "API". Un autre bon exemple est la boîte à outils Tk.

Par API, que voulez-vous dire exactement?

Sur de nombreuses plates-formes, vous pouvez créer un lien vers une DLL ou une construction similaire, mais le fait de devoir être recompilé pour une cible native particulière (Intel / ARM) ou pour l’endianisme est-il toujours admissible? Une interface binaire particulière peut toujours rencontrer des difficultés avec certaines langues en raison de problèmes de types de données ou de constructions (les pointeurs essayant d’être renvoyés vers des langues qui ne les prennent pas bien en charge). Vous devrez donc également prendre en compte la conception de l’API afin de ne pas la modifier. exclure certaines langues ou rendre son utilisation lourde de ces langues.

Quelque chose de portable, comme C, et une interface basée sur des points de terminaison binaires dans une DLL peuvent être généralement appelés et appelables sur la plupart des plateformes et de la plupart des langues, mais il peut être nécessaire de les compiler différemment et / ou de les proposer sous différentes formes ou de les lier à différentes bibliothèques statiques.

Il me semble que le choix de la langue dans laquelle vous écrivez votre bibliothèque ou votre service ou quoi que ce soit est, par définition, indissociable de la question jusqu'à ce que vous en donniez davantage sur la plate-forme / service exposée par l'API. Si vous pouvez supposer qu'une pile réseau est disponible et que les performances au niveau des fonctions liées directement ne sont pas une exigence, l'API peut facilement être basée sur HTTP avec une sorte de shim pour la langue du client afin de rendre les requêtes transparentes.

Je pense que, d’une manière générale, cette question est trop vaste pour être utile dans le monde réel, car vous n’avez pas indiqué quel type d’API pourrait convenir compte tenu du type de service offert.

Pour ajouter aux réponses ci-dessus qui suggèrent l'utilisation d'un mécanisme RPC. Vous pouvez utiliser Apache Thrift. ( Http://thrift.apache.org/ ). C'est fondamentalement un framework RPC.

Selon le wiki Thrift:

Le framework logiciel Apache Thrift, destiné au développement de services inter-langues évolutifs, associe une pile logicielle à un moteur de génération de code pour créer des services efficaces et transparents entre C ++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C #, Cocoa, JavaScript, Node.js, Smalltalk, OCaml et Delphi et d'autres langages

Demandez à n'importe quelle langue d'écrire un fichier texte avec une fonction à appeler avec des paramètres à transmettre. Demandez à votre application "Je m'entends avec tout le monde" de regarder un répertoire et une fois qu'elle verra un processus-call.txt le faire fonctionner. Aucun serveur ou protocole réseau; même une méthode en langage non informatique peut initier les fonctions. Même une personne pourrait simplement créer le fichier texte.

Le contenu pourrait ressembler à:

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

;) vous pourriez attendre une éternité avant d’obtenir une réponse. Vous avez juste besoin d'insérer quelques octets dans l'autre processus, mais je suis sûr que ce n'est pas tout.

OpenGL est un bon exemple de ce que vous décrivez - c'est une API écrite en C, conçue de manière à ce qu'il soit facile d'écrire des liaisons dans d'autres langues.

1. Les bibliothèques C peuvent être appelées à partir de la plupart des langages de programmation (généralement en tant qu’extensions compilées, ou des choses comme la ctypesbibliothèque de PyPy, etc.)

2. Toutes les fonctions prennent comme arguments des types de données simples (booléen, entier, virgule flottante, constantes, tableaux), car les fonctions utilisant des pointeurs peuvent être difficiles à traduire en certaines langues.

3. Avoir ses propres types de données numériques, qui spécifient la précision et la signature (alors que int floatetc peut différer)

L'API résultante n'est pas nécessairement l'API C la plus conviviale que vous puissiez écrire si vous ne ciblez que des utilisateurs C. Cependant, cela signifie que les fonctions peuvent être presque directement exposées à une autre langue (par exemple, la documentation de PyOpenGL répertorie les différences, dont la plupart sont plutôt minimes).

En plus de cette API prolixe, vous pouvez écrire plus de wrappers "conviviaux pour les développeurs" autour de cela (frameworks de jeu et autres).