Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 29 down vote favorite
9

I'd like to find a way to write an API that can be accessed from any other programming language via language bindings (or some other framework). Is it possible to do this? If so, which programming language would be the most suitable for writing a "cross-language" API? My goal is to create a single set of functions that I can access from any programming language that I'm working with, so that I won't need to manually re-write the entire API in each language.

share|improve this question
4  
If you just want to be able to say "we support EVERYTHING" for marketing reasons, you can just write a low-level DLL or shared library in C. If you want anybody in say, Java, to use your thingy, you'd better provide a Java interface. – mjfgates Jul 20 '12 at 7:59
1  
You say "(almost) any", which languages would you exclude for this purpose? Or which are the most important to you? – funkybro Jul 20 '12 at 8:12
20  
Webservice? You can write some functions in for instance php. Almost any language has the posibility to interface with webpages, supply arguments and read the results. – Pieter B Jul 20 '12 at 8:28
5  
+1 'cause it's an interesting question - but your question would be improved by saying why you want to do this. What are your goals? – TarkaDaal Jul 20 '12 at 8:28
@PieterB => answer. – Konrad Rudolph Jul 20 '12 at 13:05
show 2 more comments

10 Answers

up vote 40 down vote accepted

You have a few options:

  1. Create an HTTP interface, almost everything can talk HTTP so that will get you a lot of languages.

  2. Create something that can be linked into a language runtime, this will be rather time consuming as you will need to find a way to connect it to many different languages.

share|improve this answer
What kind of HTTP interface do you have in mind, specifically? – Anderson Green Jul 20 '12 at 16:01
@AndersonGreen It shouldn't matter (since any language that can open a network socket can speak HTTP), but REST is a useful pseudo-standard. – Brendan Long Jul 20 '12 at 16:12
6  
REST + JSON would be a reasonable solution – David Hayes Jul 20 '12 at 17:53
I also agree, using HTTP to communicate allows pretty much every language out there to interact with your application's functions. – Only Bolivian Here Jul 26 '12 at 21:29
up vote 25 down vote

I think C or C++ would be most suitable for your purpose. You can use SWIG to generate language bindings from your C or C++ API.

share|improve this answer
2  
SWIG is a great tool. – Joset Jul 20 '12 at 4:47
26  
C++ would be an awful choice. There are numerous problems with it: dependency on a runtime library, unspecified ABI (especially mangling), etc. Generating bindings from C++ headers is prohibitively tricky. SWIG is quite a limited thing. See all the overcomplicated infrastructure around, say, Python Qt bindings. – SK-logic Jul 20 '12 at 8:04
10  
@SK-logic: Not really. C needs a runtime lib just like C++. The ABI can be controlled in C++ via extern "C" so it is C-compatible on the outside. Hence, you do have the internal advantages of C++ (higher type-safety, libraries) but the external advantages of C (de facto ABI standard) – MSalters Jul 20 '12 at 9:12
2  
@SK-logic The unspecified ABI is simply a solved problem, see SWIG, Boost.Python and a host of other language bindings. – Konrad Rudolph Jul 20 '12 at 13:04
3  
@MSalters don't forget about exceptions and their general non-workiness across library boundaries – sehe Jul 20 '12 at 13:07
show 5 more comments
up vote 18 down vote

There are pretty much 2 ways:

  • a C API. Practically ever language there ever was will load a C library and call its functions. How you do this depends on the source language.
  • a RPC mechanism of some sort. This can be a REST API running over HTTP, or a binary interface running over a socket. Unless you go for the lowest common denominator mechanism (eg a socket) you run the risk of not having client access routines (eg some languages do not have the right SOAP clients to call an API implemented using SOAP, or there are interoperability issues). Stick to the simplest, either a HTTP/REST interface, or a socket. Sockets have the advantage that they do not need a HTTP server to expose the interface to the clients, and can more easily run on the same server as the client with better performance.

The work required for this changes depending on the system used, for example, a socket interface will work, but client-side libraries tend to be more low-level compared to http libraries.

You could try finding a networking library that supports all the languages you want to use, and implement the API in terms of that library - eg, using ZeroMQ gives you a lot of flexibility, so you'd write your API using ZeroMQ interfaces, and then any language that wants to call your API must use the ZeroMQ client library to do so. Choose a library that supports a broad range of languages, and allows you to in-process as well as out-of-process communication for best performance.

share|improve this answer
So what steps would I need to take if I wanted to write the API in multiple languages as well? (In my case, those languages would be Javascript, C++, and Java.) – Anderson Green Jul 22 '12 at 3:14
Should I just write 3 separate RESTful APIs for each of the languages? – Anderson Green Jul 22 '12 at 5:38
You write a native wrapper in each of these languages that handles the loading and calling the underlying C dll. Or write it in C++ and use SWIG to do this for you. If you're using a REST API, then the same applies, either write a single API and then 3 wrappers, but if you're writing a REST API then each language will be able to call the REST API directly - don't bother with a wrapper. – gbjbaanb Jul 25 '12 at 10:44
Would the dll (dynamically linked library) be compatible any platform besides Windows? I need cross-platform compatibility here. – Anderson Green Jul 25 '12 at 22:59
no, you'd need to recompile it for other platforms. Linux for example uses .so instead of .dll. Just a straight recompile is needed, no (or very minor) code changes. – gbjbaanb Jul 29 '12 at 13:52
up vote 10 down vote

If performance and call latency is not an issue, consider providing a comprehensive command line interface (probably, using a scripting language on top of it). ImageMagick can be a good example of such an "API". Another good example is Tk toolkit.

share|improve this answer
Which scripting language and/or programming language would you recommend for the purpose of creating a command line foreign function interface? Also, have you found any concrete examples of such interfaces? – Anderson Green Jul 27 '12 at 3:34
@AndersonGreen, any language with decent metaprogramming is ok for such a purpose. E.g., Scheme, MetaLua, various other embeddable Lisps, Tcl. You can easily implement your own command language as well. Many CAD/CAE systems operate this way. An already mentioned Tk is another typical example. – SK-logic Jul 27 '12 at 8:15
In order to use a command-line interface in this way, would you get the console output for a specific command (such as whoami on Ubuntu to get the username), or did you have something else in mind? – Anderson Green Dec 13 '12 at 20:46
@AndersonGreen, piping stdin and stdout should be sufficient in most cases. – SK-logic Dec 13 '12 at 20:52
up vote 3 down vote

By API, what exactly do you mean?

On many platforms you could link to a DLL or similar construction, but would having to be re-compiled for a particular native target (Intel/ARM) or endianness still qualify? A particular binary interface might still have difficulties with certain languages because of datatype issues or constructs (pointers trying to be returned to languages which don't support them well), so you would also have to consider the design of the API itself so as not to exclude some languages or make its use from those languages cumbersome.

Something portable like C and an interface based on binary endpoints in a DLL might be fine and generally callable on most platforms and from most languages, but it might need to be compiled differently and/or offered in different flavors or linked to different static libraries.

It seems to me that the choice of language you write your library or service or whatever is, by definition, not intrinsic to the question until you've given more about the platform/service the API exposes. If you can assume a network stack is available and direct-linked function-call-level performance is not a requirement, the API could easily be HTTP-based with some kind of shim for the client language to make the requests transparent.

I think in general this question is overly broad to be useful in the real world, because you haven't given indication about what kind of API might be suitable given the type of service which is being offered.

share|improve this answer
2  
+1 for overly broad question. – MichaelT Jul 20 '12 at 16:39
up vote 0 down vote

Have any language write out a text file with function to call with params to pass in. Have your "I get along with anybody" app watching a directory and once it sees a process-call.txt have it go to work. No servers or network protocols; even a non-computer language method can init the functions. Even a person could just create the text file.

Content could look like: 

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

;) you might wait forever to get an answer though. You just need to push a few bytes to the other process, but I'm sure that's not the whole spec.

share|improve this answer
Seems overly complicated when you could just have a command-line interface + stdin/stdout. – Brendan Long Jul 20 '12 at 16:15
Even better call can ++1 that, Brendan. I never saw it in action but once upon a time people were punching holes in card to transfer the bytes around. – Pareshkumar Jul 20 '12 at 20:58
2  
This is a joke answer, right? We don't do that here. – Ernest Friedman-Hill Jul 21 '12 at 1:15
Well the fdisk and /root part is a joke, but the I was involved as a platform r&d (developer and analyst) for over 5 years to create a platform-product that produced good in the 10's of millions of dollars. It's spit out millions of shippable physical (not pdf and emails) items for client (with processing Files ranging in hundreds of MBs per item) using this type of REST method. We had major system triolgy-SAP-MS Office-PLC Drivewrs-PDF Workflow all taking to each other and working well together with plain-old-UTF-8-text files and a zip with-in a zip with-in a zip, and no HTTP bs overhead. – Pareshkumar Jul 21 '12 at 3:20
May I ask a question? Why does no one think that JSON is a joke? How is what I recomended any different? We would/might have used json but it wasn't around in 2003. XML is too fat, but back then that was the flavor of the month not the most pratical and simplest soulition. – Pareshkumar Jul 21 '12 at 3:35
show 3 more comments
up vote 0 down vote

OpenGL is a good example of what you describe - it's an API written in C, designed in a way that is easy to write bindings for in other languages

  1. C libraries can be called from most programming languages (usually as compiled extensions, or things like PyPy's ctypes library etc)

  2. All functions take simple data-types as arguments (boolean, integer, floating point, constants, arrays), as functions taking pointers can be awkward to translate into some languages

  3. Having it's own numeric data-types, which specify precision and signed'ness (whereas int float etc can differ)

The resulting API isn't necessarily the nicest-to-use C API you could write if targeting only C users. However it means the functions can be almost directly exposed to another language (e.g the PyOpenGL docs list the differences, most of which are pretty minimal)

On top of this verbose API, you can write more "developer friendly" wrappers around this (game frameworks and such)

share|improve this answer
up vote 0 down vote

To add to above answers that suggest using an RPC mechanism. You could use Apache Thrift.(http://thrift.apache.org/). It is basically a RPC framework.

As per the Thrift wiki:

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

share|improve this answer
How can foreign function calls be done using Apache Thrift? – Anderson Green Sep 3 '12 at 2:46
up vote -2 down vote

One other preference would be considering The .NET Persistence API, also referred to as NPA.

One of the goals it has is to provide a cross language persistence API by extending the popular Java Persistence API (JPA) to all the .NET programming languages.

More official information is located @ .NET Persistence API.

share|improve this answer
3  
"to all the .NET programming languages" is not "all languages". MS hasn't made an IronPerl, IronJavascript, IronBash or IronC AFAIK. – gbjbaanb Jul 20 '12 at 16:00
3  
Unclear how this answers the original question; not only is it only applicable to .NET, but it's a persistence API, not a call mechanism. – Ernest Friedman-Hill Jul 21 '12 at 1:16
up vote -3 down vote

Simple. You just have to write a program that is a polyglot over your language requirements:

http://en.wikipedia.org/wiki/Polyglot_%28computing%29

share|improve this answer
3  
That is not a practical answer. – Daenyth Jul 20 '12 at 14:29
2  
...Are you joking? – Peter Olson Jul 20 '12 at 15:58
Have you found any practical applications of this approach so far (where an entire polyglot API has been successfully implemented)? – Anderson Green Mar 18 at 17:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.