Difference between revisions of "Application programming interface (API)"

From LIMSWiki
Jump to navigationJump to search
(Removing unrelevant links)
Line 34: Line 34:


For instance: the <code>math.h</code> include file for the C language contains the definition of the function prototypes of the mathematical functions available in the C language library for mathematical processing (usually called <code>libm<code>).
For instance: the <code>math.h</code> include file for the C language contains the definition of the function prototypes of the mathematical functions available in the C language library for mathematical processing (usually called <code>libm<code>).
This file describes how to ''use'' the functions included in the given library: the [[function prototype]] is a [[function signature|signature]] that describes the number and types of the parameters to be passed to the functions and the type of the return value.   
This file describes how to ''use'' the functions included in the given library: the function prototype is a signature that describes the number and types of the parameters to be passed to the functions and the type of the return value.   


The ''behavior'' of the functions is usually described in more details in a human readable format in printed books or in electronic formats like the man pages: e.g. on [[Unix]] systems the command  
The ''behavior'' of the functions is usually described in more details in a human readable format in printed books or in electronic formats like the man pages: e.g. on [[Unix]] systems the command  
Line 96: Line 96:
In this case the API can be interpreted as the two methods <code>pop()</code> and <code>push()</code>, or, more generally, as the ''idea'' that one can use an item of type <code>Stack</code> that implements the behavior of a stack: a pile ''exposing'' its top to add/remove elements.
In this case the API can be interpreted as the two methods <code>pop()</code> and <code>push()</code>, or, more generally, as the ''idea'' that one can use an item of type <code>Stack</code> that implements the behavior of a stack: a pile ''exposing'' its top to add/remove elements.


This concept can be carried to the point where a class interface in an API has no methods at all, but only behaviors associated with it. For instance, the Java language and Lisp API include the interface <code>Serializable</code>, which requires that each class that implements it should behave in a [[Serialization|serialized]] fashion. This does not require to have any public method, but rather requires that any class that implements it to have a representation that can be ''saved'' (serialized) at any time (this is typically true for any class containing simple data and no link to external resources, like an open connection to a file, a remote system, or an external device).
This concept can be carried to the point where a class interface in an API has no methods at all, but only behaviors associated with it. For instance, the Java language and Lisp API include the interface <code>Serializable</code>, which requires that each class that implements it should behave in a serialized fashion. This does not require to have any public method, but rather requires that any class that implements it to have a representation that can be ''saved'' (serialized) at any time (this is typically true for any class containing simple data and no link to external resources, like an open connection to a file, a remote system, or an external device).


In this sense, in object oriented languages, the API defines a set of object behaviors, possibly mediated by a set of class methods.  
In this sense, in object oriented languages, the API defines a set of object behaviors, possibly mediated by a set of class methods.  
Line 115: Line 115:


==Web APIs==
==Web APIs==
When used in the context of [[web development]], an API is typically a defined set of Hypertext Transfer Protocol ([[HTTP]]) request messages, along with a definition of the structure of response messages, which is usually in an Extensible Markup Language ([[XML]]) or JavaScript Object Notation ([[JSON]]) format. While "Web API" is virtually a synonym for [[web service]], the recent trend (so-called Web 2.0) has been moving away from Simple Object Access Protocol (SOAP) based services towards more direct Representational State Transfer (REST) style communications.<ref>
When used in the context of web development, an API is typically a defined set of Hypertext Transfer Protocol ([[HTTP]]) request messages, along with a definition of the structure of response messages, which is usually in an Extensible Markup Language ([[XML]]) or JavaScript Object Notation ([[JSON]]) format. While "Web API" is virtually a synonym for [[web service]], the recent trend (so-called Web 2.0) has been moving away from Simple Object Access Protocol (SOAP) based services towards more direct Representational State Transfer (REST) style communications.<ref>
{{cite web
{{cite web
  |first      = Djamal
  |first      = Djamal
Line 127: Line 127:
  |year        = 2008
  |year        = 2008
}}
}}
</ref> Web APIs allow the combination of multiple services into new applications known as  [[Mashup_(web_application_hybrid)|mashups]].<ref>
</ref> Web APIs allow the combination of multiple services into new applications known as  Mashup_(web_application_hybrid)|mashups.<ref>
{{citation
{{citation
  |first      = James
  |first      = James
Line 140: Line 140:
The practice of publishing APIs has allowed web communities to create an open architecture for sharing content and data between communities and applications. In this way, content that is created in one place can be dynamically posted and updated in multiple locations on the web.
The practice of publishing APIs has allowed web communities to create an open architecture for sharing content and data between communities and applications. In this way, content that is created in one place can be dynamically posted and updated in multiple locations on the web.
#Photos can be shared from sites like Flickr and Photobucket to social network sites like Facebook and MySpace.
#Photos can be shared from sites like Flickr and Photobucket to social network sites like Facebook and MySpace.
#Content can be embedded, e.g. embedding a presentation from [[Slide hosting services|SlideShare]] on a [[LinkedIn]] profile.
#Content can be embedded, e.g. embedding a presentation from SlideShare on a LinkedIn profile.
#Content can be dynamically posted. Sharing live comments made on [[Twitter]] with a Facebook account, for example, is enabled by their APIs.
#Content can be dynamically posted. Sharing live comments made on Twitter with a Facebook account, for example, is enabled by their APIs.
#Video content can be embedded on sites which are served by another host.
#Video content can be embedded on sites which are served by another host.
#User information can be shared from web communities to outside applications, delivering new functionality to the web community that shares its user data via an open API. One of the best examples of this is the [[Facebook Platform|Facebook Application platform]]. Another is the [[Open Social]] platform.<ref>
#User information can be shared from web communities to outside applications, delivering new functionality to the web community that shares its user data via an open API. One of the best examples of this is the Facebook Application platform. Another is the Open Social platform.<ref>
{{cite web
{{cite web
  |title      = Dynamic Community content via APIs
  |title      = Dynamic Community content via APIs
Line 153: Line 153:


==Implementations==
==Implementations==
The [[POSIX]] standard defines an API that allows a wide range of common computing functions to be written in a way such that they may operate on many different systems ([[Mac OS X]], and various [[Berkeley Software Distribution]]s (BSDs) implement this interface); however, making use of this requires [[Compiler|re-compiling]] for each platform.  A compatible API, on the other hand, allows compiled [[object code]] to function without any changes to the system implementing that API.  This is beneficial to both software providers (where they may distribute existing software on new systems without producing and distributing upgrades) and users (where they may install older software on their new systems without purchasing upgrades), although this generally requires that various software libraries implement the necessary APIs as well.
The [[POSIX]] standard defines an API that allows a wide range of common computing functions to be written in a way such that they may operate on many different systems ([[Mac OS X]], and various Berkeley Software Distributions (BSDs) implement this interface); however, making use of this requires re-compiling for each platform.  A compatible API, on the other hand, allows compiled object code to function without any changes to the system implementing that API.  This is beneficial to both software providers (where they may distribute existing software on new systems without producing and distributing upgrades) and users (where they may install older software on their new systems without purchasing upgrades), although this generally requires that various software libraries implement the necessary APIs as well.


[[Microsoft]] has shown a strong commitment to a backward compatible API, particularly within their [[Windows API]] (Win32) library, such that older applications may run on newer versions of Windows using an executable-specific setting called "Compatibility Mode".<ref>
Microsoft has shown a strong commitment to a backward compatible API, particularly within their Windows API (Win32) library, such that older applications may run on newer versions of Windows using an executable-specific setting called "Compatibility Mode".<ref>
{{cite web
{{cite web
  |author      = Microsoft
  |author      = Microsoft
Line 167: Line 167:
}}</ref>
}}</ref>


[[Apple Inc.]] has shown less concern, breaking compatibility or implementing an API in a slower "emulation mode"; this allows greater freedom in development, at the cost of making older software obsolete. {{Citation needed|date=January 2010}}
Apple Inc. has shown less concern, breaking compatibility or implementing an API in a slower "emulation mode"; this allows greater freedom in development, at the cost of making older software obsolete. {{Citation needed|date=January 2010}}


Among [[Unix-like]] operating systems, there are many related but incompatible operating systems running on a common hardware platform (particularly [[Intel 80386]]-compatible systems).  There have been several attempts to standardize the API such that software vendors may distribute one binary application for all these systems; however, to date, none of these have met with much success.  The [[Linux Standard Base]] is attempting to do this for the [[Linux]] platform, while many of the BSD Unixes, such as [[FreeBSD]], [[NetBSD]], and [[OpenBSD]], implement various levels of API compatibility for both backward compatibility (allowing programs written for older versions to run on newer distributions of the system) and cross-platform compatibility (allowing execution of foreign code without recompiling).
Among [[Unix-like]] operating systems, there are many related but incompatible operating systems running on a common hardware platform (particularly Intel 80386-compatible systems).  There have been several attempts to standardize the API such that software vendors may distribute one binary application for all these systems; however, to date, none of these have met with much success.  The Linux Standard Base is attempting to do this for the [[Linux]] platform, while many of the BSD Unixes, such as FreeBSD, NetBSD, and OpenBSD, implement various levels of API compatibility for both backward compatibility (allowing programs written for older versions to run on newer distributions of the system) and cross-platform compatibility (allowing execution of foreign code without recompiling).


==Release policies==
==Release policies==
The two options for releasing API are:
The two options for releasing API are:


#Protecting information on APIs from the general public. For example, [[Sony]] used to make its official [[PlayStation 2]] API available only to licensed PlayStation developers. This enabled Sony to control who wrote PlayStation 2 [[game]]s. This gives companies quality control privileges and can provide them with potential licensing revenue streams.
#Protecting information on APIs from the general public. For example, Sony used to make its official PlayStation 2 API available only to licensed PlayStation developers. This enabled Sony to control who wrote PlayStation 2 games. This gives companies quality control privileges and can provide them with potential licensing revenue streams.
#Making APIs freely available. For example, [[Microsoft]] makes the [[Microsoft Windows]] API public, and [[Apple Inc.|Apple]] releases its APIs [[Carbon (computing)|Carbon]] and [[Cocoa (API)|Cocoa]], so that software can be written for their [[System platform|platform]]s.
#Making APIs freely available. For example, Microsoft makes the Microsoft Windows API public, and Apple releases its APIs Carbon and Cocoa, so that software can be written for their platforms.


A mix of the two behaviors can be used as well.
A mix of the two behaviors can be used as well.


==ABIs==
==ABIs==
The related term [[application binary interface]] (ABI) is a lower level definition concerning details at the [[assembly language]] level. For example, the [[Linux Standard Base]] is an ABI, while [[POSIX]] is an API.<ref>{{cite web|
The related term Application Binary Interface (ABI) is a lower level definition concerning details at the assembly language level. For example, the Linux Standard Base is an ABI, while [[POSIX]] is an API.<ref>{{cite web|
first=Nick|
first=Nick|
last=Stoughton|
last=Stoughton|
url=https://db.usenix.org/publications/login/2005-04/openpdfs/standards2004.pdf|
url=https://db.usenix.org/publications/login/2005-04/openpdfs/standards2004.pdf|
title=Update on Standards|
title=Update on Standards|
publisher=[[USENIX]]|
publisher=USENIX|
format=PDF|
format=PDF|
year=2005|
year=2005|
Line 192: Line 192:


==API examples==
==API examples==
{{see also|Category:Application programming interfaces}}
* [[Advanced SCSI Programming Interface|ASPI]] for [[SCSI]] device interfacing
* [[Advanced SCSI Programming Interface|ASPI]] for [[SCSI]] device interfacing
* [[Carbon (computing)|Carbon]] and [[Cocoa (API)|Cocoa]] for the [[Apple Macintosh|Macintosh]]
* [[DirectX]] for [[Microsoft Windows]]
* [[DirectX]] for [[Microsoft Windows]]
* [[EHLLAPI]]
* [[EHLLAPI]]
Line 202: Line 200:
* [[OpenCL]] cross-platform API for general-purpose computing for CPUs & GPUs
* [[OpenCL]] cross-platform API for general-purpose computing for CPUs & GPUs
* [[OpenMP]] API that supports multi-platform shared memory multiprocessing programming in C, C++ and Fortran on many architectures, including Unix and Microsoft Windows platforms.
* [[OpenMP]] API that supports multi-platform shared memory multiprocessing programming in C, C++ and Fortran on many architectures, including Unix and Microsoft Windows platforms.
* [[Simple DirectMedia Layer]] (SDL)
* Simple DirectMedia Layer (SDL)
* [[Talend]] integrates its [[data management]] with [[Business process management|BPM]] from [[Bonita Open Solution]]
* Talend integrates its [[data management]] with Business process management (BPM) from Bonita Open Solution
* [[Windows API]]
* Windows API


==Language bindings and interface generators==
==Language bindings and interface generators==
APIs that are intended to be used by more than one [[high-level programming language]] often provide, or are augmented with, facilities to automatically map the API to features (syntactic or semantic) that are more natural in those languages. This is known as [[language binding]], and is itself an API. The aim is to [[Encapsulation (computer science)|encapsulate]] most of the required functionality of the API, leaving a "thin" layer appropriate to each language.
APIs that are intended to be used by more than one high-level programming language often provide, or are augmented with, facilities to automatically map the API to features (syntactic or semantic) that are more natural in those languages. This is known as [[language binding]], and is itself an API. The aim is to encapsulate most of the required functionality of the API, leaving a "thin" layer appropriate to each language.


Below are listed some interface generator tools which bind languages to APIs at [[compile time]].
Below are listed some interface generator tools which bind languages to APIs at [[compile time]].


* [[SWIG]] opensource interfaces bindings generator from many languages to many languages (Typically Compiled->Scripted)
* [[SWIG]] opensource interfaces bindings generator from many languages to many languages (Typically Compiled->Scripted)
* F2PY:<ref>[http://www.f2py.org/ F2PY.org]</ref> [[Fortran (programming language)|Fortran]] to [[Python (programming language)|Python]] interface generator.
* F2PY:<ref>[http://www.f2py.org/ F2PY.org]</ref> Fortran to Python interface generator.
 
==See also==
{{div col|3}}
* [[Application Binary Interface]] – ABI
* [[Calling convention]]
* [[Comparison of application virtual machines]]
* [[Common Object Request Broker Architecture|CORBA]] a cross platform-language standard for intercommunication
* [[Document Object Model]] (DOM)
* [[Double-chance function]]
* [[Foreign function interface]]
* [[Language binding]]
* [[List of 3D graphics APIs]]
* [[Mashup (web application hybrid)]]
* [[Name mangling]]
* [[Open Service Interface Definitions]] (OSID)
* [[Platform-enabled website]]
* [[Plug-in (computing)|Plugin]]
* [[Software Development Kit]] (SDK)
* [[SWIG]] – opensource interfaces bindings generator from many languages to many languages
* [[Web service]]
* [[XPCOM]] (Cross Platform Component Object Model) is a cross platform component model from [[Mozilla]].
{{div col end}}


==References==
==References==
Line 247: Line 223:


{{DEFAULTSORT:Application Programming Interface}}
{{DEFAULTSORT:Application Programming Interface}}
[[Category:Technical communication]]
[[Category:Application programming interfaces|*]]
[[Category:Application programming interfaces|*]]

Revision as of 14:05, 18 August 2011

(This article was taken from Wikipedia)

An application programming interface (API) is a particular set of rules and specifications that software programs can follow to communicate with each other. It serves as an interface between different software programs and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers.

An API can be created for applications, libraries, operating systems, etc., as a way of defining their "vocabularies" and resources request conventions (e.g. function-calling conventions). It may include specifications for routines, data structures, object classes, and protocols used to communicate between the consumer program and the implementer program of the API.[1][2]

Concept

An API can be:

  • general, the full set of an API that is bundled in the libraries of a programming language, e.g. Standard Template Library in C++ or Java API.
  • specific, meant to address a specific problem, e.g. Google Maps API or Java API for XML Web Services.
  • language-dependent, meaning it is only available by using the syntax and elements of a particular language, which makes the API more convenient to use.
  • language-independent, written so that it can be called from several programming languages. This is a desirable feature for a service-oriented API that is not bound to a specific process or system and may be provided as remote procedure calls or web services. For example, a website that allows users to review local restaurants is able to layer their reviews over maps taken from Google Maps, because Google Maps has an API that facilitates this functionality. Google Maps' API controls what information a third-party site can use and how they can use it.

API may be used to refer to a complete interface, a single function, or even a set of APIs provided by an organization. Thus, the scope of meaning is usually determined by the context of usage.

Advanced explanation

An API may describe the ways in which a particular task is performed. In procedural languages like C language the action is usually mediated by a function call.

For instance: the math.h include file for the C language contains the definition of the function prototypes of the mathematical functions available in the C language library for mathematical processing (usually called libm). This file describes how to use the functions included in the given library: the function prototype is a signature that describes the number and types of the parameters to be passed to the functions and the type of the return value.

The behavior of the functions is usually described in more details in a human readable format in printed books or in electronic formats like the man pages: e.g. on Unix systems the command

man 3 sqrt

will present the signature of the function sqrt in the form:

SYNOPSIS
            #include <math.h>
            double sqrt(double X);
            float  sqrtf(float X);
DESCRIPTION
       DESCRIPTION
       sqrt computes the positive square root of the argument. ...
RETURNS
       On success, the square root is returned. If X is real and positive...

That means that the function returns the square root of a positive floating point number (single or double precision) as another floating point number. Hence the API in this case can be interpreted as the collection of the included files used by the C language and its human readable description provided by the man pages.

API in modern languages

Most of the modern programming languages provide the documentation associated with an API in some digital format that makes it easy to consult on a computer. E.g. perl comes with the tool perldoc:

$ perldoc -f sqrt
       sqrt EXPR
       sqrt    #Return the square root of EXPR.  If EXPR is omitted, returns
               #square root of $_.  Only works on non-negative operands, unless
               #you've loaded the standard Math::Complex module.

python comes with the tool pydoc:

$ pydoc math.sqrt
Help on built-in function sqrt in math:
math.sqrt = sqrt(...)
    sqrt(x)
    Return the square root of x.

ruby comes with the tool ri:

$ ri Math::sqrt
------------------------------------------------------------- Math::sqrt
     Math.sqrt(numeric)    => float
------------------------------------------------------------------------
     Returns the non-negative square root of _numeric_.

Java comes with the documentation organized in html pages (JavaDoc format), while Microsoft distributes the API documentation for its languages (Visual C++, C#, Visual Basic, F#, etc...) embedded in Visual Studio's help system.

API in object-oriented languages

In object oriented languages, an API usually includes a description of a set of class definitions, with a set of behaviors associated with those classes. A behavior is the set of rules for how an object, derived from that class, will act in a given circumstance. This abstract concept is associated with the real functionalities exposed, or made available, by the classes that are implemented in terms of class methods.

The API in this case can be conceived as the totality of all the methods publicly exposed by the classes (usually called the class interface). This means that the API prescribes the methods by which one interacts with/handles the objects derived from the class definitions.

More generally, one can see the API as the collection of all the kinds of objects one can derive from the class definitions, and their associated possible behaviors. Again: the use is mediated by the public methods, but in this interpretation, the methods are seen as a technical detail of how the behavior is implemented.

For instance: a class representing a Stack can simply expose publicly two methods push() (to add a new item to the stack), and pop() (to extract the last item, ideally placed on top of the stack).

In this case the API can be interpreted as the two methods pop() and push(), or, more generally, as the idea that one can use an item of type Stack that implements the behavior of a stack: a pile exposing its top to add/remove elements.

This concept can be carried to the point where a class interface in an API has no methods at all, but only behaviors associated with it. For instance, the Java language and Lisp API include the interface Serializable, which requires that each class that implements it should behave in a serialized fashion. This does not require to have any public method, but rather requires that any class that implements it to have a representation that can be saved (serialized) at any time (this is typically true for any class containing simple data and no link to external resources, like an open connection to a file, a remote system, or an external device).

In this sense, in object oriented languages, the API defines a set of object behaviors, possibly mediated by a set of class methods.

In such languages, the API is still distributed as a library. For example, the Java language libraries include a set of APIs that are provided in the form of the JDK used by the developers to build new Java programs. The JDK includes the documentation of the API in JavaDoc notation.

The quality of the documentation associated with an API is often a factor determining its success in terms of ease of use.

API and protocols

An API can also be an implementation of a protocol.

In general the difference between an API and a protocol is that the protocol defines a standard way to exchange requests and responses based on a common transport, while an API provides a library to be used directly: hence there can be no transport (no information physically transferred from some remote machine), but rather only simple information exchange via function calls (local to the machine where the elaboration takes place).

When an API implements a protocol it can be based on proxy methods for remote invocations that underneath rely on the communication protocol. The role of the API can be exactly to hide the detail of the transport protocol.

Protocols are usually shared between different technologies (system based on given computer programming languages in a given operating system) and usually allow the different technologies to exchange information, acting as an abstraction/mediation level between the two worlds. While APIs are specific to a given technology: hence the APIs of a given language cannot be used in other languages, unless the function calls are wrapped with specific adaptation libraries.

Web APIs

When used in the context of web development, an API is typically a defined set of Hypertext Transfer Protocol (HTTP) request messages, along with a definition of the structure of response messages, which is usually in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format. While "Web API" is virtually a synonym for web service, the recent trend (so-called Web 2.0) has been moving away from Simple Object Access Protocol (SOAP) based services towards more direct Representational State Transfer (REST) style communications.[3] Web APIs allow the combination of multiple services into new applications known as Mashup_(web_application_hybrid)|mashups.[4]

Use of APIs to share content

The practice of publishing APIs has allowed web communities to create an open architecture for sharing content and data between communities and applications. In this way, content that is created in one place can be dynamically posted and updated in multiple locations on the web.

  1. Photos can be shared from sites like Flickr and Photobucket to social network sites like Facebook and MySpace.
  2. Content can be embedded, e.g. embedding a presentation from SlideShare on a LinkedIn profile.
  3. Content can be dynamically posted. Sharing live comments made on Twitter with a Facebook account, for example, is enabled by their APIs.
  4. Video content can be embedded on sites which are served by another host.
  5. User information can be shared from web communities to outside applications, delivering new functionality to the web community that shares its user data via an open API. One of the best examples of this is the Facebook Application platform. Another is the Open Social platform.[5]

Implementations

The POSIX standard defines an API that allows a wide range of common computing functions to be written in a way such that they may operate on many different systems (Mac OS X, and various Berkeley Software Distributions (BSDs) implement this interface); however, making use of this requires re-compiling for each platform. A compatible API, on the other hand, allows compiled object code to function without any changes to the system implementing that API. This is beneficial to both software providers (where they may distribute existing software on new systems without producing and distributing upgrades) and users (where they may install older software on their new systems without purchasing upgrades), although this generally requires that various software libraries implement the necessary APIs as well.

Microsoft has shown a strong commitment to a backward compatible API, particularly within their Windows API (Win32) library, such that older applications may run on newer versions of Windows using an executable-specific setting called "Compatibility Mode".[6]

Apple Inc. has shown less concern, breaking compatibility or implementing an API in a slower "emulation mode"; this allows greater freedom in development, at the cost of making older software obsolete.[citation needed]

Among Unix-like operating systems, there are many related but incompatible operating systems running on a common hardware platform (particularly Intel 80386-compatible systems). There have been several attempts to standardize the API such that software vendors may distribute one binary application for all these systems; however, to date, none of these have met with much success. The Linux Standard Base is attempting to do this for the Linux platform, while many of the BSD Unixes, such as FreeBSD, NetBSD, and OpenBSD, implement various levels of API compatibility for both backward compatibility (allowing programs written for older versions to run on newer distributions of the system) and cross-platform compatibility (allowing execution of foreign code without recompiling).

Release policies

The two options for releasing API are:

  1. Protecting information on APIs from the general public. For example, Sony used to make its official PlayStation 2 API available only to licensed PlayStation developers. This enabled Sony to control who wrote PlayStation 2 games. This gives companies quality control privileges and can provide them with potential licensing revenue streams.
  2. Making APIs freely available. For example, Microsoft makes the Microsoft Windows API public, and Apple releases its APIs Carbon and Cocoa, so that software can be written for their platforms.

A mix of the two behaviors can be used as well.

ABIs

The related term Application Binary Interface (ABI) is a lower level definition concerning details at the assembly language level. For example, the Linux Standard Base is an ABI, while POSIX is an API.[7]

API examples

  • ASPI for SCSI device interfacing
  • DirectX for Microsoft Windows
  • EHLLAPI
  • Java APIs
  • OpenGL cross-platform graphics API
  • OpenAL cross-platform sound API
  • OpenCL cross-platform API for general-purpose computing for CPUs & GPUs
  • OpenMP API that supports multi-platform shared memory multiprocessing programming in C, C++ and Fortran on many architectures, including Unix and Microsoft Windows platforms.
  • Simple DirectMedia Layer (SDL)
  • Talend integrates its data management with Business process management (BPM) from Bonita Open Solution
  • Windows API

Language bindings and interface generators

APIs that are intended to be used by more than one high-level programming language often provide, or are augmented with, facilities to automatically map the API to features (syntactic or semantic) that are more natural in those languages. This is known as language binding, and is itself an API. The aim is to encapsulate most of the required functionality of the API, leaving a "thin" layer appropriate to each language.

Below are listed some interface generator tools which bind languages to APIs at compile time.

  • SWIG opensource interfaces bindings generator from many languages to many languages (Typically Compiled->Scripted)
  • F2PY:[8] Fortran to Python interface generator.

References

External links