CODEWITHSUNDEEP
socketsserverdesktop-applicationinteractive-brokersib-api
limestreetlab
limestreetlab

Reputation: 328

How does a desktop application's API work?

It is my understanding, right or wrong, that desktop applications communicate with each other via sockets over localhost, similar to how a web server and local client use sockets or websockets.

For web-based APIs, both sockets and REST are language-agnostic, right? They can be requested regardless of the client app language.

For desktop app APIs, such as Bloomberg or Interactive Brokers, they are documented to use TCP socket connections.

When the Interactive Brokers API says it supports Python, Java, C++, C#, the downloaded API folder includes source codes for each such language and such respective classes/modules must be imported into the client codes to invoke the API calls. So if I use Java, the API Java classes must be in the classpath and imported.

The InteractiveBrokers application is coded in Java. When a function is invoked from API, it shouldn't matter at all for that app what API language the client is using, right? So when a Python or Java API user calls placeOrder(what, where, price), the very same Java-coded function is invoked after receiving the parameters, right? As long as connection is set up, the functions can be invoked as long as the correct signatures are used right, so why the client language matters?

My question is, when a desktop app has an API (TCP connection), is the communication with the client app language-agnostic like a web app API? If so, when the API says it supports language Python Java and C#, doesn't it only mean it provides some neccesary source codes in those languages to be imported. In other words, if some 3rd-party can replicate those exact source codes in another langauge like Go, can't the client then use the API in that language?

Upvotes: -2

Views: 549

Answers (1)

Stephen C
Stephen C

Reputation: 719386

I'm not going to address some of the questionable assumptions about how "desktop APIs" work. Or, indeed about what a "desktop API" actually is.

Now to your questions:

My question is, when a desktop app has an API (TCP connection), is the communication with the client app language-agnostic like a web app API?

It depends on the application. You can't infer that all of an application's APIs provide the same functionality ... of that the functionality works the same way.

If so, when the API says it supports language Python Java and C#, doesn't it only mean it provides some necessary source codes in those languages to be imported.

This is is independent of the previous question.

Yes, that is probably correct. (But note that there is a distinction between what a specification document says, and what has actually been implemented.)

In other words, if some 3rd-party can replicate those exact source codes in another langauge like Go, can't the client then use the API in that language?

That is yet another question.

But again, the answer is probably yes. But it is conceivable that the API is actually multiple APIs (at the protocol level) that each support a different language. Check the API specification (if it exists) or the source code for the existing vendor supplied client libraries (if it is available).

The InteractiveBrokers application is coded in Java. When a function is invoked from API, it shouldn't matter at all for that app what API language the client is using, right?

Once again, it depends on the API.

If we assume that the application and the client communicate over a socket, then they have to turn every interaction into an exchange of sequences of bytes. For example, when the client "calls" the application, something converts the call and its parameters to a "message" encoded as bytes. And at the application end, they are decoded. And the same thing happens for the information returned as the result of the call.

If the client and application are implemented in the same language, you only need one implementation of the encoding / decoding. But, if there are multiple languages, multiple implementations are required. Sometimes that is easy, sometimes not. For example, if the application is implemented in Java and it has based its API on Java Object Serialization, then that becomes a significant problem. Decoding Java serialized objects into (say) Python data structures is hard, and going in the other direction is even harder.

Having said all of that, I don't really see the point of this question:

  • On the one hand, almost anything is possible in theory.
  • On the other hand, availability of client libraries for specific APIs will depend on whether someone has decided to invest the time to implement and maintain them. In the worst case, you may need to invest the effort yourself.

But this is all ... basically ... obvious.

Upvotes: 1

Related Questions