¿Cómo puedo escribir un conjunto de funciones que se pueden invocar desde (casi) cualquier lenguaje de programación?

Me gustaría encontrar una manera de escribir una API a la que se pueda acceder desde cualquier otro lenguaje de programación a través de enlaces de idioma (o algún otro marco). ¿Es posible hacer esto? Si es así, ¿qué lenguaje de programación sería el más adecuado para escribir una API "cross-language"? Mi objetivo es crear un conjunto único de funciones a las que pueda acceder desde cualquier lenguaje de programación con el que estoy trabajando, para que no necesite volver a escribir manualmente la API completa en cada idioma.

Tienes pocas opciones:

1. Cree una interfaz HTTP, casi todo puede hablar HTTP, por lo que obtendrá muchos idiomas.

2. Cree algo que pueda vincularse a un tiempo de ejecución de idioma, esto llevará bastante tiempo ya que necesitará encontrar una manera de conectarlo a muchos idiomas diferentes.

Creo que C o C ++ serían los más adecuados para su propósito. Puede usar SWIG (generador de interfaz y envoltorio simplificado) para generar enlaces de lenguaje desde su API C o C ++.

SWIG es una herramienta de desarrollo de software que conecta programas escritos en C y C ++ con una variedad de lenguajes de programación de alto nivel. SWIG se utiliza con diferentes tipos de lenguajes de destino, incluidos los lenguajes de secuencias de comandos comunes, como Perl, PHP, Python, Tcl y Ruby. La lista de idiomas admitidos.también incluye lenguajes sin secuencias de comandos como C #, Common Lisp (CLISP, Allegro CL, CFFI, UFFI), D, lenguaje Go, Java, incluidos Android, Lua, Modula-3, OCAML, Octave y R. También varios esquemas interpretados y compilados implementaciones (Guile, MzScheme / Racket, Chicken) son compatibles. SWIG se usa más comúnmente para crear entornos de programación interpretados o compilados de alto nivel, interfaces de usuario y como herramienta para probar y crear prototipos de software C / C ++. SWIG se usa típicamente para analizar interfaces C / C ++ y generar el 'código de pegamento' requerido para que los lenguajes de destino anteriores llamen al código C / C ++. SWIG también puede exportar su árbol de análisis en forma de expresiones XML y Lisp. SWIG es software libre y el código que genera SWIG es compatible con proyectos comerciales y no comerciales ...

Hay casi 2 formas:

• una API de C. Prácticamente cualquier lenguaje que haya existido cargará una biblioteca C y llamará a sus funciones. Cómo hacerlo depende del idioma de origen.
• un mecanismo RPC de algún tipo. Esto puede ser una API REST que se ejecuta sobre HTTP, o una interfaz binaria que se ejecuta sobre un socket. A menos que elija el mecanismo de mínimo común denominador (por ejemplo, un socket), corre el riesgo de no tener rutinas de acceso de clientes (por ejemplo, algunos idiomas no tienen los clientes SOAP adecuados para llamar a una API implementada usando SOAP, o existen problemas de interoperabilidad). Apéguese a lo más simple, ya sea una interfaz HTTP / REST o un socket. Los sockets tienen la ventaja de que no necesitan un servidor HTTP para exponer la interfaz a los clientes, y pueden ejecutarse más fácilmente en el mismo servidor que el cliente con un mejor rendimiento.

El trabajo requerido para estos cambios depende del sistema utilizado, por ejemplo, una interfaz de socket funcionará, pero las bibliotecas del lado del cliente tienden a tener un nivel más bajo en comparación con las bibliotecas http.

Podría intentar encontrar una biblioteca de red que admita todos los idiomas que desea usar e implementar la API en términos de esa biblioteca; por ejemplo, usar ZeroMQ le brinda mucha flexibilidad, por lo que escribiría su API usando interfaces ZeroMQ, y entonces cualquier idioma que quiera llamar a su API debe usar la biblioteca del cliente ZeroMQ para hacerlo. Elija una biblioteca que admita una amplia gama de idiomas y le permita la comunicación tanto en proceso como fuera de proceso para obtener el mejor rendimiento.

Si el rendimiento y la latencia de las llamadas no son un problema, considere proporcionar una interfaz de línea de comandos completa (probablemente, utilizando un lenguaje de script encima). ImageMagick puede ser un buen ejemplo de tal "API". Otro buen ejemplo es el kit de herramientas Tk.

Por API, ¿qué quieres decir exactamente?

En muchas plataformas, puede vincular a una DLL o construcción similar, pero ¿tendría que volver a compilarse para un objetivo nativo particular (Intel / ARM) o la endianness aún califica? Una interfaz binaria en particular aún puede tener dificultades con ciertos idiomas debido a problemas de tipo de datos o construcciones (punteros que intentan regresar a idiomas que no los admiten bien), por lo que también debería considerar el diseño de la API en sí misma para no para excluir algunos idiomas o hacer que su uso sea engorroso.

Algo portátil como C y una interfaz basada en puntos finales binarios en una DLL puede estar bien y, en general, se puede llamar en la mayoría de las plataformas y desde la mayoría de los lenguajes, pero es posible que deba compilarse de manera diferente y / u ofrecerse en diferentes versiones o vincularse a diferentes bibliotecas estáticas.

Me parece que la elección del idioma en el que escribe su biblioteca o servicio o lo que sea, por definición, no es intrínseco a la pregunta hasta que haya dado más información sobre la plataforma / servicio que expone la API. Si puede suponer que hay una pila de red disponible y el rendimiento de nivel de llamada de función con enlace directo no es un requisito, la API podría estar fácilmente basada en HTTP con algún tipo de calce para que el idioma del cliente haga transparentes las solicitudes.

Creo que, en general, esta pregunta es demasiado amplia para ser útil en el mundo real, porque no ha dado indicaciones sobre qué tipo de API podría ser adecuada dado el tipo de servicio que se ofrece.

Para agregar a las respuestas anteriores que sugieren utilizar un mecanismo RPC. Puede usar Apache Thrift. ( Http://thrift.apache.org/ ). Básicamente es un marco RPC.

Según la wiki de Thrift:

El marco de software Apache Thrift, para el desarrollo escalable de servicios en varios idiomas, combina una pila de software con un motor de generación de código para crear servicios que funcionan de manera eficiente y sin problemas entre C ++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C #, Cacao, JavaScript, Node.js, Smalltalk, OCaml y Delphi y otros idiomas

Haga que cualquier idioma escriba un archivo de texto con función para llamar con parámetros para pasar. Haga que su aplicación "Me llevo bien con cualquiera" vea un directorio y una vez que vea un proceso call.txt haga que funcione. No hay servidores o protocolos de red; incluso un método de lenguaje no informático puede iniciar las funciones. Incluso una persona podría simplemente crear el archivo de texto.

El contenido podría verse así:

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

;) sin embargo, puede esperar para siempre para obtener una respuesta. Solo necesita insertar algunos bytes en el otro proceso, pero estoy seguro de que esa no es la especificación completa.

OpenGL es un buen ejemplo de lo que describe: es una API escrita en C, diseñada de una manera que es fácil de escribir enlaces en otros idiomas

1. Las bibliotecas C se pueden llamar desde la mayoría de los lenguajes de programación (generalmente como extensiones compiladas o cosas como la ctypesbiblioteca de PyPy, etc.)

2. Todas las funciones toman tipos de datos simples como argumentos (booleano, entero, coma flotante, constantes, matrices), ya que las funciones que toman punteros pueden ser difíciles de traducir a algunos idiomas.

3. Tener sus propios tipos de datos numéricos, que especifican precisión y firma (mientras que int floatetc. pueden diferir)

La API resultante no es necesariamente la API de C más agradable de usar que podría escribir si se dirige solo a usuarios de C. Sin embargo, significa que las funciones pueden exponerse casi directamente a otro idioma (por ejemplo, los documentos de PyOpenGL enumeran las diferencias, la mayoría de las cuales son bastante mínimas)

Además de esta API detallada, puede escribir más envoltorios "amigables para el desarrollador" alrededor de esto (marcos de juego y demás)