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

Mi piacerebbe trovare un modo per scrivere un'API a cui è possibile accedere da qualsiasi altro linguaggio di programmazione tramite collegamenti linguistici (o qualche altro framework). È possibile farlo? In tal caso, quale linguaggio di programmazione sarebbe il più adatto per scrivere un'API "cross-language"? Il mio obiettivo è quello di creare un singolo set di funzioni a cui posso accedere da qualsiasi linguaggio di programmazione con cui sto lavorando, in modo da non dover riscrivere manualmente l'intera API in ogni lingua.

Hai alcune opzioni:

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

2. Crea qualcosa che può essere collegato in un runtime linguistico, questo richiederà piuttosto tempo in quanto dovrai trovare un modo per collegarlo a molte lingue diverse.

Penso che C o C ++ siano i più adatti al tuo scopo. È possibile utilizzare SWIG (Simple Wrapper and Interface Generator) per generare collegamenti linguistici dall'API C o C ++.

SWIG è uno strumento di sviluppo software che collega i programmi scritti in C e C ++ con una varietà di linguaggi di programmazione di alto livello. SWIG viene utilizzato con diversi tipi di lingue di destinazione, inclusi linguaggi di scripting comuni come Perl, PHP, Python, Tcl e Ruby. L'elenco delle lingue supportateinclude anche linguaggi non di scripting come C #, Common Lisp (CLISP, Allegro CL, CFFI, UFFI), D, Go language, Java compreso Android, Lua, Modula-3, OCAML, Octave e R. Anche diversi schemi interpretati e compilati sono supportate implementazioni (Guile, MzScheme / Racket, Chicken). SWIG è più comunemente usato per creare ambienti di programmazione interpretati o compilati di alto livello, interfacce utente e come strumento per testare e prototipare il software C / C ++. SWIG viene in genere utilizzato per analizzare le interfacce C / C ++ e generare il "codice colla" richiesto per le lingue di destinazione sopra indicate per chiamare nel codice C / C ++. SWIG può anche esportare il suo albero di analisi sotto forma di espressioni s-XML e Lisp. SWIG è un software gratuito e il codice generato da SWIG è compatibile con progetti sia commerciali che non commerciali ...

Ci sono praticamente 2 modi:

• un'API C. Praticamente ogni linguaggio mai esistito caricherà una libreria C e chiamerà le sue funzioni. Come lo fai dipende dalla lingua di partenza.
• un meccanismo RPC di qualche tipo. Può essere un'API REST in esecuzione su HTTP o un'interfaccia binaria in esecuzione su un socket. A meno che non si scelga il meccanismo di denominazione comune più basso (ad es. Un socket) si corre il rischio di non avere routine di accesso al client (ad es. Alcune lingue non hanno i client SOAP giusti per chiamare un'API implementata tramite SOAP o ci sono problemi di interoperabilità). Attenersi alla più semplice, un'interfaccia HTTP / REST o un socket. I socket hanno il vantaggio di non avere 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 queste modifiche dipende dal sistema utilizzato, ad esempio un'interfaccia socket funzionerà, ma le librerie lato client tendono ad essere di livello più basso 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 scriveresti l'API utilizzando le interfacce ZeroMQ e quindi qualsiasi lingua che desideri chiamare l'API deve utilizzare la libreria client ZeroMQ per farlo. Scegli una libreria che supporti una vasta gamma di lingue e ti permetta di comunicare in-process e out-of-process per ottenere le migliori prestazioni.

Se le prestazioni e la latenza delle chiamate non rappresentano un problema, è consigliabile fornire un'interfaccia a riga di comando completa (probabilmente, utilizzando un linguaggio di scripting al di sopra 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 ri-compilare per un determinato target nativo (Intel / ARM) o endianness ancora qualificarsi? Una particolare interfaccia binaria potrebbe avere ancora difficoltà con alcuni linguaggi a causa di problemi o costrutti di tipi di dati (puntatori che cercano di essere restituiti a linguaggi che non li supportano bene), quindi dovresti anche considerare il design dell'API stessa in modo da non per escludere alcune lingue o farne uso ingombrante da quelle lingue.

Qualcosa di portatile come C e un'interfaccia basata su endpoint binari in una DLL potrebbe andare bene e generalmente richiamabile sulla maggior parte delle piattaforme e dalla maggior parte delle lingue, ma potrebbe aver bisogno di essere compilato in modo diverso e / o offerto in diversi gusti o collegato a diverse librerie statiche.

Mi sembra che la scelta della lingua in cui scrivi la tua biblioteca o il tuo servizio o qualsiasi altra cosa, per definizione, non sia intrinseca alla domanda fino a quando non avrai dato di più sulla piattaforma / servizio che l'API espone. Se si può presumere che sia disponibile uno stack di rete e che le prestazioni a livello di chiamata a funzione diretta non siano un requisito, l'API potrebbe facilmente essere basata su HTTP con un qualche tipo di shim per la lingua del client per rendere trasparenti le richieste.

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

Aggiungere alle risposte precedenti che suggeriscono di utilizzare un meccanismo RPC. Potresti usare Apache Thrift. ( Http://thrift.apache.org/ ). È fondamentalmente un framework RPC.

Secondo la wiki di Thrift:

Il framework software Apache Thrift, per lo sviluppo di servizi in più lingue scalabili, combina uno stack software con un motore di generazione di codice per creare servizi che funzionano in modo efficiente e senza soluzione di continuità tra C ++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C #, Cocoa, JavaScript, Node.js, Smalltalk, OCaml e Delphi e altre lingue

Chiedi a qualsiasi lingua di scrivere un file di testo con la funzione da chiamare con i parametri da trasmettere. Fai in modo che la tua app "Vado d'accordo con chiunque" guardi una directory e una volta che vede un processo-call.txt farlo funzionare. Nessun server o protocolli di rete; anche un metodo non linguistico può avviare le funzioni. Anche una persona potrebbe semplicemente creare il file di testo.

Il contenuto potrebbe apparire come:

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

;) potresti aspettare per sempre per ottenere una risposta. Devi solo spingere qualche byte nell'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 per cui è facile scrivere i collegamenti 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 ctypeslibreria di PyPy ecc.)

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

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

L'API risultante non è necessariamente l'API C più bella da usare che potresti scrivere se si rivolge solo agli utenti C. Tuttavia, significa che le funzioni possono essere esposte quasi direttamente a un'altra lingua (ad esempio i documenti PyOpenGL elencano le differenze, la maggior parte delle quali sono piuttosto minime)

Oltre a questa API dettagliata, puoi scrivere più wrapper "per sviluppatori" attorno a questo (framework di gioco e simili)