Come posso scrivere una serie di funzioni che possono essere invocate da (quasi) qualsiasi linguaggio di programmazione?

Hai alcune opzioni:

1. Crea un'interfaccia HTTP, quasi tutto può parlare di HTTP in modo tale da ottenere un sacco di lingue.

2. Crea qualcosa che può essere collegato in un runtime di lingua, questo richiederà molto tempo in quanto dovrai trovare un modo per connetterlo a molte lingue diverse.

Penso che C o C ++ siano più adatti al tuo scopo. Puoi utilizzare SWIG (Wrapper semplificato e generatore di interfacce) per generare collegamenti linguistici dalla tua API C o C ++.

SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages. SWIG is used with different types of target languages including common scripting languages such as Perl, PHP, Python, Tcl and Ruby. The list of supported languages also includes non-scripting languages such as C#, Common Lisp (CLISP, Allegro CL, CFFI, UFFI), D, Go language, Java including Android, Lua, Modula-3, OCAML, Octave and R. Also several interpreted and compiled Scheme implementations (Guile, MzScheme/Racket, Chicken) are supported. SWIG is most commonly used to create high-level interpreted or compiled programming environments, user interfaces, and as a tool for testing and prototyping C/C++ software. SWIG is typically used to parse C/C++ interfaces and generate the 'glue code' required for the above target languages to call into the C/C++ code. SWIG can also export its parse tree in the form of XML and Lisp s-expressions. SWIG is free software and the code that SWIG generates is compatible with both commercial and non-commercial projects...

Ci sono praticamente 2 modi:

• un'API C. Il linguaggio praticamente mai esistito caricherà una libreria C e chiamerà le sue funzioni. Il modo in cui lo fai dipende dalla lingua di origine.
• un meccanismo RPC di qualche tipo. Può trattarsi di un'API REST in esecuzione su HTTP o un'interfaccia binaria in esecuzione su un socket. A meno che non si scelga il meccanismo del minimo comune denominatore (ad es. Un socket) si corre il rischio di non avere routine di accesso client (ad esempio alcune lingue non hanno i client SOAP giusti per chiamare un'API implementata usando SOAP o ci sono problemi di interoperabilità). Attenersi al più semplice, un'interfaccia HTTP / REST o un socket. I socket hanno il vantaggio di non aver bisogno di un server HTTP per esporre l'interfaccia ai client e possono essere eseguiti più facilmente sullo stesso server del client con prestazioni migliori.

Il lavoro richiesto per questo cambiamento dipende dal sistema utilizzato, ad esempio, un'interfaccia socket funzionerà, ma le librerie lato client tendono ad essere più a basso livello rispetto alle librerie http.

Potresti provare a trovare una libreria di rete che supporti tutte le lingue che desideri utilizzare e implementare l'API in termini di tale libreria - ad esempio, l'utilizzo di ZeroMQ ti offre molta flessibilità, quindi dovresti scrivere la tua API usando ZeroMQ interfacce e quindi qualsiasi linguaggio che desideri chiamare la tua API deve utilizzare la libreria client ZeroMQ per farlo. Scegli una libreria che supporta un'ampia gamma di lingue e ti consente di elaborare sia le comunicazioni fuori processo che le migliori prestazioni.

Se le prestazioni e la latenza delle chiamate non sono un problema, prendi in considerazione l'idea di fornire un'interfaccia a riga di comando completa (probabilmente, utilizzando un linguaggio di scripting su di esso). ImageMagick può essere un buon esempio di tale "API". Un altro buon esempio è Tk toolkit.

Per API, cosa intendi esattamente?

Su molte piattaforme potresti collegare una DLL o una costruzione simile, ma dovresti essere ricompilata per un particolare target nativo (Intel / ARM) o endianness ancora qualificati? Una particolare interfaccia binaria potrebbe avere ancora difficoltà con alcuni linguaggi a causa di problemi di tipo di dati o costrutti (i puntatori cercano di essere restituiti a linguaggi che non li supportano bene), quindi dovresti considerare anche il design dell'API stessa in modo da non dover escludere alcune lingue o renderlo complicato da quelle lingue.

Qualcosa di portatile come C e un'interfaccia basata su endpoint binari in una DLL può essere soddisfacente e generalmente richiamabile sulla maggior parte delle piattaforme e dalla maggior parte delle lingue, ma potrebbe dover essere compilato in modo diverso e / o offerto in sapori diversi o collegato a diversi librerie statiche.

Mi sembra che la scelta del linguaggio che scrivi la tua biblioteca o il tuo servizio o qualsiasi altra cosa sia, per definizione, non intrinseca alla domanda finché non hai dato più informazioni sulla piattaforma / servizio che l'API espone. Se si può presupporre che uno stack di rete sia disponibile e che le prestazioni a livello di call-call a funzione diretta non siano un requisito, l'API potrebbe facilmente essere basata su HTTP con una sorta di shim per la lingua del client per rendere trasparenti le richieste.

Penso che in generale questa domanda sia troppo ampia per essere utile nel mondo reale, perché non hai dato indicazioni su quale tipo di API potrebbe essere adatto dato il tipo di servizio che viene offerto.

Per aggiungere alle risposte precedenti che suggeriscono l'utilizzo di un meccanismo RPC. Potresti usare Apache Thrift. ( link ). È fondamentalmente un framework RPC.

Come per il wiki di Thrift:

The Apache Thrift software framework, for scalable cross-language services development, combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages

Qualunque lingua abbia scritto un file di testo con la funzione da chiamare con i parametri per passare. Avere l'app "I get along with anybody" a guardare una directory e una volta che vede un processo-call.txt farlo funzionare. Nessun server o protocollo di rete; anche un metodo di linguaggio non computerizzato può avviare le funzioni. Anche una persona potrebbe semplicemente creare il file di testo.

Il contenuto potrebbe essere simile a:

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

;) potresti aspettare per sempre per avere una risposta. Hai solo bisogno di spingere alcuni byte per l'altro processo, ma sono sicuro che non è l'intera specifica.

OpenGL è un buon esempio di ciò che descrivi - è un'API scritta in C, progettata in un modo che è facile scrivere associazioni in altre lingue

1. Le librerie C possono essere chiamate dalla maggior parte dei linguaggi di programmazione (di solito come estensioni compilate, o cose come la libreria ctypes di PyPy ecc.)

2. Tutte le funzioni accettano semplici tipi di dati come argomenti (booleano, intero, virgola mobile, costanti, matrici), poiché le funzioni che assumono i puntatori possono essere scomode da tradurre in alcune lingue

3. Avere i propri tipi di dati numerici, che specificano precisione e firma (mentre int float ecc può differire)

L'API risultante non è necessariamente la migliore API C che potresti scrivere se hai come target solo gli utenti C. Tuttavia, significa che le funzioni possono essere quasi direttamente esposte ad un'altra lingua (ad esempio i documenti PyOpenGL elencano le differenze, la maggior parte che sono piuttosto minimali)

Oltre a questa verbosa API, puoi scrivere più wrapper "developer friendly" attorno a questo (framework di gioco e simili)