Within an organisation, suppose you have an internal tool used by different teams and for different use cases. This package offers APIs in different languages.

  • One could say that having multiple APIs enables more people to use the tool, as they don't have to learn a new language and can use their favorite one.
  • On the other hand, one could also argue that this makes code reuse more difficult. If team A uses language X and develops a nice script using the tool, team B can reuse the script only if they also work in language X.

My question is: from your experience, what is the global impact of having multiple APIs (potentially more people using the tool, but they can't share their code) or a single one (less people using the tool, but they can share their code)?


Example

An organisation has created an internal package to get weather forecast, with Python and C APIs.

One team working with Python creates a new component out of that, which aggregates weather forecast and also traffic (with the help of another tool) for the user's position.
While this code is useful, it has nothing to do within the weather forecast tool's API and it's not generic/bullet-proof/meaningful enough to become a separate package.

Another team working with Python could reuse this new component with some minor adjustments while the team working with C would have to rewrite the whole component from scratch.

  • The second argument is obviously flawed. "If team A uses language X and develops a nice function", but without "using the tool", because it does not offer an API for language X, then team B can also reuse the function only if they also work in language X. This has nothing to do with the availability of multiple APIs. – Doc Brown Nov 9 at 15:19
  • Functions that you want to reuse should be implemented in the libraries/api's, never on the implementing side. – fstam Nov 9 at 16:21
  • Is this API intended for use outside the team, e.g. for the general public? Or is this an internal API? – John Wu Nov 9 at 17:34
  • @JohnWu In this case, it would be internal only but not within a team only. – filaton 2 days ago
  • @DocBrown Sorry, I think the term "function" here was not the most appropriate. Please see my updated answer with the example :) – filaton 2 days ago

Providing multiple API's does not reduce your own projects ability to reuse its own code between those API's (when well engineered), nor does it limit the ability to share code between projects (otherwise we would have to rewrite the operating system each time we make a new program).

I'm going to rephrase your question as:

Does providing multiple API's limit my clients ability to share and reuse code?

Short answer: no.

Longer answer: Other stuff does, not the number of API's.

Reuse itself has no technical barrier that cannot be easily overcome. Particularly in this day and age.

There are many libraries out there that allow one language to call into another*. This might be done by interpreting the other program (embedded put-on, lua, tcl, etc... (even c)), or by marshalling the call across to the compiled component such as by JNI, COM, HTTP, SOAP, etc..., or even by directly/dynamically linking the component.

Even if the component does not already support it, it should be reasonably possible to provide a shell for the component which allows shell scripting (available from any desktop/server language) to work with it.

So from a user perspective, there is no technical reason why they could not share their nice script, with someone else who wishes to use it.

The main issue is in fact the issue of any public service/library maintainer. When you share code there are a number of incidental responsibilities.

  • It needs to be reliable - This code is being depended on, it must work, or reasonably fail.
  • It needs to be stable - Updates should preserve the interface behaviour. Breaking changes should be flagged, have work-arounds, and migration paths.
  • It needs to be documented - You can't use even the nicest script without knowing how.
  • It needs to be maintained - Bugs happen, Vulnerabilities are discovered, upstream systems change. These have to be solved.
  • It needs to be distributed - Code that you can't access is unusable, whether behind a service, in a binary, or as source.
  • It needs feedback loops (a community) - Code is just an artefact of a community of individuals who know the problem being solved, that is the most important thing ever. The code is just the best guess at a solution.

I would not consider making my software dependent on other software that does not have at least these incidental properties. As an API provider you are aware how non-trivial these things can be.

If your own clients ability to share code is crucial to your platform/application. Consider offering GitHub like services, or some form of package manager. This would reduce the burden of these incidentals on the downstream developers, while also reducing the burden on their clients. It would additionally improve the sense of community around your own software, bringing those individuals into contact with each other. They will figure out how to specifically reuse each others code.

*Side Note: C can embed a fully featured python environment, and Python can easily be extended by C libraries.

New contributor
Kain0_0 is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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