Hubbry Logo
APIAPIMain
Open search
API
Community hub
API
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
API
API
API
View on Wikipedia
from Wikipedia

An application programming interface (API) is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software.[1] A document or standard that describes how to build such a connection or interface is called an API specification. A computer system that meets this standard is said to implement or expose an API. The term API may refer either to the specification or to the implementation.

In contrast to a user interface, which connects a computer to a person, an application programming interface connects computers or pieces of software to each other. It is not intended to be used directly by a person (the end user) other than a computer programmer[1] who is incorporating it into software. An API is often made up of different parts which act as tools or services that are available to the programmer. A program or a programmer that uses one of these parts is said to call that portion of the API. The calls that make up the API are also known as subroutines, methods, requests, or endpoints. An API specification defines these calls, meaning that it explains how to use or implement them.

One purpose of APIs is to hide the internal details of how a system works, exposing only those parts a programmer will find useful and keeping them consistent even if the internal details later change. An API may be custom-built for a particular pair of systems, or it may be a shared standard allowing interoperability among many systems.

The term API is often used to refer to web APIs,[2] which allow communication between computers that are joined by the internet. There are also APIs for programming languages, software libraries, computer operating systems, and computer hardware. APIs originated in the 1940s, though the term did not emerge until the 1960s and 70s.

Purpose

[edit]

An API opens a software system to interactions from the outside. It allows two software systems to communicate across a boundary — an interface — using mutually agreed-upon signals.[3] In other words, an API connects software entities together. Unlike a user interface, an API is typically not visible to users. It is an "under the hood" portion of a software system, used for machine-to-machine communication.[4]

A well-designed API exposes only objects or actions needed by software or software developers. It hides details that have no use. This abstraction simplifies programming.[5]

Metaphorically, APIs connect software like interlocking blocks.

Building software using APIs has been compared to using building-block toys, such as Lego bricks. Software services or software libraries are analogous to the bricks; they may be joined together via their APIs, composing a new software product.[6] The process of joining is called integration.[3]

As an example, consider a weather sensor that offers an API. When a certain message is transmitted to the sensor, it will detect the current weather conditions and reply with a weather report. The message that activates the sensor is an API call, and the weather report is an API response.[7] A weather forecasting app might integrate with a number of weather sensor APIs, gathering weather data from throughout a geographical area.

An API is often compared to a contract. It represents an agreement between parties: a service provider who offers the API and the software developers who rely upon it. If the API remains stable, or if it changes only in predictable ways, developers' confidence in the API will increase. This may increase their use of the API.[8]

History of the term

[edit]
A diagram from 1978 proposing the expansion of the idea of the API to become a general programming interface, beyond application programs alone[9]

The term API initially described an interface only for end-user-facing programs, known as application programs. This origin is still reflected in the name "application programming interface." Today, the term is broader, including also utility software and even hardware interfaces.[10]

The idea of the API is much older than the term itself. British computer scientists Maurice Wilkes and David Wheeler worked on a modular software library in the 1940s for EDSAC, an early computer. The subroutines in this library were stored on punched paper tape organized in a filing cabinet. This cabinet also contained what Wilkes and Wheeler called a "library catalog" of notes about each subroutine and how to incorporate it into a program. Today, such a catalog would be called an API (or an API specification or API documentation) because it instructs a programmer on how to use (or "call") each subroutine that the programmer needs.[10]

Wilkes and Wheeler's book The Preparation of Programs for an Electronic Digital Computer contains the first published API specification. Joshua Bloch considers that Wilkes and Wheeler "latently invented" the API, because it is more of a concept that is discovered than invented.[10]

Although the people who coined the term API were implementing software on a Univac 1108, the goal of their API was to make hardware independent programs possible.[11]

The term "application program interface" (without an -ing suffix) is first recorded in a paper called Data structures and techniques for remote computer graphics presented at an AFIPS conference in 1968.[12][10] The authors of this paper use the term to describe the interaction of an application—a graphics program in this case—with the rest of the computer system. A consistent application interface (consisting of Fortran subroutine calls) was intended to free the programmer from dealing with idiosyncrasies of the graphics display device, and to provide hardware independence if the computer or the display were replaced.[11]

The term was introduced to the field of databases by C. J. Date[13] in a 1974 paper called The Relational and Network Approaches: Comparison of the Application Programming Interface.[14] An API became a part of the ANSI/SPARC framework for database management systems. This framework treated the application programming interface separately from other interfaces, such as the query interface. Database professionals in the 1970s observed these different interfaces could be combined; a sufficiently rich application interface could support the other interfaces as well.[9]

This observation led to APIs that supported all types of programming, not just application programming. By 1990, the API was defined simply as "a set of services available to a programmer for performing certain tasks" by technologist Carl Malamud.[15]

Screenshot of Web API documentation written by NASA

The idea of the API was expanded again with the dawn of remote procedure calls and web APIs. As computer networks became common in the 1970s and 80s, programmers wanted to call libraries located not only on their local computers, but on computers located elsewhere. These remote procedure calls were well supported by the Java language in particular. In the 1990s, with the spread of the internet, standards like CORBA, COM, and DCOM competed to become the most common way to expose API services.[16]

Roy Fielding's dissertation Architectural Styles and the Design of Network-based Software Architectures at UC Irvine in 2000 outlined Representational state transfer (REST) and described the idea of a "network-based Application Programming Interface" that Fielding contrasted with traditional "library-based" APIs.[17] XML and JSON web APIs saw widespread commercial adoption beginning in 2000 and continuing as of 2021. The web API is now the most common meaning of the term API.[2]

The Semantic Web proposed by Tim Berners-Lee in 2001 included "semantic APIs" that recast the API as an open, distributed data interface rather than a software behavior interface.[18] Proprietary interfaces and agents became more widespread than open ones, but the idea of the API as a data interface took hold. Because web APIs are widely used to exchange data of all kinds online, API has become a broad term describing much of the communication on the internet.[16] When used in this way, the term API has overlap in meaning with the term communication protocol.

Types

[edit]

Libraries and frameworks

[edit]

The interface to a software library is one type of API. The API describes and prescribes the "expected behavior" (a specification) while the library is an "actual implementation" of this set of rules.

A single API can have multiple implementations (or none, being abstract) in the form of different libraries that share the same programming interface.

The separation of the API from its implementation can allow programs written in one language to use a library written in another. For example, because Scala and Java compile to compatible bytecode, Scala developers can take advantage of any Java API.[19]

API use can vary depending on the type of programming language involved. An API for a procedural language such as Lua could consist primarily of basic routines to execute code, manipulate data or handle errors while an API for an object-oriented language, such as Java, would provide a specification of classes and its class methods.[20][21] Hyrum's law states that "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."[22] Meanwhile, several studies show that most applications that use an API tend to use a small part of the API.[23]

Language bindings are also APIs. By mapping the features and capabilities of one language to an interface implemented in another language, a language binding allows a library or service written in one language to be used when developing in another language.[24] Tools such as SWIG and F2PY, a Fortran-to-Python interface generator, facilitate the creation of such interfaces.[25]

An API can also be related to a software framework: a framework can be based on several libraries implementing several APIs, but unlike the normal use of an API, the access to the behavior built into the framework is mediated by extending its content with new classes plugged into the framework itself.

Moreover, the overall program flow of control can be out of the control of the caller and in the framework's hands by inversion of control or a similar mechanism.[26][27]

Operating systems

[edit]

An API can specify the interface between an application and the operating system.[28] POSIX, for example, specifies a set of common APIs that aim to enable an application written for a POSIX conformant operating system to be compiled for another POSIX conformant operating system.

Linux and Berkeley Software Distribution are examples of operating systems that implement the POSIX APIs.[29]

Microsoft has shown a strong commitment to a backward-compatible API, particularly within its Windows API (Win32) library, so older applications may run on newer versions of Windows using an executable-specific setting called "Compatibility Mode".[30] How much Microsoft developers' access to the company's operating systems' internal APIs is an advantage is unclear. Richard A. Shaffer of Technologic Computer Letter in 1987 compared the situation to a baseball game in which "Microsoft owns all the bats and the field",[31] but Ed Esber of Ashton-Tate said in an interview that year that Bill Gates told him that his developers sometimes had to rewrite software based on early APIs. Gates noted in the interview that Microsoft's Apple Macintosh applications were more successful than those for MS-DOS, because his company did not have to also devote resources to Mac OS.[32]

An API differs from an application binary interface (ABI) in that an API is source code based while an ABI is binary based. For instance, POSIX provides APIs while the Linux Standard Base provides an ABI.[33][34]

Remote APIs

[edit]

Remote APIs allow developers to manipulate remote resources through protocols, specific standards for communication that allow different technologies to work together, regardless of language or platform. For example, the Java Database Connectivity API allows developers to query many different types of databases with the same set of functions, while the Java remote method invocation API uses the Java Remote Method Protocol to allow invocation of functions that operate remotely, but appear local to the developer.[35][36]

Therefore, remote APIs are useful in maintaining the object abstraction in object-oriented programming; a method call, executed locally on a proxy object, invokes the corresponding method on the remote object, using the remoting protocol, and acquires the result to be used locally as a return value.

A modification of the proxy object will also result in a corresponding modification of the remote object.[37]

Web APIs

[edit]
Main article: Web API

Web APIs are the defined interfaces through which interactions happen between an enterprise and applications that use its assets, which also is a Service Level Agreement (SLA) to specify the functional provider and expose the service path or URL for its API users. An API approach is an architectural approach that revolves around providing a program interface to a set of services to different applications serving different types of consumers.[38]

When used in the context of web development, an API is typically defined as a set of specifications, such as Hypertext Transfer Protocol (HTTP) request messages, along with a definition of the structure of response messages, usually in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format. An example might be a shipping company API that can be added to an eCommerce-focused website to facilitate ordering shipping services and automatically include current shipping rates, without the site developer having to enter the shipper's rate table into a web database. While "web API" historically has been virtually synonymous with web service, the recent trend (so-called Web 2.0) has been moving away from Simple Object Access Protocol (SOAP) based web services and service-oriented architecture (SOA) towards more direct representational state transfer (REST) style web resources and resource-oriented architecture (ROA).[39] Part of this trend is related to the Semantic Web movement toward Resource Description Framework (RDF), a concept to promote web-based ontology engineering technologies. Web APIs allow the combination of multiple APIs into new applications known as mashups.[40] In the social media space, web APIs have allowed web communities to facilitate sharing content and data between communities and applications. In this way, content that is created in one place dynamically can be posted and updated to multiple locations on the web.[41] For example, Twitter's REST API allows developers to access core Twitter data and the Search API provides methods for developers to interact with Twitter Search and trends data.[42]

Design

[edit]

The design of an API has significant impact on its usage.[5] The principle of information hiding describes the role of programming interfaces as enabling modular programming by hiding the implementation details of the modules so that users of modules need not understand the complexities inside the modules.[43] Thus, the design of an API attempts to provide only the tools a user would expect.[5] The design of programming interfaces represents an important part of software architecture, the organization of a complex piece of software.[44]

Release policies

[edit]

APIs are one of the more common ways technology companies integrate. Those that provide and use APIs are considered as being members of a business ecosystem.[45]

The main policies for releasing an API are:[46]

  • Private: The API is for internal company use only.
  • Partner: Only specific business partners can use the API. For example, vehicle for hire companies such as Uber and Lyft allow approved third-party developers to directly order rides from within their apps. This allows the companies to exercise quality control by curating which apps have access to the API, and provides them with an additional revenue stream.[47]
  • Public: The API is available for use by the public. For example, Microsoft makes the Windows API public, and Apple releases its API Cocoa, so that software can be written for their platforms. Not all public APIs are generally accessible by everybody. For example, Internet service providers like Cloudflare or Voxility, use RESTful APIs to allow customers and resellers access to their infrastructure information, DDoS stats, network performance or dashboard controls.[48] Access to such APIs is granted either by “API tokens”, or customer status validations.[49]

Public API implications

[edit]

An important factor when an API becomes public is its "interface stability". Changes to the API—for example adding new parameters to a function call—could break compatibility with the clients that depend on that API.[50]

When parts of a publicly presented API are subject to change and thus not stable, such parts of a particular API should be documented explicitly as "unstable". For example, in the Google Guava library, the parts that are considered unstable, and that might change soon, are marked with the Java annotation @Beta.[51]

A public API can sometimes declare parts of itself as deprecated or rescinded. This usually means that part of the API should be considered a candidate for being removed, or modified in a backward incompatible way. Therefore, these changes allow developers to transition away from parts of the API that will be removed or not supported in the future.[52]

Client code may contain innovative or opportunistic usages that were not intended by the API designers. In other words, for a library with a significant user base, when an element becomes part of the public API, it may be used in diverse ways.[53] On February 19, 2020, Akamai published their annual “State of the Internet” report, showcasing the growing trend of cybercriminals targeting public API platforms at financial services worldwide. From December 2017 through November 2019, Akamai witnessed 85.42 billion credential violation attacks. About 20%, or 16.55 billion, were against hostnames defined as API endpoints. Of these, 473.5 million have targeted financial services sector organizations.[54]

Documentation

[edit]

API documentation describes what services an API offers and how to use those services, aiming to cover everything a client would need to know for practical purposes.

Documentation is crucial for the development and maintenance of applications using the API.[55] API documentation is traditionally found in documentation files but can also be found in social media such as blogs, forums, and Q&A websites.[56]

Traditional documentation files are often presented via a documentation system, such as Javadoc or Pydoc, that has a consistent appearance and structure. However, the types of content included in the documentation differs from API to API.[57]

In the interest of clarity, API documentation may include a description of classes and methods in the API as well as "typical usage scenarios, code snippets, design rationales, performance discussions, and contracts", but implementation details of the API services themselves are usually omitted. It can take a number of forms, including instructional documents, tutorials, and reference works. It'll also include a variety of information types, including guides and functionalities.

Restrictions and limitations on how the API can be used are also covered by the documentation. For instance, documentation for an API function could note that its parameters cannot be null, that the function itself is not thread safe.[58] Because API documentation tends to be comprehensive, it is a challenge for writers to keep the documentation updated and for users to read it carefully, potentially yielding bugs.[50]

API documentation can be enriched with metadata information like Java annotations. This metadata can be used by the compiler, tools, and by the run-time environment to implement custom behaviors or custom handling.[59]

It is possible to generate API documentation in a data-driven manner. By observing many programs that use a given API, it is possible to infer the typical usages, as well the required contracts and directives.[60] Then, templates can be used to generate natural language from the mined data.

[edit]
Main article: Google LLC v. Oracle America, Inc.

In 2010, Oracle Corporation sued Google for having distributed a new implementation of Java embedded in the Android operating system.[61] Google had not acquired any permission to reproduce the Java API, although permission had been given to the similar OpenJDK project. Judge William Alsup ruled in the Oracle v. Google case that APIs cannot be copyrighted in the U.S. and that a victory for Oracle would have widely expanded copyright protection to a "functional set of symbols" and allowed the copyrighting of simple software commands:

To accept Oracle's claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing its different versions to carry out all or part of the same commands.[62][63]

Alsup's ruling was overturned in 2014 on appeal to the Court of Appeals for the Federal Circuit, though the question of whether such use of APIs constitutes fair use was left unresolved.[64][65]

In 2016, following a two-week trial, a jury determined that Google's reimplementation of the Java API constituted fair use, but Oracle vowed to appeal the decision.[66] Oracle won on its appeal, with the Court of Appeals for the Federal Circuit ruling that Google's use of the APIs did not qualify for fair use.[67] In 2019, Google appealed to the Supreme Court of the United States over both the copyrightability and fair use rulings, and the Supreme Court granted review.[68] Due to the COVID-19 pandemic, the oral hearings in the case were delayed until October 2020.[69]

The case was decided by the Supreme Court in Google's favor.[70]

Examples

[edit]
Main category: Application programming interfaces

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

API

View on Grokipedia
from Grokipedia
An Application Programming Interface (API) is a set of rules, protocols, and tools that enables different software applications to communicate, exchange data, and interact seamlessly with one another. The concept of APIs traces its origins to the early days of in the , when modular software libraries were developed for machines like the , though the term "API" emerged in the 1960s and 1970s as systems became more complex. Modern APIs gained prominence in the early 2000s with the rise of web services, exemplified by Salesforce's 2000 launch of the first widely recognized commercial API, followed by platforms like and Amazon that enabled third-party integrations. APIs are categorized by accessibility and purpose, including open APIs (publicly available for broad use, often with usage limits), partner APIs (shared with specific business collaborators under agreements), internal APIs (used within an organization to connect private systems), and composite APIs (which combine multiple APIs into a single interface for efficiency). By architectural style, common types include REST APIs (stateless, using HTTP methods for web-based interactions), SOAP APIs (protocol-based with XML messaging for enterprise reliability), and RPC APIs (remote procedure calls for direct function invocation across systems). In modern , APIs are foundational to digital ecosystems, powering services, mobile apps, and the economy by facilitating , reducing development time, and enabling scalable integrations without exposing underlying code. They underpin services like processing, sharing, and , with RESTful designs dominating due to their simplicity and widespread adoption in . As organizations increasingly rely on APIs for innovation and efficiency, robust governance and security practices—such as authentication via and —have become essential to mitigate risks like unauthorized access.

Fundamentals

Definition

An application programming interface (API) is a set of rules, protocols, and tools that enable different software applications or components to communicate, exchange , and access functionalities from one another in a standardized manner. This definition aligns with the NIST description of an API as "a system access point or library function that has a well-defined and is accessible from application programs or user code to provide well-defined services," drawing from ISO/IEC 2382-1:1993 standards for vocabulary. The API primarily defines the interface, which consists of the specifications outlining how interactions occur—such as the expected inputs, outputs, and behaviors—without exposing the underlying , which refers to the actual or logic that executes those specifications. This separation allows developers to use the API without needing to understand or modify the internal workings of the providing system, promoting and reusability in . Key components of an API typically include specifications for operations (such as functions or methods), parameters (inputs like arguments or request data), responses (outputs like return values or results), and data representations (such as data types or formats). In web APIs, these may manifest as endpoints, HTTP methods (e.g., GET or ), and formats like or XML. These elements ensure consistent and predictable communication between applications.

Purpose

APIs serve as intermediaries that abstract the complexities of underlying systems, allowing developers to interact with software components without needing to understand their internal implementations. This abstraction enables standardized interfaces for communication between applications, promoting reusability of code across different projects and environments. By facilitating modular programming, APIs break down large systems into independent, interchangeable parts, which enhances overall software maintainability and allows teams to focus on specific functionalities rather than rebuilding from scratch. The benefits of APIs extend to significant improvements in development efficiency and system capabilities. They reduce development time by streamlining integrations and enabling the reuse of existing services, with surveys indicating that 54% of organizations use APIs for reducing development time. Enhanced scalability arises from APIs' ability to manage distributed resources dynamically, particularly in cloud environments where services can be scaled independently. Furthermore, APIs promote third-party integrations, fostering ecosystems such as mobile applications that leverage payment gateways like or mapping services like , and cloud platforms that connect diverse tools for seamless data exchange. In architectural contexts, APIs play a pivotal role in (SOA) and by enabling and service independence, which supports agile responses to business needs through reusable, encapsulated components. In SOA, APIs allow services to be orchestrated across enterprise systems, decoupling for greater flexibility. Within architecture, APIs define communication protocols between fine-grained services, each handling a single responsibility, which bolsters modularity and parallel . This integration capability is essential for composing complex applications from smaller, deployable units. Economically, APIs underpin innovative business models by creating API economies that monetize digital capabilities, such as software-as-a-service (SaaS) platforms like AWS and , which have scaled to serve billions of transactions through exposed interfaces. These economies enable non-technical organizations to participate in , unlocking new revenue streams via third-party developer ecosystems and reducing barriers to market entry. For instance, APIs have facilitated rapid expansions in sectors like healthcare and during high-demand periods, contributing to broader projections of trillions in value.

History

Origins of the Term

The term "API," an abbreviation for "application program interface" (later commonly expanded as "Application Programming Interface"), was first documented in the computing literature in 1968 by Ira W. Cotton and Frank S. Greatorex in their seminal paper "Data Structures and Techniques for Remote Computer Graphics," presented at the AFIPS Fall Joint Computing Conference. In this work, the authors used the term to denote a standardized set of conventions and data structures enabling an application program to communicate with a remote graphics subsystem across network connections, particularly for transmitting display commands and handling real-time interactions in time-sharing environments. This introduction marked the formal etymology of "API" as a descriptor for programmatic boundaries between software components, emphasizing abstraction and modularity in early networked computing applications. The coinage emerged amid the 1960s push toward modular system design, exemplified by IBM's System/360 mainframe family, announced in 1964, which featured extensive documentation on subroutine libraries and hardware-software interfaces to support compatible programming across models. Although initial System/360 manuals, such as the 1965 Operating System/360 Concepts and Facilities, described these interfaces through macro-instructions and linkage conventions without employing the "API" acronym, they laid foundational concepts for reusable code modules and system calls. Early adoption of the term extended to similar contexts in the 1970s, where academic papers on referenced APIs for defining boundaries in operating systems and library integrations, building on the graphics-focused precedent set by Cotton and Greatorex. These developments were influenced by prior programming paradigms, notably the subroutine calls introduced in , the first high-level language developed by in the mid-1950s and released in 1957, which allowed main programs to invoke independent code blocks for tasks like mathematical computations. Fortran's CALL statement, refined in Fortran II around 1958, provided a template for procedure-oriented interfaces that promoted and , concepts central to the API's later formalization.

Evolution

In the 1970s and 1980s, the evolution of APIs shifted toward object-oriented paradigms, emphasizing modular interfaces that encapsulated data and behavior within classes. Smalltalk, developed at Xerox PARC starting in 1972 by and his team, pioneered this approach by treating everything as objects with public interfaces that served as APIs, enabling reusable and extensible software components. This influenced subsequent languages, including C++, which began designing in 1979 at as "C with Classes" to blend Simula's object-oriented features with C's performance; by 1983, it evolved into C++, introducing abstract classes and virtual functions that formalized APIs as public interfaces for polymorphism and abstraction. The 1990s marked the rise of distributed APIs to facilitate communication across networked systems. The (OMG) released the (CORBA) specification in 1991, standardizing for distributed object interactions and enabling platform-independent APIs over networks. countered with (DCOM) in 1996, extending its (COM) to support remote procedure calls across machines, promoting enterprise-level distributed APIs despite platform dependencies. These technologies addressed the growing need for in client-server environments but highlighted challenges in complexity and . The ushered in the web services era, leveraging XML for standardized, internet-scale APIs. XML-RPC, introduced in 1998 by of UserLand Software in collaboration with , provided a simple protocol for remote procedure calls using XML over HTTP, laying groundwork for web-based . Building on this, (Simple Object Access Protocol) emerged in 1998 from , DevelopMentor, and UserLand, and was standardized by the W3C in 2003 as SOAP 1.2, enabling robust, extensible messaging for enterprise web services with features like security and transactions. From the 2010s to the 2020s, RESTful APIs gained dominance for their simplicity and alignment with web architecture, followed by innovations like and API-first design. Roy Fielding's 2000 dissertation formalized (Representational State Transfer) principles, promoting stateless, resource-oriented APIs using HTTP methods, which proliferated with the rise of web and mobile applications. , developed internally at in 2012 and open-sourced in 2015, addressed REST's over- and under-fetching issues by allowing clients to query precise data structures via a single endpoint. API-first design, emphasizing APIs as the primary product from the outset, became standard in microservices architectures during this period, exemplified by (AWS) launching its Simple Storage Service (S3) API in 2006, which evolved into a cloud ecosystem integrating with services like EC2 for scalable, on-demand computing. As of 2025, recent trends focus on AI-driven APIs for integration and APIs for decentralized applications. According to , by 2026 more than 80% of enterprises will have used (GenAI) APIs or deployed GenAI-enabled applications, enhancing automation and personalization while raising concerns over data privacy and ethical use. APIs, facilitating secure, tamper-proof transactions in ecosystems, are increasingly adopted for and , with integrations like Ethereum's enabling interactions.

Types

Local APIs

Local APIs are interfaces that enable communication between software components within the same computing environment, such as a single or , without relying on network transmission. They typically involve direct function calls, method invocations, or calls that allow applications to access shared libraries, operating services, or internal modules efficiently. This form of intra-application interaction supports by defining standardized ways for code segments to exchange data and functionality locally. Prominent examples include the (Portable Operating System Interface) APIs in systems, which provide a set of standard functions for tasks like file operations, process management, and threading, ensuring portability across compliant operating systems. Similarly, the .NET Framework class libraries offer a collection of reusable classes, interfaces, and types that developers use to build desktop and server applications, encapsulating system resources and algorithms for seamless integration within .NET environments. These examples illustrate how local APIs abstract underlying complexities, promoting and consistency. Key characteristics of local APIs include low latency from in-memory or direct processor access, eliminating the delays associated with data or transmission over networks. They incur no network overhead, making them suitable for performance-critical scenarios where real-time responses are essential. Binding often occurs at compile-time or link-time through static or dynamic libraries, allowing early resolution of dependencies and reducing runtime overhead compared to interpreted or remote invocations. Local APIs find extensive use in embedded systems, where resource constraints demand efficient, lightweight interfaces for and task scheduling, as seen in real-time operating systems that rely on them for low-overhead device control. In desktop applications, they facilitate component reuse by enabling developers to integrate pre-built modules, such as graphics rendering libraries or utilities, into larger programs without redundant implementation. Unlike remote APIs that span distributed systems, local APIs prioritize speed and simplicity within a single host.

Remote APIs

Remote APIs enable communication between processes or systems across networks, typically involving protocols that facilitate inter-process calls over distributed environments. A foundational example is the (RPC) protocol, which allows a program to execute a subroutine or procedure on a remote server as if it were a local call, abstracting the underlying network complexities. Key protocols for remote APIs include , developed by and open-sourced in 2015 as a high-performance RPC framework supporting multiple languages and efficient data serialization. Another prominent protocol is , originally created at and open-sourced in 2007, which provides a framework for scalable cross-language service development through code generation from interface definitions. Message queue-based APIs, such as those in , support asynchronous communication by allowing producers to publish messages to queues that consumers retrieve, enabling decoupled and reliable data exchange in distributed systems. Characteristics of remote APIs emphasize robustness in networked settings, including mechanisms to handle latency through efficient transport protocols and connection multiplexing, as seen in gRPC's use of for reduced overhead. Error recovery is addressed via retries, timeouts, and fault-tolerant designs, such as idempotent operations and circuit breakers to manage transient failures without data loss. Serialization plays a critical role, often employing compact formats like (Protobuf), a language-neutral mechanism developed by for structured data encoding that minimizes payload size and parsing time compared to text-based alternatives. Unlike local APIs, remote APIs incur additional overhead from network traversal, leading to higher latency and requiring optimizations like compression to maintain . Remote APIs find extensive use in enterprise integrations, where they connect disparate systems for and workflow automation, such as linking CRM platforms with backend databases. In IoT scenarios, they facilitate device-to-cloud communication, enabling real-time from sensors to central analytics platforms for monitoring and control.

Web APIs

Web APIs are application programming interfaces that enable communication between client and server systems over the using the Hypertext Transfer Protocol (HTTP) or its secure variant, . They typically expose resources through standardized endpoints, allowing developers to perform operations such as retrieving, creating, updating, or deleting data via HTTP methods like GET, POST, PUT, and DELETE. Many web APIs adhere to RESTful principles, emphasizing simplicity, scalability, and interoperability across diverse platforms. Key architectures for web APIs include , introduced by in his 2000 doctoral dissertation as a set of constraints for designing networked applications. promotes a uniform interface where resources are identified by URIs and manipulated through standard HTTP verbs, facilitating between clients and servers. Another prominent architecture is , developed internally by starting in 2012 and open-sourced in 2015, which allows clients to request precisely the data they need in a single query, reducing over-fetching and under-fetching common in . Simple Object Access Protocol (SOAP), originating in 1998 from a Microsoft-led initiative, provides a more rigid, XML-based framework for exchanging structured information, often used in enterprise environments requiring strict standards and security. Web APIs exhibit several defining characteristics that support their use in distributed systems. ensures that each request from a client contains all necessary information, independent of prior interactions, which enhances by allowing servers to handle requests without maintaining session state. Resource-oriented design treats data as addressable resources—such as users or posts—modeled hierarchically to mirror real-world entities, promoting intuitive navigation and extensibility. Authentication mechanisms, like OAuth 2.0 standardized in 2012 via RFC 6749, enable secure delegated access by issuing tokens that authorize third-party applications without sharing user credentials. Common use cases for web APIs include public services that integrate social media functionalities, such as the Twitter API launched in 2006, which allows developers to access tweets, user data, and timelines in real-time. Payment gateways also rely heavily on web APIs; for instance, Stripe's API enables merchants to process transactions, manage subscriptions, and handle fraud detection through simple HTTP requests. As of 2025, trends in web APIs emphasize serverless architectures, exemplified by , where functions are triggered by HTTP events via API Gateway, enabling automatic scaling and cost efficiency for event-driven applications without provisioning servers.

Design

Principles

Effective API design relies on core principles that enhance usability and maintainability, including consistency, , and . Consistency involves uniform naming conventions for resources, methods, and responses, ensuring developers can predict API across endpoints; for instance, using nouns for collections (e.g., /users) and singular for specific items (e.g., /users/{id}) promotes predictability. emphasizes minimal endpoints and straightforward interactions, avoiding over-engineered features to reduce on users; this principle advocates for designing APIs around essential use cases rather than exhaustive CRUD operations. Discoverability makes resources self-descriptive through mechanisms like hypermedia links in responses (e.g., in RESTful designs), allowing clients to navigate the API without external documentation. For RESTful APIs, these principles align with the architectural constraints outlined by , which form the foundation of scalable web services. The client-server separation divides concerns between user interfaces (clients) and (servers), enabling independent evolution of each. Cacheability allows responses to be explicitly marked as storable, improving by reducing network requests. The layered system constraint supports intermediaries like proxies without clients needing to distinguish them from the origin server, enhancing and . Error handling in APIs follows standardized practices to provide clear feedback. HTTP status codes, such as 4xx for client errors (e.g., 400 Bad Request) and 5xx for server errors (e.g., 500 Internal Server Error), convey the nature of issues unambiguously. Accompanying meaningful messages in the response body, often in a structured format like , explain the error context without exposing sensitive details. Basic security measures are integral to API principles, focusing on preventing abuse and ensuring . Rate limiting restricts the number of requests per client within a time window to mitigate denial-of-service attacks and enforce fair usage. Input validation verifies all incoming data against expected formats and constraints, blocking malicious payloads like injection attempts.

Versioning

API versioning is essential for managing the evolution of application programming interfaces (APIs) while preserving , thereby preventing disruptions to existing consumer applications and maintaining developer trust. Breaking changes, such as renaming fields, altering data types, or making optional parameters required, can cause failures in integrated systems, leading to errors like missing properties or parsing exceptions. By implementing versioning, API providers can introduce updates without immediately affecting users, allowing gradual migration and ensuring long-term stability. Common methods for API versioning include URI-based, header-based, and semantic versioning approaches. In URI versioning, the version identifier is embedded directly in the resource path, such as /v1/users for accessing user data in the first version, which clearly signals the API endpoint but may complicate caching and URI consistency across versions. Header-based versioning, conversely, keeps URIs clean by specifying the version through custom headers like X-API-Version: 1 or the standard Accept header, for example Accept: application/vnd.example.v1+[json](/page/JSON), enabling without altering paths. Semantic versioning (SemVer), formalized in version 2.0.0 released in 2013, structures versions as MAJOR.MINOR.PATCH (e.g., 2.0.0), where major increments indicate incompatible changes, minor increments add backward-compatible features, and patch increments fix bugs; this scheme requires a declared public API and is widely adopted for APIs to communicate change implications clearly. Best practices for API versioning emphasize proactive communication and controlled transitions to handle breaking changes effectively. Providers should issue warnings via HTTP headers, such as Deprecation: Sun, 1 Jan 2023 00:00:00 GMT, to notify consumers of impending removals, accompanied by links to migration guides. Sunset periods, typically spanning weeks to months (e.g., a one-week buffer post-), allow time for users to upgrade, with clear timelines announced through documentation, blogs, or emails to minimize disruptions. For breaking changes, strategies include supporting multiple versions simultaneously, adding new fields without removing old ones, and providing migration paths to ensure seamless evolution. In public APIs, versioning presents challenges in balancing rapid innovation with stability, as extensive increases maintenance complexity and code overhead. For instance, Stripe's model uses date-based rolling versions (e.g., 2017-05-24) pinned per account, enabling monthly non-breaking updates and biannual major releases while maintaining compatibility since 2011; this approach minimizes migration stress but requires sophisticated internal tooling to manage side effects and declarative changes across versions.

Management

Release Policies

API release policies outline the strategies organizations adopt to introduce, maintain, and retire APIs, ensuring reliability and predictability for developers and systems. These policies typically categorize APIs by maturity levels to manage expectations around stability and support. Common policy types include stable releases, which receive and are intended for production use without anticipated breaking changes; experimental or beta releases, which allow testing of new features but carry no guarantees of or ongoing maintenance; and deprecated phases, where APIs are marked for eventual removal to encourage migration to newer versions. For instance, stable APIs undergo thorough testing before general availability, while experimental ones enable rapid iteration on innovative capabilities. Deprecated APIs remain functional for a defined period to minimize disruption. Factors influencing release policies often differ based on the audience: internal APIs, used within an organization, prioritize speed and flexibility to support rapid internal development and collaboration, whereas external APIs, exposed to third-party developers, emphasize stability, security, and scalability to foster trust and adoption. Service level agreements (SLAs) further define commitments, such as uptime guarantees; for example, many cloud-based APIs target 99.9% availability, allowing no more than about 43 minutes of monthly downtime to ensure consistent performance. To enforce these policies, organizations deploy tools like API gateways for , requests, enforcing rate limits, and monitoring usage to align with release commitments. Examples include Kong, an open-source gateway focused on high-performance , and , a platform offering advanced analytics and security for enterprise-scale traffic control. A notable case is Google's API policy, established since 2012, which mandates at least a 12-month notice before discontinuing support for features or , allowing developers ample time to transition while the affected components remain operational during the phase-out. This approach integrates with versioning practices by signaling changes in advance through API updates.

Documentation

Effective API documentation serves as a comprehensive guide that empowers developers to understand, integrate, and troubleshoot APIs with minimal friction. Essential elements typically encompass detailed endpoint descriptions, which outline the paths, HTTP methods (such as GET, , PUT, and DELETE), and resource interactions; parameters, including query strings, path variables, headers, and request bodies with their data types, validation rules, and optional defaults; responses, specifying HTTP status codes, response headers, and structured body schemas (often in or XML formats); and flows, detailing mechanisms like API keys, OAuth 2.0 token exchanges, or JWT validation processes with sequential steps for implementation and error handling. These components ensure developers can anticipate API behavior and handle edge cases efficiently. Standardized formats facilitate the creation and consumption of such documentation. The OpenAPI Specification, formerly known as Swagger and donated by SmartBear Software to the OpenAPI Initiative in 2015 as version 2.0, provides a machine-readable or format for describing RESTful APIs, including paths for endpoints, parameter objects with location and schema details, responses mapped to status codes with content types, and security schemes for like API keys or . Complementing this, RAML (RESTful API Modeling Language), a -based specification developed for API modeling, supports through resource definitions, method annotations, response facets, and traits for reusable authentication patterns, enabling tools to generate synchronized or interactive consoles. For interactive experiences, Postman collections organize API requests into shareable sets that automatically produce covering endpoints, parameters, authentication headers, and sample responses, allowing developers to test calls directly within the interface. Best practices for API documentation prioritize developer-centric features to enhance usability and adoption. Including practical examples—such as commands or snippets in languages like Python and —for requests and responses helps illustrate real-world application, while tutorials and quickstart guides offer step-by-step walkthroughs for common workflows like user authentication or . Maintaining a that logs version-specific changes, deprecations, and new features ensures transparency, often aligned with release policies to synchronize updates and prevent outdated information. Additionally, auto-generation tools extract documentation from annotations or specifications; for instance, Swagger UI renders interactive docs from OpenAPI files, and libraries like OpenAPI Generator produce client SDKs and reference materials directly from , minimizing discrepancies between and description. Evaluating documentation quality relies on targeted metrics to quantify its impact on developer productivity. Readability scores, calculated using formulas like the Flesch-Kincaid index that assess sentence length, count, and word complexity, help gauge accessibility for diverse audiences, with scores above 60 indicating easy comprehension for non-expert users. Developer feedback loops, gathered through embedded surveys, Net Promoter Scores from usage analytics, or analysis of support queries, reveal pain points and satisfaction levels; tools like on doc pages track bounce rates and time spent as proxies for engagement. Stripe's API reference exemplifies these principles, featuring a clean three-column layout with searchable endpoints, live code playgrounds, and a prominent , which has contributed to its high developer satisfaction ratings in industry benchmarks.

Performance

Optimization Techniques

Optimization techniques for APIs focus on improving response times, reducing bandwidth consumption, and enhancing overall reliability without altering the core functionality. These methods address bottlenecks in data transfer, processing, and , enabling APIs to handle higher loads efficiently. By implementing targeted strategies, developers can achieve measurable gains in , such as decreased latency and lower resource utilization. Caching mechanisms are essential for minimizing redundant data retrieval in APIs. Entity Tags (ETags), defined in HTTP standards, allow servers to assign unique identifiers to resource versions, enabling clients to validate cached content via conditional requests like If-None-Match. This prevents unnecessary transfers of unchanged , reducing bandwidth usage and server load. For instance, when a client resubmits an ETag, the server responds with 304 Not Modified if the resource is identical, saving transfer costs. In-memory caching solutions like further optimize this by storing frequently accessed API responses in a high-speed key-value store, allowing sub-millisecond retrieval times compared to database queries. supports eviction policies such as least recently used (LRU) to manage efficiently, making it suitable for dynamic API environments where expires or updates periodically. Data compression techniques, particularly , significantly reduce the size of API payloads over HTTP. employs the algorithm to compress text-based responses like , achieving up to 70% size reduction for uncompressed content. Servers negotiate compression via the Accept-Encoding header, appending Content-Encoding: to responses, while clients decompress transparently. This approach lowers bandwidth requirements and accelerates transmission, especially beneficial for mobile or high-latency networks, though it incurs minor CPU overhead for compression and decompression. Best practices recommend applying to textual payloads exceeding 1KB while avoiding it for already compressed formats like images. Pagination is a critical technique for managing large response datasets, preventing overload on both servers and clients. By dividing results into smaller pages—typically using parameters like limit (e.g., number of items per page) and offset (starting position)—APIs avoid returning exhaustive lists that could exceed memory limits or timeout. For example, a request to /users?limit=50&offset=100 retrieves the third page of 50 users, with metadata in the response indicating total count and next/previous links for navigation. Cursor-based pagination, using opaque tokens referencing the last item, offers better efficiency for ordered datasets by avoiding offset calculations that degrade with scale. Microsoft guidelines emphasize including sorting and filtering options alongside pagination to further refine queries and maintain response consistency. Effective monitoring of API performance relies on tracking key metrics such as latency (time from request to response) and throughput (requests processed per unit time). Tools like collect these via HTTP endpoints, using a pull-based model to scrape time-series data from instrumented services. For latency, histograms capture request durations, revealing percentiles like p95 to identify slowdowns, while counters track throughput to monitor capacity. Integrating with visualization tools allows real-time alerting on thresholds, ensuring proactive optimization. Security optimizations balance protection with performance, where JSON Web Tokens (JWTs) provide stateless superior to traditional sessions for APIs. Unlike sessions requiring server-side storage and database lookups per request, JWTs encode user claims in a compact, signed token carried in headers, eliminating repeated queries and enabling horizontal scaling. As per RFC 7519, this reduces authentication overhead, with verification involving only signature checks, though it demands secure key management to prevent tampering. JWTs are particularly efficient in , supporting cross-domain use without shared session stores. Edge computing reduces API latency by processing requests at distributed network points closer to users. Platforms like Workers execute code at over 300 global edge locations, bypassing central server round-trips and achieving sub-100ms response times for compute-intensive tasks. This distributed model cuts propagation delays by up to 50% in remote regions, integrating seamlessly with caching and compression for compounded gains. As of 2025, AI and are increasingly used for predictive optimizations in APIs, such as dynamic caching based on usage patterns and in traffic to preempt performance issues. These techniques enable proactive and further reduce latency in high-scale environments.

Scaling Strategies

Scaling APIs to accommodate growing loads involves architectural strategies that distribute traffic and resources efficiently across systems. Load balancing is a foundational technique, where incoming requests are routed to multiple backend servers to prevent overload on any single instance. For example, serves as a high-performance load balancer for HTTP APIs, supporting methods like round-robin, least connections, and IP hash to evenly distribute traffic and improve availability. Microservices decomposition further enhances scalability by breaking down monolithic APIs into smaller, independent services that can be developed, deployed, and scaled separately. This approach, often guided by the Scale Cube model, applies Y-axis scaling through functional decomposition, allowing teams to partition applications along business capabilities rather than technical layers. Database sharding complements this by horizontally partitioning data across multiple databases, enabling APIs to handle larger datasets without performance degradation; for instance, sharding distributes queries based on keys like user IDs to balance read and write loads. Horizontal scaling, or scaling out, adds more instances of API servers to handle increased demand, contrasting with vertical scaling, which upgrades individual server hardware like CPU or memory. Horizontal methods offer greater elasticity for distributed systems, as they avoid single points of failure and support linear capacity growth. In cloud environments, auto-scaling automates this process; , introduced in 2014, uses Horizontal Pod Autoscalers to dynamically adjust the number of API service pods based on metrics like CPU utilization, ensuring resources match traffic spikes without manual intervention. A key challenge in these distributed setups is maintaining consistency amid failures, as outlined by the , which states that a system can only guarantee two of three properties—consistency, , and partition tolerance—in the presence of network partitions. API designers often prioritize and partition tolerance (AP systems) for high-traffic scenarios, accepting to avoid downtime, though this requires careful trade-off analysis. Netflix exemplifies these strategies in scaling its streaming API during the , evolving from a to over 500 by 2015 to manage billions of daily requests. The company adopted load balancing, sharding in for data persistence, and horizontal scaling on AWS, later incorporating federation around 2019 to unify service interactions while enabling independent scaling of domain-specific APIs. This decomposition allowed Netflix to handle global user growth without proportional infrastructure increases, achieving 99.99% availability for streaming services. The central debate in copyright law regarding application programming interfaces (APIs) revolves around whether they constitute functional elements, which are generally uncopyrightable under doctrines like the merger and principles, or creative expressions eligible for protection. In the United States, courts have long distinguished between the unprotected idea or function of software and the protectable expression of that idea, as established in cases like Baker v. Selden (1879), applying this merger doctrine to limit where expression is inextricably tied to function. This tension is particularly acute for APIs, which define methods for software interaction but often blend necessary functionality with potentially expressive choices in naming and structure. A landmark resolution in the U.S. came from the Supreme Court's 2021 ruling in , where the Court held, 6-2, that 's use of 37 API packages in Android constituted under Section 107 of the Copyright Act. The case, initiated in 2010, involved alleging infringement after acquiring ' copyrights; copied declaring code for but reimplemented the methods. While assuming that the APIs were copyrightable, the Court emphasized in creating a new platform, weighing factors like the purpose ( in ) and market harm (minimal, as it spurred Android's ecosystem). This decision avoided directly settling the copyrightability question but reinforced functionality limits on protection. Internationally, the (ECJ) in Inc. v. World Programming Ltd. (2012) rejected protection for software functionality, including elements akin to APIs, under the EU Software Directive (2009/24/EC). The ruling clarified that only the expression of a program's code and preparatory design material is protectable, not its interface specifications or functions, allowing reproduction for compatibility purposes via observation or . UK courts, applying this precedent post-Brexit, upheld similar limits in subsequent SAS v. World Programming proceedings, affirming no infringement in replicating functionality without copying literal code. These rulings have significant implications for compatibility and rights, enabling developers to implement interoperable APIs without fear of copyright claims, as seen in projects like reimplementing Java interfaces. By prioritizing functionality over expression, they promote innovation while curbing monopolistic control over standard interfaces, though they leave room for protection via contracts or patents in some jurisdictions.

Public API Implications

Public APIs, by design, enable third-party developers and organizations to integrate with core services, fostering expansive innovation ecosystems. For instance, Apple's ecosystem facilitated over $1.3 trillion in developer billings and sales globally in 2024, while platforms like Store leverage APIs to allow developers to build and distribute applications that extend platform functionality. Similarly, API-driven ecosystems such as those powered by AppExchange or have accelerated the creation of interconnected services, enabling rapid scaling for companies like through access to mapping and payment APIs. These structures promote collaborative development, where diverse applications can interoperate seamlessly, driving economic growth and technological advancement across industries. Data sharing standards further amplify these benefits, as exemplified by the European Union's Second (PSD2), enacted in 2018, which mandates banks to provide secure API access to customer account data for authorized third parties. This regulation has spurred initiatives, allowing firms to offer innovative services like aggregated financial insights and seamless payments, thereby enhancing competition and consumer choice while reducing banks' data monopolies. However, exposing APIs publicly introduces significant risks, particularly in and dependency. The 2023 MOVEit Transfer breach, stemming from a critical vulnerability (CVE-2023-34362) in the software's , enabled attackers to deploy web shells and exfiltrate data from thousands of organizations worldwide, highlighting how API endpoints can serve as entry points for widespread exploitation. Vendor lock-in poses another challenge, as proprietary APIs in cloud platforms like AWS or Azure create high switching costs through incompatible integrations and data egress fees, potentially trapping users in suboptimal vendor relationships and stifling multi-cloud strategies. Ethically, public APIs raise concerns around data privacy and power imbalances. Under the General Data Protection Regulation (GDPR), APIs handling from residents must incorporate , including explicit consent mechanisms, data minimization, and rights to access or erasure, with non-compliance risking fines up to 4% of global annual turnover. Monopolistic control is evident in dominant platforms, where companies like Apple and restrict API access in app stores to enforce ecosystem rules, limiting developer autonomy and enabling revenue extraction through commissions, as criticized in antitrust discussions. Regulatory trends such as the EU AI Act, which entered into force for general-purpose AI models on 2 August 2025, are reshaping public API practices, particularly for AI-integrated systems, by imposing disclosure obligations—such as transparency on training data, capabilities, and risks—to build user trust and mitigate systemic harms. These provisions extend to API providers embedding AI, mandating of potential biases or vulnerabilities, while briefly noting that intellectual property hurdles like must also be navigated in API design.

Examples

Software Libraries

Software libraries often expose APIs that enable developers to interact with complex functionalities in a standardized, programmatic manner, typically within local application contexts. These APIs encapsulate underlying implementations, allowing and simplifying development by providing consistent interfaces for tasks such as data access and computation. A seminal example is Java's () API, first specified in January 1997, which standardizes access to relational databases from applications. JDBC defines interfaces for establishing connections, executing SQL statements, and processing results, abstracting vendor-specific database details through driver implementations. This enables portable database interactions without direct dependency on proprietary protocols. In Python, the provides a simple API for making HTTP requests, streamlining network communication in scripts and applications. Released initially in February 2011, its core functions like requests.get() and requests.post() handle headers, , and response parsing, reducing the verbosity of Python's built-in urllib module. While primarily for HTTP, it exemplifies APIs that promote readable, human-friendly code for programmatic exchange. Frameworks further illustrate API design in libraries through modular components. React, open-sourced in May 2013, offers component APIs that allow developers to build user interfaces by composing reusable elements, with hooks like useState and useEffect providing declarative and side-effect handling. This API abstracts DOM manipulation and rendering cycles, enabling efficient, virtual DOM-based updates. Django's ORM (Object-Relational Mapping) API, part of the Django web framework since its 2005 inception, translates Python objects into database operations. Methods like Model.objects.filter() and Model.objects.create() enable query construction and data persistence without raw SQL, supporting multiple backends such as PostgreSQL and SQLite through abstract models. These APIs abstract underlying complexity by offering high-level abstractions over low-level operations. For instance, NumPy's array API in Python provides the ndarray class and functions like np.array() and np.dot() for efficient multidimensional array manipulation, handling memory layout, broadcasting, and vectorized computations that would otherwise require manual loops or C extensions. This design shifts focus from implementation details to algorithmic logic, boosting performance in scientific computing. In modern contexts, the TensorFlow API, released in November 2015, represents evolutionary advancements in library APIs for machine learning. It supplies high-level constructs like tf.keras layers and tf.data pipelines for model building, training, and data processing, abstracting tensor operations, graph execution, and hardware acceleration across CPUs, GPUs, and TPUs. This API's graph-based computation model and eager execution mode illustrate how libraries evolve to support scalable, distributed workflows while maintaining accessibility for diverse applications.[](https://www.tensorflow.org/guide

Operating Systems

Operating systems provide application programming interfaces (APIs) that enable software developers to interact with core system resources, such as processes, files, memory, and hardware devices, ensuring portability and consistency across applications. These APIs abstract low-level kernel operations, allowing programs to perform tasks like file I/O, process management, and network communication without direct hardware access. In Unix-like systems, including Linux and macOS, the POSIX standard serves as a foundational API specification for achieving source-level portability. POSIX, or Portable Operating System Interface, is an IEEE and ISO/IEC standard (IEEE Std 1003.1) that defines a core set of APIs, command-line shells, and utilities for Unix-based operating systems. It includes over 100 system interfaces, such as open() for file handling, fork() for creation, and pthread_create() for multithreading, which are implemented via libraries like on . These APIs promote interoperability; for instance, a POSIX-compliant application can compile and run on certified systems like distributions, , or Solaris with minimal modifications. The standard also encompasses shell utilities like sh for command interpretation and redirection operators (e.g., <, >), facilitating scriptable interactions with the OS environment. In Windows, the (formerly Win32 API) offers a comprehensive set of functions for desktop and server applications, organized into categories like system services, , and networking. Key functionalities include and thread management via APIs such as CreateProcess() and CreateThread(), access with CreateFile() and ReadFile(), and features like through LogonUser(). This API supports both 32-bit and 64-bit architectures and is accessible via dynamic-link libraries (DLLs) like kernel32.dll, enabling developers to build native applications that leverage Windows-specific features, such as the registry or event logs. Apple's macOS employs a framework-based approach to APIs, bundling related functions into dynamic libraries that provide object-oriented and procedural interfaces to system services. The Core Foundation framework delivers low-level C APIs for data management, including CFStringCreateWithCString() for string handling and CFDictionaryCreate() for key-value storage, serving as a bridge to higher-level operations. Building on this, the Foundation framework offers Objective-C classes like NSString and NSDictionary for cross-platform compatibility, while AppKit provides UI-specific APIs such as NSApplication for event loops and window management. These frameworks integrate with the underlying Darwin kernel (BSD-based and POSIX-compliant), allowing developers to access hardware acceleration, file systems, and multitasking capabilities seamlessly. Linux distributions, while POSIX-compliant through libraries like glibc, expose user-space APIs directly interfacing with the kernel via system calls wrapped in functions such as openat() for directory-relative file operations and epoll_create1() for efficient I/O multiplexing in networking applications. The kernel's user-space API guide documents interfaces for subsystems like filesystems (e.g., mount() for mounting volumes) and media (e.g., V4L2 APIs for video capture via ioctl() commands). These APIs enable high-performance applications, such as web servers using socket() for TCP connections, and are extensible through device-specific ioctls for hardware interaction.

References

  1. https://aws.amazon.com/what-is/api/
  2. https://www.oracle.com/cloud/cloud-native/api-management/what-is-api/
  3. https://csrc.nist.gov/glossary/term/application_programming_interface
  4. https://visuallywritten.com/a-brief-history-of-apis/
  5. https://www.forbes.com/councils/forbestechcouncil/2020/06/23/the-history-and-rise-of-apis/
  6. https://blog.postman.com/intro-to-apis-history-of-apis/
  7. https://konghq.com/blog/learning-center/different-api-types-and-use-cases
  8. https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design
  9. https://onlinecs.baylor.edu/news/what-are-apis-and-how-do-they-work
  10. https://resources.data.gov/resources/documenting-apis/
  11. https://www.academia.edu/143364728/The_Role_of_APIs_in_Modern_Web_Development_A_Literature_Review
  12. https://dspace.mit.edu/bitstream/handle/1721.1/155197/3639477.3639713.pdf?sequence=1&isAllowed=y
  13. https://www.sei.cmu.edu/documents/5955/On_the_Design_Development_and_Testing_of_Modern_APIs-1.pdf
  14. https://www.ibm.com/think/topics/api-endpoint
  15. https://www.computer.org/publications/tech-news/trends/what-are-apis/
  16. https://microservice-api-patterns.org/introduction
  17. https://smartbear.com/resources/ebooks/the-state-of-api-2019-report/
  18. https://hbr.org/2021/04/apis-arent-just-for-tech-companies
  19. https://www.opengroup.org/soa/source-book/msawp/p3.htm
  20. https://dl.acm.org/doi/10.1145/1476589.1476661
  21. https://historyofinformation.com/detail.php?entryid=2703
  22. http://bitsavers.org/pdf/ibm/360/os/R01-08/C28-6535-0_OS360_Concepts_and_Facilities_1965.pdf
  23. https://mcjones.org/dustydecks/archives/2005/08/07/46/
  24. https://worrydream.com/EarlyHistoryOfSmalltalk/
  25. https://www.stroustrup.com/hopl2.pdf
  26. https://cacm.acm.org/practice/the-rise-and-fall-of-corba/
  27. https://www.gartner.com/en/newsroom/press-releases/2023-10-11-gartner-says-more-than-80-percent-of-enterprises-will-have-used-generative-ai-apis-or-deployed-generative-ai-enabled-applications-by-2026
  28. https://www.ibm.com/think/topics/api
  29. https://pubs.opengroup.org/onlinepubs/9699919799/
  30. https://learn.microsoft.com/en-us/dotnet/standard/class-library-overview
  31. https://www.confluent.io/learn/api/
  32. https://www.beningo.com/embedded-basics-apis-vs-hals/
  33. https://learn.microsoft.com/en-us/dotnet/standard/class-libraries
  34. https://datatracker.ietf.org/doc/html/rfc5531
  35. https://developers.googleblog.com/introducing-grpc-a-new-open-source-http2-rpc-framework/
  36. https://thrift.apache.org/about
  37. https://www.rabbitmq.com/docs
  38. https://grpc.io/docs/what-is-grpc/introduction/
  39. https://protobuf.dev/overview/
  40. https://blog.dreamfactory.com/ultimate-guide-to-api-latency-and-throughput
  41. https://boomi.com/blog/10-business-use-cases-api/
  42. https://www.iotforall.com/iot-data-enterprise-silos-roi
  43. https://aws.amazon.com/what-is/restful-api/
  44. https://www.ibm.com/think/topics/rest-apis
  45. https://restfulapi.net/
  46. https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
  47. https://engineering.fb.com/2015/09/14/core-infra/graphql-a-data-query-language/
  48. https://www.xml.com/pub/a/ws/2001/04/04/soap.html
  49. https://www.oreilly.com/library/view/restful-web-services/9780596529260/ch04.html
  50. https://datatracker.ietf.org/doc/html/rfc6749
  51. https://blog.x.com/en_us/a/2006/introducing-the-twitter-api
  52. https://docs.stripe.com/payments/payment-methods
  53. https://aws.amazon.com/blogs/compute/serverless-icymi-q3-2025/
  54. https://datatracker.ietf.org/doc/html/rfc9110#section-15
  55. https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/
  56. https://www.postman.com/api-platform/api-versioning/
  57. https://restfulapi.net/versioning/
  58. https://semver.org/
  59. https://nordicapis.com/how-to-smartly-sunset-and-deprecate-apis/
  60. https://stripe.com/blog/api-versioning
  61. https://docs.pytorch.org/executorch/stable/api-life-cycle.html
  62. https://developer.ebay.com/api-docs/static/versioning.html
  63. https://www.mediawiki.org/wiki/API_versioning
  64. https://blog.techcompose.com/api-aspects-to-consider-for-internal-platform-vs-external-platforms/
  65. https://www.assemblyai.com/docs/faq/what-is-your-api-uptime-sla
  66. https://cloud.google.com/blog/products/networking/new-availability-sla-for-standard-tier-networking
  67. https://konghq.com/performance-comparison/kong-vs-apigee
  68. https://www.solo.io/blog/avoid-apigee-api-gateway
  69. https://developers.google.com/maps/deprecations
  70. https://cloud.google.com/maps-platform/terms
  71. https://www.altexsoft.com/blog/api-documentation/
  72. https://www.heretto.com/blog/api-documentation
  73. https://swagger.io/specification/
  74. https://raml.org/
  75. https://www.postman.com/product/api-documentation/
  76. https://stoplight.io/api-documentation-guide
  77. https://swagger.io/solutions/api-documentation/
  78. https://daily.dev/blog/5-metrics-to-measure-documentation-quality
  79. https://idratherbewriting.com/blog/measuring-documentation-quality-rubric-developer-docs/
  80. https://docs.stripe.com/api
  81. https://nordicapis.com/the-top-trends-shaping-apis-in-2025/
  82. https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/
  83. https://microservices.io/articles/scalecube.html
  84. https://learn.microsoft.com/en-us/azure/architecture/patterns/sharding
  85. https://www.digitalocean.com/resources/articles/horizontal-scaling-vs-vertical-scaling
  86. https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
  87. https://dl.acm.org/doi/10.1145/564585.564601
  88. https://www.sayonetech.com/blog/5-microservices-examples-amazon-netflix-uber-spotify-and-etsy/
  89. https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2
  90. https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf
  91. https://harvardlawreview.org/print/vol-135/google-llc-v-oracle-america-inc/
  92. https://www.copyright.gov/fair-use/summaries/google-llc-oracle-am-inc-2021.pdf
  93. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62010CJ0406
  94. https://texaslawreview.org/interfaces-and-interoperability-after-google-v-oracle/
  95. https://www.apple.com/ca/newsroom/2025/06/global-app-store-helps-developers-reach-new-heights/
  96. https://sidgs.com/evolution-of-apis/
  97. https://ronimmink.medium.com/apis-as-an-automatic-innovation-ecosystem-dc357ea11d88
  98. https://blog.dreamfactory.com/what-is-an-api-ecosystem
  99. https://www.ecb.europa.eu/press/intro/mip-online/2018/html/1803_revisedpsd.en.html
  100. https://ozoneapi.com/blog/the-history-of-open-banking-industry-apis-and-payments/
  101. https://www.mulesoft.com/api/open-banking-apis-benefits
  102. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a
  103. https://www.firetail.ai/blog/moveit-series-breaches-enabled-apis
  104. https://www.cloudflare.com/learning/cloud/what-is-vendor-lock-in/
  105. https://cast.ai/blog/vendor-lock-in-and-how-to-break-free/
  106. https://nordicapis.com/10-data-regulations-all-api-developers-should-know-about/
  107. https://www.activemind.legal/guides/api-data-protection/
  108. https://www.computerweekly.com/news/365534673/Developers-say-Apple-and-Google-are-running-app-store-monopolies
  109. https://www.americanprogress.org/article/using-antitrust-law-address-market-power-platform-monopolies/
  110. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
  111. https://www.softwareimprovementgroup.com/eu-ai-act-summary/
  112. https://www.skadden.com/insights/publications/2025/08/eus-general-purpose-ai-obligations
  113. https://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/
  114. https://jcp.org/aboutJava/communityprocess/first/jsr054/jdbc-3_0-pfd-spec.pdf
  115. https://react.dev/versions
  116. https://numpy.org/doc/stable/user/basics.creation.html
  117. https://www.tensorflow.org/about/bib
  118. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
  119. https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-api-list
  120. https://developer.apple.com/documentation/corefoundation
  121. https://developer.apple.com/documentation/foundation
  122. https://www.kernel.org/doc/html/latest/userspace-api/index.html
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.