Como posso escrever um conjunto de funções que podem ser chamadas de (quase) qualquer linguagem de programação?

Gostaria de encontrar uma maneira de escrever uma API que possa ser acessada de qualquer outra linguagem de programação por meio de ligações de linguagem (ou alguma outra estrutura). É possível fazer isso? Em caso afirmativo, qual linguagem de programação seria a mais adequada para escrever uma API "entre idiomas"? Meu objetivo é criar um único conjunto de funções que eu possa acessar a partir de qualquer linguagem de programação com a qual estou trabalhando, para não precisar reescrever manualmente a API inteira em cada idioma.

Você tem poucas opções:

1. Crie uma interface HTTP, quase tudo pode falar HTTP, para que você obtenha muitas linguagens.

2. Crie algo que possa ser vinculado a um tempo de execução do idioma. Isso consumirá bastante tempo, pois você precisará encontrar uma maneira de conectá-lo a vários idiomas diferentes.

Eu acho que C ou C ++ seria mais adequado para o seu propósito. Você pode usar SWIG (Wrapper simplificado e gerador de interface) para gerar ligações de idioma a partir da sua API C ou C ++.

SWIG é uma ferramenta de desenvolvimento de software que conecta programas escritos em C e C ++ com uma variedade de linguagens de programação de alto nível. SWIG é usado com diferentes tipos de linguagens de destino, incluindo linguagens de script comuns como Perl, PHP, Python, Tcl e Ruby. A lista de idiomas suportadostambém inclui linguagens sem script, como C #, Common Lisp (CLISP, Allegro CL, CFFI, UFFI), linguagem D, Go, Java incluindo Android, Lua, Modula-3, OCAML, Octave e R. Também vários esquemas interpretados e compilados implementações (Guile, MzScheme / Racket, Chicken) são suportadas. O SWIG é mais comumente usado para criar ambientes de programação interpretados ou compilados de alto nível, interfaces de usuário e como uma ferramenta para testar e criar protótipos de software C / C ++. O SWIG é normalmente usado para analisar interfaces C / C ++ e gerar o 'código de cola' necessário para que os idiomas de destino acima chamem no código C / C ++. O SWIG também pode exportar sua árvore de análise na forma de expressões XML e Lisp. O SWIG é um software livre e o código que o SWIG gera é compatível com projetos comerciais e não comerciais ...

Existem basicamente duas maneiras:

• uma API C. Praticamente todas as linguagens existentes carregarão uma biblioteca C e chamarão suas funções. Como você faz isso depende do idioma de origem.
• um mecanismo RPC de algum tipo. Pode ser uma API REST executando HTTP ou uma interface binária executando um soquete. A menos que você opte pelo menor mecanismo de denominador comum (por exemplo, um soquete), corre o risco de não ter rotinas de acesso ao cliente (por exemplo, alguns idiomas não têm os clientes SOAP certos para chamar uma API implementada usando SOAP, ou há problemas de interoperabilidade). Atenha-se ao mais simples, uma interface HTTP / REST ou um soquete. Os soquetes têm a vantagem de não precisarem de um servidor HTTP para expor a interface aos clientes e podem ser executados mais facilmente no mesmo servidor que o cliente com melhor desempenho.

O trabalho necessário para essas alterações, dependendo do sistema usado, por exemplo, uma interface de soquete funcionará, mas as bibliotecas do lado do cliente tendem a ter um nível mais baixo em comparação às bibliotecas http.

Você pode tentar encontrar uma biblioteca de rede que ofereça suporte a todos os idiomas que deseja usar e implementar a API em termos dessa biblioteca - por exemplo, o uso do ZeroMQ oferece muita flexibilidade, para que você escreva sua API usando as interfaces do ZeroMQ e qualquer idioma que queira chamar sua API deve usar a biblioteca do cliente ZeroMQ para fazer isso. Escolha uma biblioteca que ofereça suporte a uma ampla variedade de idiomas e permita a comunicação em processo e fora de processo para obter o melhor desempenho.

Se o desempenho e a latência de chamadas não forem um problema, considere fornecer uma interface abrangente de linha de comando (provavelmente, usando uma linguagem de script em cima dela). O ImageMagick pode ser um bom exemplo dessa "API". Outro bom exemplo é o kit de ferramentas Tk.

Por API, o que exatamente você quer dizer?

Em muitas plataformas, você poderia vincular a uma DLL ou construção semelhante, mas teria que ser recompilado para um destino nativo específico (Intel / ARM) ou endianness ainda se qualificaria? Uma interface binária específica ainda pode ter dificuldades com certos idiomas devido a problemas ou construções de tipo de dados (ponteiros tentando retornar para idiomas que não os suportam bem), portanto, você também deve considerar o design da própria API para não excluir alguns idiomas ou fazer com que esses idiomas sejam pesados.

Algo portátil como C e uma interface baseada em pontos de extremidade binários em uma DLL podem ser bons e geralmente acessíveis na maioria das plataformas e na maioria dos idiomas, mas pode precisar ser compilado de forma diferente e / ou oferecido em diferentes sabores ou vinculado a diferentes bibliotecas estáticas.

Parece-me que a escolha do idioma em que você escreve sua biblioteca ou serviço ou o que quer que seja, por definição, não é intrínseca à questão até que você dê mais informações sobre a plataforma / serviço que a API expõe. Se você puder assumir que uma pilha de rede está disponível e o desempenho no nível da chamada da função vinculado diretamente não for um requisito, a API poderá ser facilmente baseada em HTTP com algum tipo de correção para que o idioma do cliente torne as solicitações transparentes.

Eu acho que, em geral, essa questão é muito ampla para ser útil no mundo real, porque você não deu indicação sobre que tipo de API pode ser adequado, dado o tipo de serviço que está sendo oferecido.

Para adicionar às respostas acima que sugerem o uso de um mecanismo RPC. Você pode usar o Apache Thrift. ( Http://thrift.apache.org/ ). É basicamente uma estrutura RPC.

De acordo com o wiki Thrift:

A estrutura de software Apache Thrift, para desenvolvimento de serviços escaláveis ​​em vários idiomas, combina uma pilha de software com um mecanismo de geração de código para criar serviços que funcionam de maneira eficiente e sem problemas entre C ++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C #, Cacau, JavaScript, Node.js, Smalltalk, OCaml e Delphi e outros idiomas

Qualquer idioma escreva um arquivo de texto com a função para chamar params para passar. Faça com que o aplicativo "eu me dou bem com alguém" assista a um diretório e, quando ele vir um processo-call.txt, faça com que ele funcione. Nenhum servidor ou protocolo de rede; mesmo um método de linguagem que não seja de computador pode iniciar as funções. Mesmo uma pessoa poderia apenas criar o arquivo de texto.

O conteúdo pode ter a seguinte aparência:

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

;) você pode esperar uma eternidade para obter uma resposta. Você só precisa enviar alguns bytes para o outro processo, mas tenho certeza de que essa não é a especificação completa.

O OpenGL é um bom exemplo do que você descreve - é uma API escrita em C, projetada de maneira fácil para escrever ligações em outros idiomas

1. As bibliotecas C podem ser chamadas da maioria das linguagens de programação (geralmente como extensões compiladas ou coisas como a ctypesbiblioteca do PyPy, etc.)

2. Todas as funções aceitam tipos de dados simples como argumentos (booleano, inteiro, ponto flutuante, constantes, matrizes), pois funções que usam ponteiros podem ser difíceis de traduzir para alguns idiomas

3. Ter seus próprios tipos de dados numéricos, que especificam precisão e sinalização (enquanto int floatetc podem ser diferentes)

A API resultante não é necessariamente a API C mais agradável de usar que você poderia escrever se visasse apenas usuários C. No entanto, isso significa que as funções podem ser quase diretamente expostas a outro idioma (por exemplo, os documentos do PyOpenGL listam as diferenças, a maioria das quais é bastante mínima)

Além dessa API detalhada, você pode escrever mais wrappers "amigáveis ​​ao desenvolvedor" em torno disso (estruturas de jogos e outras)