{
  "id": "application-programming-interface",
  "title": "Application Programming Interface",
  "lang": "en",
  "source_lang": "en",
  "summary": "A set of definitions and protocols that lets software components communicate and use each other's functions without exposing their internal implementation.",
  "category": "computer-science",
  "subcategory": "software",
  "type": "concept",
  "aliases": [
    "API",
    "programming interface",
    "application interface"
  ],
  "generated_at": "2026-10-08",
  "model": "pro/claude-haiku-5-5",
  "url": "https://aiwiki.page/en/application-programming-interface/",
  "translations": {
    "zh-Hans": {
      "url": "https://aiwiki.page/zh/application-programming-interface/",
      "json": "https://aiwiki.page/zh/application-programming-interface.json"
    }
  },
  "sections": [
    {
      "heading": "",
      "text": "An application programming interface (API) is a defined set of operations, data types, conventions and rules through which one software component uses the functions of another. The API specifies what a caller may request and what it will receive, while hiding how the provider carries out the work. This separation between a stable contract and a changeable implementation lets programmers build on code they did not write, lets systems be replaced or upgraded without breaking their users, and lets different organizations and machines exchange services. The idea is central to software engineering and underlies nearly every modern program, from a operating system kernel exposing system calls to a mobile application fetching data from a cloud service.\n\nThe concept has grown from local subroutine libraries of the early computing era into the web APIs that power the World Wide Web, mobile platforms, payment networks, and cloud infrastructure. Its design choices, including architectural styles such as REST, GraphQL and gRPC, event-driven interfaces, machine-readable specifications, and versioning rules, are shaped by trade-offs among simplicity, performance, security and long-term compatibility. APIs also raise economic and legal questions, because they can serve as platforms, competitive tools, and objects of intellectual property disputes.\n\nThis entry first defines the core concepts and traces the historical development of APIs. It then surveys the main types and architectural styles, followed by the mechanisms of interface description, request handling, security, versioning and design practice. The final sections cover documentation and developer experience, testing and performance, management and business models, legal and competition issues, applications across domains, relations to other fields, and open problems, including the emerging use of APIs by AI systems."
    },
    {
      "heading": "Definition and core concepts",
      "text": "An application programming interface (API) is the set of operations, inputs, outputs, data types and error conditions that one software component exposes for use by another. It works as a contract between a provider, which implements the behaviour, and a consumer, which relies on it. The contract covers what the provider promises, such as the result of a call, the cost of a call, and the conditions under which it fails. It does not cover how the provider achieves those results.\n\nPublic interface and private implementation\n\nThe public interface is the part of a component that consumers may depend on. The private implementation is everything else: internal data structures, helper routines, storage formats and algorithms. A function declaration in a header file is a typical example. The declaration states the name, the parameters and the return type, while the function body remains hidden. The provider can rewrite the body, optimise it or replace it entirely, and consumers are unaffected as long as the declared contract holds. The contract also includes less formal promises, such as preconditions, side effects, thread-safety guarantees and ordering rules, which often matter as much as the signature.\n\nAbstraction and information hiding\n\nAbstraction lets a developer use a component by its behaviour without knowing its internals. The principle of information hiding was stated most influentially by David Parnas in his 1972 paper \"On the Criteria To Be Used in Decomposing Systems into Modules\". Parnas argued that module boundaries should be drawn around design decisions that are likely to change, and that each module should reveal only what other modules need. He illustrated the point with a keyword-in-context indexing problem, comparing decompositions based on processing steps with decompositions based on hidden decisions. The second approach made later changes far less costly. An API is the practical form of this boundary: the interface stays fixed while the hidden decisions, such as data representation, can evolve. The same idea underlies software engineering practice in general.\n\nDistinguishing an API from related concepts\n\n- Application binary interface (ABI): An ABI is a binary-level contract. It fixes calling conventions, data layout, type sizes, alignment and symbol names so that compiled machine code can interoperate without recompilation. An API is a source-level contract. Two versions of a library may keep the same API while breaking the ABI, which forces dependent programs to be rebuilt. For this reason, see application binary interface.\n- Network protocol: A protocol specifies the rules and message formats exchanged between communicating parties on the wire, including sequencing, framing and error signalling. TCP/IP and HTTP are protocols. An API built on HTTP specifies application-level operations, such as which resources exist and which fields a request must contain. A protocol says how bytes move; an API says what a program may ask for.\n- Library: A library is a packaged collection of reusable code. An API is the interface the library exposes. One library can offer several APIs, and one API can be implemented by several different libraries or by a remote service.\n- Software development kit (SDK): An SDK is a bundle that usually includes one or more APIs, libraries, documentation, sample code, and tools such as compilers, debuggers or emulators for a given platform. The API is the contract, while the SDK is the toolkit that makes using it practical.\n\nBasic elements of an API\n\nMost APIs, whatever their style, consist of the same basic parts:\n\n- Operations or endpoints: The named actions a consumer can invoke, such as functions, methods or, in web APIs, URL paths combined with HTTP methods.\n- Parameters: The inputs an operation accepts, including which are required, which are optional, their types, and their permitted ranges or formats.\n- Return values: The results an operation produces and their structure, including whether a result may be absent.\n- Data types: The vocabulary used to represent information, such as integers, strings, timestamps, enumerations and nested records. Mismatched expectations about these types are a frequent source of integration errors.\n- Error conditions: The defined ways an operation can fail, expressed as exceptions, error codes or structured error responses, together with the conditions that trigger them.\n\nA well-specified API defines all five elements precisely, so that a consumer can use it correctly without reading the implementation. Those elements are the starting point for later topics such as documentation, versioning and the design of web interfaces."
    },
    {
      "heading": "Historical development",
      "text": "The idea behind an API predates the word. Its earliest clear form is the reusable subroutine library of the 1940s and 1950s. The 1951 book was a mass-printed version of a report titled Report on the Preparation of Programmes for the EDSAC and the Use of the Library of Subroutines written in September 1950 for private circulation and distributed to no more than 100 people. Its authors, Maurice Wilkes and David Wheeler, kept their routines on punched paper tape organized in a filing cabinet, and the accompanying notes on how to use each routine are what modern readers would recognise as API documentation: such a catalog would be called an API (or an API specification or API documentation) because it instructs a programmer on how to use each subroutine.\n\nMainframe computing in the 1950s and 1960s shaped the next stage. Programs were typically run in batches on shared machines, and software of that era was often large, monolithic documents of code. Subroutines were the main way to split such programs into parts that different people could write and call. Operating systems added their own service layers, and the hardware market was fragmented, so each new machine often meant rewriting software. The IBM System/360 line, with the operating system OS/360 introduced in 1964, was an early attempt to let one software base run across several models.\n\nThe term itself appeared in 1968. 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. The authors used it for the interaction between a graphics program and the rest of the system. The goal of their API was to make hardware-independent programs possible. In 1974, C. J. Date introduced the term to the field of databases in a 1974 paper called The Relational and Network Approaches: Comparison of the Application Programming Interface. The idea then entered the database architecture standards of the period.\n\nUnix contributed the idea of a stable system-call interface. The roots of POSIX can be traced back to the early days of UNIX, developed at Bell Labs in the 1970s. Calls such as open() and write() gave programs a file abstraction that hid the file system's internals. As Unix spread through vendors, however, software portability became a significant challenge, and applications written for one UNIX variant often required modifications to run on another.\n\nPOSIX was the response. In the mid-1980s, IEEE started a formal standardization effort (the 1003 \"P1003\" project) to define a consistent, vendor-neutral interface. The first version of this new standard was released by IEEE in 1988, under the name IEEE Std 1003.1-1988. The standard was defined based on System V and BSD Unix. POSIX does not define the operating system, it only defines the interface between an application and an operating system. As a result, programs are portable to other operating systems at the source code level. The standard was extended over the following decade: POSIX.1b in 1993 (real-time extensions), POSIX.1c in 1995 (thread extensions), and POSIX.2 in 1992 (shell and utilities), and after 1997, all the POSIX standards were gathered under a single umbrella for simplicity.\n\nIn the late 1980s and 1990s, the term moved from mainframes to personal computers and object-oriented software. The early days of computing saw the progression from large fill-the-whole-run mainframe computers of the 1960s to the PC era of the early 1980s. Object-oriented languages made class libraries practical: development teams would create class libraries that they could use in subsequent projects. The framework idea, in which a library calls back into user code, dates to one of the most significant contributions of SIMULA 67. Windows added the dynamic link library (DLL) that encapsulated different program modules, and graphical toolkits and the Windows API became the everyday meaning of the term for many developers. As the term broadened, it 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.\n\nThe shift to web APIs came at the turn of the millennium. Once the Internet and the Web were established, providers began exposing their data and services over HTTP to outside developers. Early examples included e-commerce and online marketplaces. Companies like Amazon, eBay, and Salesforce became the life of the API party, allowing third-party developers to build applications on top of their platforms. Mapping services followed, and the e-commerce sites of the early 2000s, along with map providers, showed that remote interfaces could drive traffic and third-party products. These early web interfaces used XML-based RPC and SOAP messages, which are discussed in the web architecture section below."
    },
    {
      "heading": "Types of APIs by scope and audience",
      "text": "APIs are commonly grouped by where they operate, who is meant to use them, and whether calls stay inside one process or cross a network. These groupings overlap, and one interface can belong to several at once.\n\nBy scope: language, operating system, hardware and web APIs\n\nA language or library API is the set of types, functions and conventions that a programming-language or its bundled libraries expose to a programmer, such as the standard collections or file-handling modules that a developer imports. An operating system API is the set of services a operating-system offers to applications, typically system calls for files, memory, processes and networking; the application requests the service, and the kernel performs it on the application's behalf. A hardware driver interface is the contract between the operating system and a device driver, which translates generic requests into commands that a particular disk, graphics card or network adapter understands. A remote or web API is reached over a network, usually using HTTP, and is the category most people mean when they speak of an API today, as described in the world-wide-web and internet entries. Each layer hides the details of the layer beneath it, so a program written against a library does not need to know which system calls the library makes.\n\nBy audience: public, partner and private APIs\n\nThe audience a provider has in mind largely determines how an API is governed. A public or open API is available to any developer who registers, and it is usually documented extensively, versioned carefully and protected by published rate limits. A partner API is shared only with selected organizations, typically under a contract, so it often comes with onboarding steps, dedicated quotas and negotiated service-level commitments. A private or internal API is used only inside one organization, for example to connect payroll and human-resources systems or to let microservices call each other. Internal interfaces are sometimes left thinly documented and changed quickly, because the provider controls every consumer; however, the same lack of outside pressure can allow weak design to persist and become costly to maintain as the organization grows. The labels describe intended use rather than technical reach: a private endpoint that is reachable from the public internet is still a private interface in intent, and it is the access controls, not the label, that enforce the boundary.\n\nFrameworks versus libraries: who controls the flow\n\nA library is a collection of reusable code that the application calls when it needs a particular function, so the application's own logic determines when and where each call happens. A framework reverses this relationship. It supplies the overall structure of the program, defines the points at which application code may be plugged in, and then calls that code at the right moments. This pattern is known as inversion of control, a term associated with the design of graphical user interfaces and enterprise software in which the framework's event loop or lifecycle manager decides when a handler runs. The distinction is not always sharp, since many toolkits combine both styles, but the question of who calls whom is the usual test. A web framework that invokes a developer's request handler, and a numerical library that a developer calls inside a loop, expose very different kinds of interface even though both are described as APIs.\n\nLocal and remote implementation\n\nAn API may be implemented in-process, meaning that the caller and the implementation share an address space and a call is little more than a function invocation, or it may be accessed across a network, where each call becomes a message exchanged between machines. This difference has practical consequences. A local call typically completes in nanoseconds to microseconds and fails in a limited number of ways, usually by raising an exception or returning an error code. A remote call may take milliseconds or longer, may be lost or duplicated in transit, and may succeed on the server while the client receives a timeout, so consumers must handle partial failure, retries and uncertain outcomes. Security also changes: an in-process interface relies on the surrounding process's memory protection, whereas a network interface must authenticate callers, encrypt traffic and defend against attacks that can arrive from anywhere. Designers who hide a remote call behind a method that looks local can therefore mislead developers about latency and reliability, which is one reason network-facing APIs are usually designed with explicit timeouts and error types from the outset."
    },
    {
      "heading": "Web API architectural styles",
      "text": "Web APIs are reached over the Internet using standard application protocols, and several architectural styles have competed to define how requests, payloads and contracts are organized. They differ mainly in how strictly they constrain messages, how much of the interface is described in advance, and whether the design centers on data resources or on remote operations.\n\nSOAP and XML-RPC\n\nXML-RPC, introduced in 1998 by Dave Winer and Microsoft, encoded a remote procedure call as an XML document sent in an HTTP POST, with a small set of typed values such as integers, strings, booleans, arrays and structs. SOAP, which was originally an acronym for Simple Object Access Protocol, grew out of this lineage and was submitted to the W3C in 2000. Every SOAP message is wrapped in an envelope that contains an optional header for metadata, such as security tokens, and a body that carries the payload. Errors are reported as structured fault elements. Interfaces are usually described in WSDL (Web Services Description Language), which lists operations, message types and bindings, while XML Schema validates the payloads. This formality appealed to enterprises that wanted generated client stubs and tooling, and it gave rise to the WS-* family of specifications for security, reliable messaging and transactions. The cost was verbosity and heavy tooling; SOAP clients were awkward to write by hand and difficult to use from browsers, and implementations of the WS-* stack often interoperated poorly.\n\nREST\n\nRepresentational State Transfer (REST) was named and defined by Roy Fielding in his 2000 doctoral dissertation at the University of California, Irvine. Fielding described it as an architectural style abstracted from the design of the World Wide Web itself. Its constraints include client–server separation, statelessness (each request carries the information needed to process it), cacheability, a uniform interface, a layered system, and optional code-on-demand. In web APIs, REST is typically realized as resources identified by URIs, such as a path naming an order, manipulated through standard HTTP methods. GET retrieves a representation without side effects, POST creates a resource or triggers processing, PUT and DELETE are defined as idempotent, and PATCH applies partial changes. Outcomes are signaled with HTTP status codes grouped by class: 2xx for success, 3xx for redirection, 4xx for client errors and 5xx for server errors. Because GET responses are addressed by URL and are marked with cache directives, shared caches and proxies can store them, which is one reason REST fits the existing Web infrastructure well. Fielding's definition also calls for hypermedia as the means of driving application state; most practical APIs omit this, a point taken up in the section on design principles. Many interfaces labeled \"REST\" behave more like remote procedure calls carried over HTTP, and maturity models such as Leonard Richardson's graded levels 0 to 3 describe this spectrum.\n\nGraphQL\n\nGraphQL was developed inside Facebook from about 2012 and was released publicly in 2015; it is now maintained as an open specification. Rather than offering many fixed endpoints, a GraphQL service exposes a single endpoint and a typed schema that describes object types and their fields. A client sends a query naming exactly the fields it needs, including fields of nested related objects, and receives a JSON response with the same structure. This reduces over-fetching, in which a response carries unused data, and under-fetching, in which a client must make several round trips to assemble related records. Writes are expressed as mutations, and live updates as subscriptions.\n\nThe flexibility has costs. Queries are normally sent as POST bodies to one URL, so the URL-based HTTP caching that serves REST so well does not apply directly; caching moves to the field or resolver level, to persisted queries registered in advance under an identifier, or to normalized caches in the client. Client control also shifts cost to the server, because a deeply nested or wide query can fan out into many backend calls. Providers respond with depth limits, complexity scoring, timeouts and rate limits measured in query cost. Naive resolver implementations can issue one database call per item in a list, a pattern known as the N+1 problem, which batching loaders are used to avoid. Authorization must also be checked for each field and object rather than only per endpoint.\n\ngRPC and RPC styles\n\nRemote procedure call (RPC) styles predate the Web and include Sun RPC, CORBA and Java RMI; they present a network call as if it were an ordinary local function call. gRPC, open-sourced by Google in 2015, is a modern example. Services and methods are declared in Protocol Buffers interface definition files, from which client and server code is generated for many languages. Messages are encoded in the compact binary Protocol Buffers format and carried over HTTP/2, which multiplexes many concurrent streams on a single connection and compresses headers. gRPC supports unary calls as well as client-streaming, server-streaming and bidirectional-streaming methods.\n\nThese properties make gRPC well suited to internal microservice traffic, where both ends belong to one organization, serialization overhead and latency matter, and strongly typed contracts reduce integration errors. Its limitations for public use are practical: browsers cannot issue native gRPC calls and need a translation layer such as gRPC-Web, binary payloads are harder to inspect with ordinary tools, and compatibility depends on disciplined evolution of the schema. Like other RPC systems, it also makes the distributed nature of the call easy to forget, so timeouts, retries and partial failures must be handled explicitly, as in any distributed computing design."
    },
    {
      "heading": "Event-driven and real-time interfaces",
      "text": "Request–response versus event-driven designs\n\nMost web APIs follow a request–response pattern: the consumer sends a request, waits, and receives a response. The provider speaks only when asked. This model is simple, but it is inefficient when a consumer needs to know about changes as they happen. The consumer must poll, repeatedly asking whether something has changed. Polling trades latency against load: short intervals waste requests, and long intervals delay updates.\n\nEvent-driven designs reverse the direction of initiative. The provider publishes a notification when a relevant state change occurs, and the consumer reacts. The same underlying system can expose both styles. A payment service might offer a query endpoint for the current status of a transaction and also send a notification when that status changes.\n\nPush mechanisms: webhooks, server-sent events and WebSockets\n\nA webhook is an HTTP callback. The consumer registers a URL with the provider, and the provider sends an HTTP POST to that URL when a subscribed event occurs. Webhooks are common in payment, code-hosting and messaging platforms. Because the consumer must expose a publicly reachable endpoint, the receiver typically verifies a signature on each payload, responds quickly with a success status, and processes the work asynchronously. Providers usually retry failed deliveries, so the receiver must tolerate duplicates and out-of-order arrival.\n\nServer-sent events (SSE) keep a single HTTP response open and stream text-based events from server to client. The stream is one-directional, and the browser's built-in mechanism can reconnect automatically and resume from the last event identifier. SSE suits news tickers, progress indicators and incremental output from generative models.\n\nWebSockets, standardized in RFC 6455 in 2011, upgrade an HTTP connection to a persistent, full-duplex channel over a single TCP connection. Both sides can send messages at any time. This suits chat, multiplayer games, collaborative editing and streaming market-data feeds in financial services. The cost is state: each connection is long-lived, so load balancers, reconnection logic and re-subscription after failures become design concerns.\n\nMessage brokers and publish–subscribe\n\nIn a publish–subscribe system, producers publish messages to named topics or channels without knowing who will consume them. A message broker stores and forwards those messages. Consumers subscribe to topics and receive copies, which allows one event to fan out to many independent services. Because the broker buffers messages, producers and consumers are decoupled in time: a consumer can be offline and catch up later. They are also decoupled in location and deployment, since neither side needs the other's network address. Systems such as Apache Kafka and RabbitMQ implement variants of this model, with different trade-offs in ordering, retention and routing. Designing an event API means specifying topic names, message schemas and versioning rules, much like a request–response contract.\n\nDelivery guarantees and idempotent handlers\n\nMessaging systems make explicit promises about delivery. At-most-once delivery sends each message without retries, so messages can be lost but never duplicated. At-least-once delivery retries until the consumer acknowledges receipt, so no message is lost but duplicates can occur. Exactly-once processing, in which each event has exactly one effect, is difficult to achieve over unreliable networks in the strict sense. In practice, systems approximate it by combining at-least-once delivery with deduplication, transactional offset commits or idempotent processing. Ordering guarantees also vary; many brokers order messages only within a partition or key.\n\nFor this reason, consumer handlers should be idempotent: processing the same event twice must produce the same result as processing it once. Common techniques include recording processed event identifiers, using conditional writes or version checks, and designing state changes as absolute assignments rather than increments. Without idempotent handling, retries that are safe at the transport level can cause double charges, duplicate notifications or inconsistent records."
    },
    {
      "heading": "Interface description, schemas and data formats",
      "text": "Machine-readable interface descriptions\n\nA machine-readable interface description records an API's operations, parameters, data types and responses in a form that software can parse. For HTTP-based services, the most widely used format is the OpenAPI Specification, which was derived from the Swagger Specification and handed to the Linux Foundation in 2016. An OpenAPI document, written in YAML or JSON, lists each path, the operations on it, the parameters and request bodies it accepts, the response schemas and status codes, and the security schemes in use. The specification does not require rewriting an existing service or binding software to it, so a description can be produced by the operator or by a third party.\n\nSOAP-era services relied on WSDL. Version 2.0 became a W3C Recommendation in 2007 and separates the abstract functionality of a service, meaning the messages exchanged and their types, from concrete details such as the protocol binding and the endpoint address. Its version 1.1 predecessor was not endorsed by the W3C. GraphQL uses a typed schema that defines object types, queries and mutations, and clients can introspect that schema at runtime. For binary RPC, Protocol Buffers use .proto files to define messages and fields. Each field carries a type, a name and a numeric tag. Those tags, not the names, identify fields on the wire, so they must never be reused once a message is in service. Tags 1 to 15 encode in one byte, tags 16 to 2047 in two, and the range 19000 to 19999 is reserved for the implementation. Retired tags and names are declared as reserved so that later editors cannot accidentally recycle them.\n\nWhat machine-readable descriptions make possible\n\nBecause the description is structured data, many tools can consume it. Documentation generators render interactive reference pages, and code generators emit client libraries and server skeletons in several languages. Mock servers can return example responses so that front-end teams can start work before the back end exists. Validators can check incoming requests and outgoing responses against the declared schemas, and diff tools can compare two versions of a description to flag removed fields or changed types before release. These uses depend on the quality of the description: if the file drifts from the running implementation, generated clients and mocks will mislead their users. This is why many teams generate the description from code, or test the implementation against it, as discussed in the sections on documentation and on testing.\n\nData formats and their trade-offs\n\nJSON is text-based, readable in a browser or a log file, and supported by parsers in virtually every language, which explains its dominance in web APIs. Its cost is verbosity, since every object repeats its field names, and its type system is minimal: it has no native date, binary or integer-size distinction. XML is also text and self-describing, with namespaces and schema languages such as XML Schema, but it is typically larger and slower to parse, and it remains common in enterprise, financial and older SOAP systems. Protocol Buffers are compact binary messages whose generated classes give strongly typed access, and parsing them is generally faster and produces smaller payloads than equivalent JSON. The price is that a binary message cannot be read without the schema, and the library itself does not compress output, so transport-level compression is often added separately. Other binary encodings, such as MessagePack, CBOR and Avro, occupy similar niches with different schema models. Choosing among them means weighing human readability for debugging against payload size, parsing cost and the strictness of the schema, and actual measurements on realistic payloads are usually more reliable than general rules.\n\nSerialization pitfalls\n\nMany interoperability failures occur at the serialization layer even when the specification is correct. Type mismatches are common: a field documented as a number may arrive as a string, or an optional field may be sent as null where clients expect it to be absent. Protocol Buffers avoid some of this with strict types, but in proto3 an unset numeric field and a field explicitly set to zero look identical on the wire, which matters when a zero value carries meaning.\n\nNumber representation causes subtle errors. The JSON standard does not fix a precision for numbers, but many parsers, including the default one in JavaScript, store them as IEEE 754 double-precision values, which represent integers exactly only up to 2^53. A 64-bit identifier or a monetary amount in minor units can therefore be silently rounded on the client. A common remedy is to transmit such values as strings. Dates raise similar issues: ambiguous local times, missing time-zone offsets, and confusion between seconds and milliseconds since the Unix epoch can all shift data without triggering an error. Timestamps are usually sent as ISO 8601 or RFC 3339 strings with explicit offsets.\n\nCharacter encoding must also be specified. JSON exchanged between systems is conventionally encoded in Unicode using UTF-8, and Protocol Buffers require string fields to be valid UTF-8. Length limits are a frequent source of disagreement, because a limit counted in bytes, UTF-16 code units or code points yields different results for the same text. Finally, schema validation has to decide how to treat unknown fields: strict rejection makes errors visible early, while tolerance allows older clients to survive additions. Either way, validation at the boundary, with clear rules for nulls, defaults and absent fields, prevents the most common silent failures."
    },
    {
      "heading": "Requests, responses and error handling",
      "text": "A single API call is a short exchange with a fixed shape. The consumer assembles a request that names an endpoint, usually a URL combined with an HTTP method that signals the intended action, and adds headers that carry metadata such as the content type, the accepted response format, and the credential identifying the caller. Write operations often include a payload in the body, typically JSON. The provider authenticates and validates the request, performs the operation, and returns a status line, response headers and, for most successful calls, a response body. Because the traffic crosses the Internet and often passes through load balancers, gateways and proxies, an intermediary can answer on its own. A client may therefore receive a status code that never came from the application it was calling, so error handling has to consider where a response originated.\n\nHTTP status codes are three-digit numbers whose first digit gives the broad outcome. 4xx responses signal a problem in the request, so the client should change the request before retrying, and repeating the same request produces the same answer. A 5xx response instead means the server could not complete a valid request, so an identical request often succeeds on a later attempt. Finer distinctions matter in practice: 401 Unauthorized means authentication is missing or invalid, while 403 Forbidden means you're authenticated but don't have permission to access the resource. A 429 response signals that a rate limit has been exceeded, and 503 indicates the service is temporarily unavailable, often overloaded or under maintenance. Status codes alone are coarse, so well-designed APIs add a structured error object to the body. Such an object typically contains a stable machine-readable code, a human-readable message, the offending field where relevant, and a request identifier that support staff can trace. Clients should branch on the stable code and the status class rather than on message text, which can be reworded or translated without notice. Returning a success status with an error hidden inside the body breaks generic monitoring, proxies and retry logic, and it is a common design fault.\n\nPagination determines how large collections are returned in pieces, and the two main strategies behave differently under change. Offset pagination, expressed in SQL as LIMIT and OFFSET or in a URL as a page number, asks the server to skip a number of records. Offset pagination scans and discards every row before the offset, so a deep page does real work that the first page does not. Its consistency problem is more serious than its cost: it can silently skip or repeat rows when items are inserted or deleted between requests. Cursor pagination instead returns an opaque position marker that the next request presents. Keyset-style cursors seek to the last-seen position using an indexed column, so the cost stays roughly constant regardless of depth, and the results remain stable under concurrent writes. The trade-off is that cursors cannot jump to an arbitrary page, and cursor-based traversal requires a stable sort order. Sorting on a non-unique column without a tiebreaker produces unpredictable cursors, so a unique identifier is usually appended to the sort key. Switching between the two schemes is itself a breaking change for consumers, which links this topic to versioning.\n\nFailures in the network are ambiguous, and the client's timeout is the point where that ambiguity becomes dangerous. When a request times out, the client cannot tell whether the server processed it. For safe methods such as GET this is harmless, but HTTP designates GET, HEAD, PUT and DELETE as idempotent, meaning that doing them twice has the same effect as doing them once. POST is not. A blind retry of a payment or order POST can therefore charge a customer twice. Retries should be restricted to transient conditions such as timeouts, 429 and 503 responses, and they should back off over time. In exponential backoff, the delay between attempts grows multiplicatively, typically doubling after each failed attempt. Adding randomness, or jitter, matters because without it clients retrying a downed service all strike again at the same synchronized intervals. Clients should also honour any server-supplied retry guidance and cap the total time spent retrying.\n\nThe standard remedy for non-idempotent operations is an idempotency key. The client generates a unique value for each logical operation and sends it with every attempt, usually in an Idempotency-Key header. The server records the key together with the outcome, so a repeated request returns the stored result instead of repeating the side effect. The key must be reused across retries: generating a new key for every retry makes the server treat each retry as a new operation. Servers must also decide how long keys remain valid, and twenty-four hours is the common default. Finally, idempotency protects a single call and does not make a multi-step workflow safe by itself, so each step in a longer process still needs its own recovery logic."
    },
    {
      "heading": "Authentication, authorization and security",
      "text": "API security rests on two distinct questions: who is making the call (authentication), and whether that caller may perform the requested operation on the requested data (authorization). Most serious API failures involve one of these two questions being answered incorrectly, and the credential scheme chosen determines how reliably each can be answered.\n\nCredentials and common methods\n\nThe simplest mechanism is the API key, an opaque string issued to a developer or application and attached to each request. A key identifies the calling project rather than a person. That makes it useful for metering and quotas, but a weak basis for per-user decisions, and keys that leak into client-side code or logs must be rotated. HTTP Basic authentication sends a username and password in an encoded header, so its safety depends entirely on encrypted transport. Bearer tokens, carried in the Authorization header, are honored on possession alone, which makes token lifetime, storage and transport protection the central concerns.\n\nOAuth 2.0 addresses a different problem: letting a third-party application reach a user's data without learning the user's password. OAuth 2.0 RFC 6749 (October 2012): IETF standard for delegated authorisation, access tokens, authorization code/implicit/client credentials/password flows. It defines four roles: the user as resource owner, the application as client, an authorization server that issues tokens, and a resource server hosting the protected API. Its grant types suit different clients. Authorization Code — standard for webapps with backend; user-agent + backend code-for-token exchange, while client credentials cover machine-to-machine access without a user present. Scopes limit what a token may do, and the draft successor OAuth 2.1 is intended to consolidate current practice, dropping the implicit flow. Note that OAuth 2.0, as specified in RFC 6749, is not an authentication protocol but an authorization framework. OpenID Connect fills that gap by layering an identity service on top of OAuth 2.0, returning a signed ID token that describes who the user is and how they were authenticated.\n\nTokens: JWT and mutual TLS\n\nA JSON Web Token is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. A signed token has three dot-separated parts: a header, a payload of claims, and a signature. Standard claims such as the issuer (iss), subject (sub) and audience (aud) let a receiving service check who issued the token, whom it concerns, and whether it was meant for that service. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. Best-practice guidance on validating JWTs is collected in RFC 8725.\n\nThe design choice here is a trade-off. Because the token is self-contained, a resource server can verify its signature and expiry locally, avoiding a call to a central session store on every request. The cost is that a signed token remains valid until it expires unless the system adds a denylist or a central check, so revocation after a compromise is slower. Centralized session checks or token introspection give immediate revocation but add a network hop and a shared runtime dependency. A common compromise pairs short-lived access tokens with longer-lived refresh tokens that can be revoked centrally.\n\nMutual TLS (mTLS) moves authentication into the transport layer. During the TLS handshake, the server also requests and validates a client certificate, so both parties are cryptographically identified before any request is sent. This suits service-to-service traffic and regulated financial interfaces, but it carries operational costs in certificate issuance, rotation and revocation, and it identifies a machine or application rather than an end user.\n\nRate limiting and quotas\n\nRate limits and quotas cap how much a client may consume within a time window, keyed by API key, user, IP address or endpoint. They protect against abuse, scraping and denial of service. The OWASP list tracks this under unrestricted resource consumption; in the 2019 edition the category was API 04:2019 – Lack of Resources & Rate limiting. Limits interact with access control in several ways. Quotas are only meaningful when tied to an authenticated identity, so limits keyed to users are fairer than per-IP limits, which distributed attackers can easily evade. Yet keying limits to identity means they run after authentication, so unauthenticated endpoints such as login and password reset need separate protection. Finally, rate limits do not substitute for authorization: they slow enumeration of records that a caller should never see, but they do not stop a permitted-looking request from returning the wrong object.\n\nMajor vulnerability classes\n\nThe OWASP API Security Top 10 was first released on 31 December 2019 and was revised in 2023. The first entry, broken object level authorization, is widely treated as the most serious. It occurs when an API endpoint accepts an object identifier (a user ID, an order ID, a document ID) and returns the object without checking whether the calling user is authorized to see that specific object. Because attackers can simply iterate identifiers, the flaw scales easily.\n\nBroken authentication, in OWASP's wording, happens when authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Excessive data exposure and mass assignment were merged in 2023 into broken object property level authorization, covering responses that reveal fields the caller should not see and requests that set fields the caller should not control. Broken function level authorization concerns administrative or privileged operations that lack role checks, and unrestricted resource consumption covers the rate-limiting gap described above.\n\nThe 2023 edition also introduced Unrestricted Access to Sensitive Business Flows, Server Side Request Forgery, and Unsafe Consumption of APIs. Injection deserves a note: it was a standalone category (API8:2019) in the 2019 list, but in the 2023 edition injection is included in Unsafe Consumption of APIs, which concerns how a service trusts data received from third-party APIs."
    },
    {
      "heading": "Versioning, evolution and compatibility",
      "text": "An API keeps changing after it is published, and each change either preserves or breaks the assumptions of the programs that already call it. A breaking change is one that can make a previously working client fail. Examples include removing or renaming a field, changing a parameter's type, adding a new mandatory argument, tightening validation, or changing what a status code means. A non-breaking change leaves existing requests and responses valid. Adding an optional parameter or a new response field is usually the safe choice. Removing or renaming a field is risky because a client that reads that field fails immediately. An extra field is usually harmless, but only if the client ignores keys it does not recognize. Providers therefore tend to evolve interfaces additively, and many API guidelines treat that as the default rule.\n\nVersioning strategies\n\nProviders that must make breaking changes usually choose one of four ways to label versions. Each has trade-offs:\n\n- URL path versions (for example, a /v1/ prefix before a /v2/ prefix) are explicit and easy to route, log and cache. The cost is that each major version becomes a separate set of URLs, and providers may need to maintain parallel code paths.\n- Custom request headers keep URLs stable and let the consumer name a version in a header. They are less visible than paths, which makes them harder to inspect in browsers, logs and simple tests.\n- Media-type negotiation uses the HTTP Accept header to request a vendor-specific media type that includes a version. This fits HTTP content negotiation well, but it is less familiar to newcomers and harder to test by hand.\n- Date-based versions label each behavior change with a release date. A consumer pins the version that was current when it integrated, so the provider can ship changes under newer dates while old pins keep their original behavior. Payment APIs are a well-known example of this approach.\n\nWhatever scheme is used, the important discipline is treating each published version as frozen. Changing behavior under an existing label is a breaking change, even when the change looks like a fix.\n\nDeprecation, sunset and migration support\n\nDeprecation tells consumers that a feature still works but should no longer be used, and that it may be removed later. A deprecation policy usually states how much notice will be given, how long the old behavior will remain available, and what support is offered during the overlap. Two HTTP headers support this process. The Sunset header, defined in RFC 8594 in 2019, carries a timestamp indicating when a URI is likely to stop responding, and the specification describes it as a hint rather than a guarantee. The later Deprecation header defined in RFC 9745 marks the start of the deprecation lifecycle, so the two are often used together. Changelogs list what changed and when, while migration guides show before-and-after examples and explain how to find affected calls. Providers can also track usage of deprecated endpoints, so they know which consumers still need to move before removal.\n\nLibrary-level compatibility\n\nFor libraries and packages, compatibility is often expressed through semantic versioning. In SemVer 2.0.0, a MAJOR.MINOR.PATCH number changes in a defined way: the major number for incompatible API changes, the minor number for backward-compatible additions, and the patch number for backward-compatible bug fixes. Deprecating public functionality is supposed to trigger a minor release. Version 0.y.z is explicitly treated as initial development, where anything may change. The scheme is only as useful as the declared public API, so SemVer requires that the public API be specified in code or documentation. Package managers build on these rules through version ranges. For example, npm's caret range allows minor and patch updates but excludes the next major version.\n\nSource compatibility and ABI stability are different matters. The application binary interface covers compiled details such as symbol names, function calling conventions, data layout and struct field offsets. A change can preserve source code compatibility while breaking already-compiled binaries. Adding a field to a public struct or changing a default argument that the compiler has inlined into callers are typical examples. Library maintainers who care about binary consumers must therefore track ABI changes separately from source-level changes.\n\nUndocumented behavior and Hyrum's Law\n\nThe hardest compatibility problem is that consumers depend on behavior the documentation never promised. Hyrum's Law, usually attributed to Google engineer Hyrum Wright, observes that with enough users, every observable behavior of a system will be depended on by somebody, whatever the contract says. Ordering, timing, error wording and side effects can all become de facto interfaces. Microsoft Windows is often cited for applications that relied on undocumented behaviors and broke when those were changed. A library may document its results as unordered while consistently returning them sorted, and users may then build code that assumes the order. The consequence is that semantic versioning protects only the declared API, and internal changes can still break someone. Mitigations include documenting explicitly what is guaranteed, black-box testing from a consumer's perspective, deprecation windows backed by usage telemetry, and feature flags that allow gradual rollout."
    },
    {
      "heading": "Design principles and best practices",
      "text": "Good API design rests less on clever features than on predictability. Consistency comes first. Naming, error formats and resource layout should follow one pattern across the whole interface, so that a developer who has learned one endpoint can guess the rest. Calling the same kind of thing \"users\" in one place and \"customers\" in another is a common source of confusion. This expectation is usually framed as the principle of least astonishment, also called the principle of least surprise. It was in use in relation to computer interaction since at least the 1970s, and it applies to method names and call behavior as much as to screens. A method named deleteFile() should remove the file, rather than quietly archiving it or failing because the file is missing. A related example is a database driver whose close call opens a second connection; users would find that astonishing. Consistency is also context-dependent. Financial-industry developers may expect idempotency keys on every write operation, while game developers may not.\n\nAPI-first design\n\nAn API-first approach is a development methodology where teams design the API contract, usually as an OpenAPI spec, before writing any application code, then build the implementation against that agreed contract. In this model the interface is treated as a product in its own right rather than a byproduct of the backend. Teams define endpoints, payload structures, response formats and error handling in a specification format such as OpenAPI or AsyncAPI before the business logic is written. The main benefit is that the contract can be reviewed while changes are still cheap. Revising a preliminary definition takes much less effort than revising a system that is already partly implemented. The approach also lets frontend and backend teams work in parallel against mock servers. The trade-off is a risk of over-specifying the contract, which can add complexity or features that are never implemented.\n\nMinimal exposure\n\nAn interface should publish only what consumers actually need. Every public operation, field or identifier becomes a promise, and removing it later is a breaking change. Exposing internal models is a particular hazard: when an API mirrors database tables or internal class hierarchies, clients become coupled to implementation choices, and ordinary refactoring breaks them. Leaked internal fields can also reveal data that should stay private, which links minimal exposure to cybersecurity and to the access controls discussed elsewhere in this article. In practice, designers keep a small public surface, map internal objects to purpose-built external representations, and treat each addition as a commitment.\n\nHypermedia controls (HATEOAS)\n\nHATEOAS, or hypermedia as the engine of application state, is the constraint in REST that asks servers to tell clients what they can do next. Clients interact with a RESTful API through the hyperlinks that the server supplies in its responses. A response for a book, for example, might carry links to purchase it, review it or find similar titles, so the client need not hard-code those URLs. Because clients discover actions at runtime, changes to the API do not necessarily force changes to the client. Despite these advantages, adoption is limited. A 2019 study of popular web APIs found that less than a fifth of the analyzed Web APIs provide links to related resources. The same study noted that HATEOAS marks the largest departure from earlier web service approaches, which relied heavily on predefined interfaces. Prominent exceptions were PayPal and GitHub, which feature hypermedia links prominently in their documentation. Most production APIs therefore adopt hypermedia only partially, using a few links such as pagination \"next\" references while leaving clients to rely on documented URL templates."
    },
    {
      "heading": "Documentation and developer experience",
      "text": "For most consumers, an API is known only through its documentation. A good documentation set usually has four layers. The reference pages list every endpoint, parameter, data type, return value and error code, and they are most reliable when generated from a machine-readable description. Conceptual guides explain the rules that span many endpoints, such as authentication, pagination, rate limits, versioning and idempotency keys. Quick starts walk a newcomer from obtaining credentials to a first successful call, and runnable examples, such as copyable request snippets or sample projects, let developers verify behavior before writing their own code. These layers serve different readers: a reference page answers \"what does this field mean\", while a quick start answers \"how do I get anything working today\". Providers that mix the two often confuse both groups. Documentation of this kind belongs to the wider discipline of software documentation.\n\nThe cost of a developer's first successful request is one of the main barriers to adoption, and providers reduce it with test environments. A sandbox is a separate environment, usually with fake or isolated data, in which requests cannot affect production records. Some providers offer open sandboxes that anyone can create, while paying customers receive private sandboxes with extra simulation features, such as generating test transactions or triggering webhooks. The distinction matters: an API that operates on real data by default pushes the burden of caution onto the developer, which is why providers recommend a separate test workspace for experimentation. Interactive API explorers complement sandboxes. Tools such as Swagger UI render an OpenAPI description into a page where a developer can fill in parameters and send live requests, while command-line tools such as cURL let them reproduce the same call in a terminal or script.\n\nOfficial SDKs and generated client libraries reduce integration work further by handling authentication headers, serialization, error decoding and retries in a language-specific form. Many providers generate these clients from the same specification that produces the reference pages, so that the documented surface and the client surface stay aligned. Open-source generators such as OpenAPI Generator support many target languages, while commercial and newer tools generate SDKs together with documentation sites and tests from one definition. Generated code is not automatically good code, however, and a generated SDK is only as clear as the names and descriptions in its source specification. Around the code, developer portals provide account registration, API key creation and rotation, usage dashboards and onboarding checklists. Community forums, changelogs and support channels then turn a product into a community of users who can help each other.\n\nDocumentation is also part of the contract. Once a behavior is described publicly, consumers reasonably rely on it, so a documented promise about a field, a limit or an error code carries the same weight as the endpoint itself. Documentation is therefore a source of obligation as well as guidance, which is why providers treat changes to docs with the same care as changes to code. The difficulty lies in keeping the two synchronized. Descriptions drift when developers change behavior without updating the text, sample responses become stale, and deprecation notices are missed or published late. Common mitigations include generating reference material directly from the specification, running documentation examples as automated tests in continuous integration, and publishing release notes with every breaking or non-breaking change. Even with these practices, the gap between what the documentation says and what the service does is one of the most frequent sources of integration failures, and it is a reason that software engineering teams increasingly treat documentation accuracy as something to be verified rather than assumed."
    },
    {
      "heading": "Testing, reliability and performance",
      "text": "Testing an API happens at several levels, and each catches a different class of defect. Unit tests exercise a single handler or client function, usually with stubbed dependencies. Integration tests run the provider together with its real database, queues and downstream services. Contract tests sit between the two: they verify that the wire-level agreement between a provider and its consumers still holds, without bringing up the whole system. Because a full end-to-end environment is slow and brittle, teams often rely on contract tests to catch breaking changes early.\n\nContract testing and consumer-driven contracts\n\nIn the consumer-driven approach, the client writes the first test. The consumer's test declares the requests it sends and the minimal response fields it depends on, runs against a mock of the provider, and produces a contract file. The provider then replays those recorded interactions against its real implementation and fails the build if a response no longer satisfies a consumer's expectations. Pact is the best-known tool for this workflow. Its value lies in exposing which parts of an API are actually used, so a provider can change unused fields freely while being warned about changes that would break real clients. The cost is coordination: providers must run every consumer's contract, and the teams involved must agree on when a contract may change. This connects directly to the versioning and compatibility concerns discussed elsewhere in this entry.\n\nPerformance measures and techniques\n\nPerformance is usually described with three measures. Latency is the time one request takes, and for APIs it is more informative to report percentiles than averages, because a small share of very slow requests (tail latency, often expressed as p99) determines how the slowest user experiences the service. Throughput is the number of requests a system can complete per unit of time. The third concern is resource efficiency at the connection level. Common techniques include caching responses with appropriate validity headers, compressing payloads, batching many small operations into one call, and reusing persistent connections so that each request avoids the cost of a new TCP and TLS handshake. Modern protocols such as HTTP/2 add multiplexing, which lets several requests share one connection.\n\nObservability\n\nObservability means being able to determine what a running API is doing from the telemetry it emits. Three kinds of signal are used together. Logs record discrete events, ideally structured and carrying request identifiers. Metrics are aggregated counters, gauges and histograms, typically broken down by endpoint, status code and consumer, so that teams can see which operations are heavily used and where error rates rise. Distributed tracing follows a single request as it crosses several services, recording the time spent in each hop; it is the main tool for locating a slow dependency in a microservice chain. Good metrics for an API usually cover request rate, error rate and duration per endpoint, which makes it possible to tell whether a problem affects one route or the whole service.\n\nReliability: service-level objectives, fault isolation and degradation\n\nReliability targets are expressed as service-level objectives (SLOs), which are internal targets such as a given share of successful requests over a month, and as service-level agreements (SLAs), which are contractual commitments that may carry financial penalties. An SLO implies an error budget: the amount of unreliability a team may spend on releases and experiments before it must prioritize stability. Whether an API meets its objectives depends heavily on how failures are contained. Michael Nygard's book Release It!, published in 2007, catalogued stability patterns including timeouts, bulkheads that partition resources so one failing workload cannot exhaust a shared pool, and circuit breakers. A circuit breaker sits in front of a remote dependency and moves between closed, open and half-open states: it lets calls pass while failures remain rare, rejects calls immediately once failures exceed a threshold, and periodically admits a probe request to test recovery. Netflix's Hystrix library later popularized the approach in microservice systems. Graceful degradation complements these measures: when a dependency is unavailable, the API may return cached data, omit a non-essential field, or switch to a simpler algorithm, so that the core function continues to work rather than failing completely."
    },
    {
      "heading": "API management, business models and the API economy",
      "text": "Gateways and management platforms\n\nOnce an API is exposed beyond a single team, providers usually place a gateway in front of it. An API gateway is the runtime component that sits between your API consumers and your backend services. It typically handles request routing, authentication, rate limiting, request and response transformation, and protocol translation, which lets policies change without touching application code. Gateways are also the enforcement point for quotas. Limits can be set by client IP address, API key, user account, or other factors.\n\nA gateway is only one part of a larger stack. API management adds lifecycle capabilities on top: a developer portal for API discovery and onboarding, versioning and deprecation workflows, usage analytics, monetization, and governance policies. Onboarding usually means self-service sign-up and key issuance, so a developer can move from registration to a first successful call without help from the provider's staff. Analytics data, such as per-endpoint call counts and error rates, also feeds into pricing decisions.\n\nMonetization models\n\nAPI monetization is the process of generating direct or indirect revenue by controlling and metering access to application programming interfaces. The most common direct models are:\n\n- Freemium. Freemium offers a usage tier with no payment required, up to a volume threshold. Above that threshold, payment begins. Google Maps is a standard case: a limited number of uses are provided for free and customers must pay fees for additional uses.\n- Pay-per-call. Each request carries a price. Published figures cited for this model are typically ranging from $0.001 to $0.05 per call depending on the API's value and computational cost. Cloud gateway pricing is a concrete example: AWS API Gateway charges $3.50 per million requests.\n- Tiered subscription. Fixed monthly plans bundle included quotas, with overage billing per tier for usage beyond the plan.\n- Revenue share. The provider takes a cut of transactions the API enables, as in payment and marketplace APIs.\n\nEach model carries trade-offs. Pay-per-call makes revenue track usage, which is hard to forecast; one comparison rates it as unpredictable revenue. It can also work against adoption, because the customers who use the API most pay the most. Subscriptions give predictable income but can leave heavy users underpriced. Hybrid designs, which combine a base fee with metered overage, are common for this reason. Pricing also has to balance the provider's cost of serving requests against what customers will pay, which is especially sensitive for compute-heavy AI endpoints.\n\nThe API economy\n\nThe term describes the commercial side of this activity. In one definition, it is the ecosystem of business models, partnerships, and revenue streams enabled by application programming interfaces that allow software systems to communicate and share data. Firms use it in two directions. Some sell their own capabilities as products. Twilio sells communications features per call, and Stripe and OpenAI sell subscription tiers. Others open platforms to partners who build on top. One genetic-testing startup, for example, licensed its testing service to organisations such as National Geographic and Mayo Clinic, which could integrate it into their own products. The API economy refers to the way application programming interfaces (APIs) can positively affect a company's profitability, through both scale and new users.\n\nStrategic risks\n\nSeveral risks come with depending on another firm's API.\n\n- Single-provider dependence. A product built on one third-party interface inherits that provider's prices, uptime and roadmap. Migrating to a different provider takes engineering effort, which creates switching costs that can be hard to measure in advance.\n- Changes to terms. Providers may revise rate limits, pricing or permitted uses after developers have committed. In 2023, several large social platforms ended free API access or introduced paid tiers, and some third-party applications that relied on those free tiers stopped operating.\n- Strategic use of access. A provider that controls an interface can restrict or price it to favour its own products or to disadvantage rivals. Such conduct is a concern for competition-law and market-power, and it can reinforce a network effect already in place. This is treated further in the legal section.\n\nGateways and metering tools make these policies easier to enforce, which is why the same infrastructure that protects a service can also be used to shape who competes with whom."
    },
    {
      "heading": "Legal, intellectual property and competition issues",
      "text": "The longest-running legal fight over APIs is the litigation between Oracle and Google over Java. Oracle sued Google in 2010 seeking more than one billion dollars in damages, alleging that Android infringed its copyrights in the Java platform. A district judge, William Alsup, held in 2012 that the APIs were not copyrightable, but on May 9, 2014, the Federal Circuit reversed that ruling and found that the Java APIs are copyrightable, while leaving open a possible fair use defense. A second jury then found that Google's use of the declaring code was fair, but the Federal Circuit reversed again in 2018, holding that Google's use of Java's declaring code and the API SSO was not fair as a matter of law.\n\nIn 2021 the Supreme Court took a different path. By a vote of 6-2, the Supreme Court ruled for Google, relying on the fair use doctrine to conclude that Google's copying did not infringe Oracle's copyright in Java. The majority did not settle the threshold question. The majority declined to answer the first question it agreed to hear: whether the Java API's declaring code was copyrightable at all. Instead, the Court framed its decision on the assumption that the entire Java API is copyrightable. The copied material was small in absolute terms: the ruling concerned copying 11,500 lines of Oracle's Java SE API code, and the majority's reasoning centred on the purpose of the reuse, which was to let developers work with an existing programming interface on a new platform.\n\nStructure versus implementation\n\nThe case turned on a distinction between an API's declaring code, the names, signatures and organisation that callers must match, and its implementing code, the internal logic that performs the work. Google had written its own implementing code, which constituted the vast majority of its API. The Federal Circuit treated the declaring code and the structure, sequence and organization (SSO) of the packages as protectable expression, while the district court had treated those elements as unprotectable. Because the Supreme Court assumed protectability rather than ruling on it, the question remains open in US law. Other jurisdictions have taken different approaches. For example, the EU Software Directive excludes ideas and principles underlying a program's interfaces from protection and includes an exception for decompilation aimed at interoperability. The result is that a company may be uncertain whether reimplementing an interface is lawful until a court in a specific jurisdiction has ruled on the facts.\n\nInteroperability and regulation\n\nThe Supreme Court's reasoning placed weight on competition. The majority viewed a copyright owner as unable to use copyright to build artificial barriers that stop developers from moving to a new platform. This links copyright on interfaces to the broader problem of switching costs and network effects, which can entrench a dominant platform.\n\nRegulators have taken up this concern directly. The EU's Digital Markets Act requires designated gatekeepers to allow third parties access to the same OS hardware and software features that are available to services or hardware provided by the gatekeeper. A narrower provision applies to messaging: requiring designated gatekeepers to open up to smaller messaging platforms on request. The Commission justifies these duties by pointing to very strong network effects, large economies of scale, the ability to connect business users with many end users, the lock-in of end users, which together can undermine market contestability. Enforcement runs through specification proceedings in which the Commission identifies concrete measures a gatekeeper must take, and third parties may comment on draft measures.\n\nContractual controls and undocumented interfaces\n\nWhere copyright protection is uncertain, providers rely on contract and secrecy. Terms of use and licences can limit how third parties call an API, forbid certain uses, or restrict reverse engineering, and rate limits can be written into the same agreements. Undocumented or internal endpoints are often treated as trade secrets, which generally requires that the information be secret and that the owner take reasonable steps to keep it so. How far such contractual and trade secret claims can be enforced against outside developers varies by jurisdiction and depends heavily on the specific terms and the conduct involved. Consumers who depend on an endpoint that the provider never documented therefore face a risk that the interface can change or disappear without notice, which connects this legal question to the problem of undocumented behaviour discussed elsewhere in this entry."
    },
    {
      "heading": "Applications across domains",
      "text": "Mobile and web applications are among the most common consumers of APIs. An app typically combines its own back end with outside services over HTTP. A sign-in button may hand authentication to a third-party identity provider using OAuth 2.0 or OpenID Connect. A map may be drawn from a mapping provider's tile and geocoding endpoints, and a checkout form may be a payment provider's hosted widget that collects card details and returns a token to the merchant's server. In each case the application holds a key or access token scoped to a particular purpose, so the provider can meter usage and revoke access without changing the application's own code. These embedded services let small teams reuse infrastructure they could not build themselves, but they also tie the product to an external provider's uptime, pricing and terms. Authentication and authorization mechanisms for such flows are described in the security section and in the related sections of this article.\n\nIn cloud computing and software-as-a-service, APIs are the mechanism by which resources are created and managed. Virtual machines, storage buckets, networks, databases and load balancers are exposed as API operations, and the provider's web console is in effect one client of that interface. Infrastructure as code tools use these calls to make environments reproducible. One source describes the approach as writing a file that is both human-readable and machine-consumable, and another notes that the tools call provider APIs to bring resources to a declared state. Multi-cloud tools such as Terraform, Pulumi and Crossplane place a configuration layer over provider-specific APIs, so that one definition can target several platforms. SaaS vendors use the same pattern in the other direction, exposing data and administrative operations so that customers can synchronize accounts, records and billing with their own systems. Running this infrastructure depends on cloud platforms whose APIs are versioned and rate-limited like any other public interface.\n\nScientific and public-sector data access is another major use. Government agencies and research repositories often publish both bulk downloads and programmatic interfaces, partly to meet freedom-of-information requirements and partly to support reuse in research. A university library guide lists NASA's open data portal as offering over 31,000 datasets and about 30 APIs. The European Space Agency's Climate Change Initiative portal provides programmatic access through OpenSearch, OPeNDAP, WMS and other protocols. The U.S. National Center for Biotechnology Information offers its E-utilities as server-side programs for querying the Entrez system, and scholarly metadata services such as OpenAlex let researchers harvest citation and publication records at scale. Open-source portal software such as CKAN is designed around API-first catalog operations. Programmatic access makes studies repeatable, but it also raises questions about rate limits, dataset versioning and schema changes that can silently alter the results of a re-run analysis. This is related to data governance and to the wider movement toward large-scale data analysis.\n\nFinancial services show how APIs can be shaped by law. In the European Union, the revised Payment Services Directive (PSD2) requires banks to expose customer account data and payment initiation through standardized interfaces to licensed third parties, provided the customer consents. The United Kingdom and Australia have introduced comparable regimes. The regulation sets security requirements, including strong customer authentication, but leaves the technical design to standards bodies such as the Berlin Group's NextGenPSD2 framework and the UK's Open Banking standard. Consent is time-limited and must be renewed, and banks must verify in real time that a third party is authorized. These obligations have made open banking one of the clearest cases in which an API is a legal duty rather than a commercial choice, and the idea has been extended to insurance, investment and pensions under the label open finance.\n\nIn the Internet of Things and industrial automation, APIs must connect heterogeneous hardware with very different capabilities. Constrained sensors often use lightweight messaging protocols such as MQTT, while factory equipment from different vendors may expose data through OPC UA, a standard with an explicit information model. Device lifetimes are long and firmware is updated slowly, so interfaces must remain stable for years and tolerate older clients. Hard-coded credentials in embedded firmware and unauthenticated device endpoints are persistent security problems, which is why connected devices are often fronted by gateways that handle authentication, translation and data protection obligations on behalf of the hardware."
    },
    {
      "heading": "Relations to other fields and concepts",
      "text": "The idea of an API sits close to the core of software engineering, and its intellectual roots lie in modular programming. David Parnas's 1972 work on information hiding argued that a module should expose only what other modules need to know, and that its internal design decisions should stay hidden. This is the same principle that makes an interface worth specifying. Programming languages that support abstract data types make the idea explicit: the interface is the set of operations that may be applied to a value, and the representation is hidden. A stack, for instance, is defined by operations such as push, pop and peek, not by the data structure behind it. Object-oriented languages extended this by grouping data and operations into classes and by declaring interfaces or abstract classes that several implementations can satisfy. In that setting, the key test is substitutability: any implementation that honours the same interface and its documented behaviour should be usable in its place.\n\nService-oriented architecture, which became prominent in the late 1990s and 2000s, packaged business functions as services reachable over a network. Microservice architectures later divided a system into small, independently deployed services. In both designs, services communicate only through network interfaces. They do not share memory or class hierarchies and, ideally, do not share databases. The API is therefore the sole contract between components, often between different teams, and any change to it affects those teams directly. This isolation also brings costs that in-process calls do not have. A remote call can be slow, can fail partway through, and can be delivered more than once. These risks make timeouts, retries and idempotency, discussed elsewhere in this entry, central concerns rather than optional refinements.\n\nRemote interfaces are also where API design meets distributed computing. Assumptions about message ordering, failure detection and consistency must be stated in the contract, because a client that receives a timeout cannot otherwise reason about whether the operation happened. Formal methods provide ways to state such contracts precisely. Bertrand Meyer's design by contract, developed with the Eiffel language in the 1980s, attaches preconditions, postconditions and invariants to operations. Similar ideas appear in runtime assertion checking and in specification languages for existing languages such as the Java Modeling Language. Interface description languages play a lighter but more widespread role: the generated stubs they produce are type-checked against the specification, which is a modest form of verification. At larger scale, engineers at Amazon Web Services have described using the TLA+ specification language to model distributed protocols before implementing them, which shows how an intended API behaviour can be examined formally before any code exists.\n\nFinally, APIs are a case of human–computer interaction, because developers are users whose difficulties can be observed and measured. Researchers such as Brad Myers and Jeffrey Stylos have argued that API usability should be evaluated like any other user interface, through observation of programmers, think-aloud sessions and controlled comparisons of alternative designs. Such studies have repeatedly found that naming, the discoverability of operations, the clarity of error messages and the availability of worked examples strongly influence how quickly developers become productive. Frameworks from cognitive psychology and notation design, such as the cognitive dimensions of notations, have also been applied to API design. The result is that the usability of an interface is treated as an empirical property, not merely a matter of taste, and it links API work to the wider computer science discipline of studying how people reason about formal systems."
    },
    {
      "heading": "Open problems and future directions",
      "text": "Syntactic compatibility does not guarantee that two systems understand each other. Two APIs can agree on endpoints, field names and JSON types and still disagree about what a value means: whether an amount is in cents or dollars, whether a timestamp is local or UTC, or what the status \"inactive\" implies. Semantic interoperability is therefore concerned not just with the packaging of data (syntax), but the simultaneous transmission of the meaning with the data (semantics). Shared schemas settle the packaging. Meaning needs a further layer, typically controlled vocabularies or ontologies, that ties each field to an agreed concept. This is accomplished by adding data about the data (metadata), linking each data element to a controlled, shared vocabulary. In practice, such vocabularies are costly to agree on and maintain, which is why semantic interoperability remains harder than the machine-readable specifications described elsewhere in this entry.\n\nA second problem is scale. Microservice and cloud-native architectures have multiplied interfaces faster than organizations can track them. Microservices and cloud-native architectures led to a massive, largely uncontrolled increase in APIs. Estimates of how many APIs a large firm runs vary widely, and many come from vendors with an interest in the answer. One gateway vendor reports that the average enterprise now manages over 354 APIs across its infrastructure, while another puts large enterprises at 10,000+ APIs, many of them redundant or poorly governed. The common pattern is the loss of visibility. Undocumented or undocumented (shadow) endpoints sit outside inventories, and this has consequences for compliance: APIs that process personal data may fall outside audits such as GDPR or HIPAA reviews if they are never catalogued. Governance tools (catalogues, gateways, lifecycle policies) are the usual response, and their adoption is tied to broader data governance and cybersecurity programmes.\n\nThe most visible new development is the use of APIs as tools for AI agents. Large language models are isolated from real-world data and systems unless they can call external functions. Before standardization, each model vendor offered its own tool-calling format, and integrations had to be rebuilt for each pairing. The Model Context Protocol (MCP), open-sourced in November 2024 by Anthropic and now governed under the Linux Foundation's Agentic AI Foundation, addresses this by defining one client–server protocol for tools, resources and prompts. Its wire format is JSON-RPC 2.0, and each tool declares a name, a description and a JSON Schema for its inputs. The specification also recommends that a human be kept in the loop through confirmation prompts before operations run. The protocol is still changing: the revision dated 2026-07-28 introduced a stateless core and HTTP headers that let gateways route and authorize requests without parsing bodies. Agent-driven traffic also complicates operations, since it can produce non-deterministic request patterns that rate limits and capacity planning were not designed for. Tool descriptions written in natural language now function as part of the contract, which raises open questions about testing and about how models interpret ambiguous descriptions.\n\nSeveral questions remain unresolved. Security at scale is one: an organization with thousands of interfaces, some of them unknown, has difficulty ensuring consistent authentication, quotas and monitoring across all of them. The economics of free public access are another. Providers that offer open data or free tiers must decide how to fund bandwidth and maintenance, and the terms they set can change without notice. Long-term preservation is the third. Consumers may depend on an interface longer than its provider keeps operating it, and once a service is withdrawn, the software that relies on it may stop working unless the protocol is documented openly or reimplemented. Whether standards such as MCP, or the open-source reimplementation of older services, can preserve interfaces beyond their original owners remains an open question."
    }
  ],
  "links": [
    "operating-system",
    "world-wide-web",
    "cloud-computing",
    "software-documentation",
    "internet",
    "e-commerce",
    "programming-language",
    "distributed-computing",
    "data-compression",
    "floating-point-arithmetic",
    "unicode",
    "cryptography",
    "cybersecurity",
    "competition-law",
    "market-power",
    "network-effect",
    "legislation",
    "infrastructure",
    "data-governance",
    "big-data",
    "data-privacy",
    "data-structure",
    "formal-verification",
    "computer-science",
    "large-language-model"
  ],
  "sources": [
    {
      "title": "The Preparation of Programs for an Electronic Digital Computer",
      "url": "https://en.wikipedia.org/wiki/The_Preparation_of_Programs_for_an_Electronic_Digital_Computer"
    },
    {
      "title": "API",
      "url": "https://en.wikipedia.org/wiki/API"
    },
    {
      "title": "The Evolution of APIs: From RPC to SOAP and XML (Part 1)",
      "url": "https://konghq.com/blog/enterprise/evolution-apis-rpc-soap-xml"
    },
    {
      "title": "Posix Standard",
      "url": "https://linuxhint.com/posix-standard/"
    },
    {
      "title": "API",
      "url": "https://encyclopedia.thefreedictionary.com/API"
    },
    {
      "title": "POSIX Portable Operating System Interface for uniX",
      "url": "https://www.telecomtrainer.com/posix-portable-operating-system-interface-for-unix/"
    },
    {
      "title": "What Is POSIX (Portable Operating System Interface)?",
      "url": "https://phoenixnap.com/glossary/posix/"
    },
    {
      "title": "The hunt for POSIX.1-1988",
      "url": "https://luplab.cs.ucdavis.edu/2021/11/04/the-hunt-for-posix-1-1988.html"
    },
    {
      "title": "A Guide to POSIX",
      "url": "https://www.baeldung.com/linux/posix"
    },
    {
      "title": "Object-oriented programming: some history, and challenges for the next fifty years",
      "url": "https://arxiv.org/pdf/1303.0427"
    },
    {
      "title": "Tracing the History of APIs: From Mainframes to the Cloud",
      "url": "https://www.sensedia.com/pillar/history-of-apis"
    },
    {
      "title": "The History and Evolution of APIs",
      "url": "https://traefik.io/blog/the-history-and-evolution-of-apis"
    },
    {
      "title": "The Enviable Pedigree of UNIX® and POSIX® - The Open Group Blog",
      "url": "https://blog.opengroup.org/2016/08/17/the-enviable-pedigree-of-unix-and-posix/"
    },
    {
      "title": "Types of APIs",
      "url": "https://blog.axway.com/learning-center/apis/basics/different-types-apis"
    },
    {
      "title": "Public, Private, Partner, and Internal APIs",
      "url": "https://algomaster.io/learn/api-design/public-private-partner-and-internal-apis"
    },
    {
      "title": "What Are the Types of APIs and Their Differences?",
      "url": "https://www.techtarget.com/searchapparchitecture/tip/What-are-the-types-of-APIs-and-their-differences"
    },
    {
      "title": "Types of APIs & Popular REST API Protocol - Blog",
      "url": "https://blog.dreamfactory.com/types-of-apis-popular-rest-api-protocol"
    },
    {
      "title": "Framework vs Library - Key Differences Explained 2026",
      "url": "https://www.sencha.com/blog/difference-between-framework-vs-library-snc/"
    },
    {
      "title": "The Difference Between a Framework and a Library",
      "url": "https://www.freecodecamp.org/news/the-difference-between-a-framework-and-a-library-bd133054023f/"
    },
    {
      "title": "Libraries vs frameworks: key differences and how to choose",
      "url": "https://hackmamba.io/engineering/libraries-vs-frameworks-which-is-right-for-your-next-web-project/"
    },
    {
      "title": "What is OpenAPI? A Guide to the OpenAPI Specification",
      "url": "https://scalar.com/learn/openapi/what-is-openapi"
    },
    {
      "title": "OpenAPI Support",
      "url": "https://docs.readme.com/main/docs/openapi"
    },
    {
      "title": "What is OpenAPI Specification? A Complete Guide for Developers.",
      "url": "https://www.digitalapi.ai/blogs/what-is-openapi-specification-a-complete-guide-for-developers"
    },
    {
      "title": "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language",
      "url": "https://www.w3.org/TR/2007/REC-wsdl20-20070626/"
    },
    {
      "title": "Web Services Description Language",
      "url": "https://en.wikipedia.org/wiki/Web_Services_Description_Language"
    },
    {
      "title": "Language Guide (editions)",
      "url": "https://protobuf.dev/programming-guides/editions/"
    },
    {
      "title": "Protocol Buffers Language Specification (Proto3)",
      "url": "https://protobuf.dev/reference/protobuf/proto3-spec/"
    },
    {
      "title": "Proto3 language guide - Protocol Buffers",
      "url": "https://protocolbuffers-protobuf-45.mintlify.app/concepts/proto3"
    },
    {
      "title": "Cheatsheet - Protocol Buffers (Protobuf)",
      "url": "https://www.hackingnote.com/en/cheatsheets/protobuf/"
    },
    {
      "title": "HTTP Status Codes explained",
      "url": "https://http.dev/status"
    },
    {
      "title": "What are HTTP status codes? Complete Guide for API Developers",
      "url": "https://blog.postman.com/what-are-http-status-codes/"
    },
    {
      "title": "HTTP Status Codes Cheat Sheet — 1xx to 5xx",
      "url": "https://www.devtools.tools/cheatsheets/http-status"
    },
    {
      "title": "Cursor vs Offset Pagination: A Practical Guide — CODERCOPS",
      "url": "https://blog.codercops.com/blog/cursor-vs-offset-pagination-guide-2026"
    },
    {
      "title": "Idempotency Keys for APIs: Safe Retries, Explained",
      "url": "https://myappapi.com/blog/idempotency-keys-for-apis"
    },
    {
      "title": "Response Codes and Retry Logic",
      "url": "https://postgrid.readme.io/docs/response-codes-and-retry-logic"
    },
    {
      "title": "Idempotency & Request Retries",
      "url": "https://apiguide.dev/guides/idempotency/"
    },
    {
      "title": "The Idempotency Pattern: Making Retries Safe in Distributed Systems - DEV Community",
      "url": "https://dev.to/ankitdevcode/the-idempotency-pattern-making-retries-safe-in-distributed-systems-hn8"
    },
    {
      "title": "Understanding HTTP Status Codes: A Complete Developer Guide",
      "url": "https://mojoauth.com/blog/understanding-http-status-codes-a-complete-developer-guide"
    },
    {
      "title": "Stop Retrying Immediately. Exponential Backoff Fixes It. - DEV Community",
      "url": "https://dev.to/parsajiravand/stop-retrying-immediately-exponential-backoff-fixes-it-1hce"
    },
    {
      "title": "Pagination Patterns: Cursor vs Offset and Why It Matters",
      "url": "https://yashveerlabs.vercel.app/blog/pagination-patterns-cursor-vs-offset-and-why-it-matters"
    },
    {
      "title": "OAuth 2.0 RFC 6749: the delegated authorisation standard",
      "url": "https://www.noze.it/en/insights/oauth-2-0-rfc-6749/"
    },
    {
      "title": "Demystifying RFC 6749: OAuth 2.0 Authorization Framework for the Technically Astute",
      "url": "https://www.zerosday.com/post/others/demystifying-rfc-6749-oauth-2-0-authorization-framework-for-the-technically-astute"
    },
    {
      "title": "JSON Web Token Introduction - jwt.io",
      "url": "https://www.jwt.io/introduction"
    },
    {
      "title": "RFC 7519: JSON Web Token (JWT)",
      "url": "https://www.rfc-editor.org/info/rfc7519/"
    },
    {
      "title": "OWASP API Security Top 10 Vulnerabilities: 2023 - API Security News",
      "url": "https://apisecurity.io/owasp-api-security-top-10/"
    },
    {
      "title": "OWASP API Security: Top 10 Security Risks & Remedies for 2026",
      "url": "https://blog.axway.com/learning-center/digital-security/risk-management/owasps-api-security"
    },
    {
      "title": "OWASP Top 10 API Security Risks",
      "url": "https://owasp.org/API-Security/editions/2023/en/0x11-t10/"
    },
    {
      "title": "Protect against OWASP API security Top 10 Vulnerabilities",
      "url": "https://42crunch.com/owasp-api-security-top-10/"
    },
    {
      "title": "Technical Deconstruction of MCP Authorization: A Deep Dive into OAuth 2.1 and IETF RFC Specifications",
      "url": "https://kane.mx/posts/2025/mcp-authorization-oauth-rfc-deep-dive/"
    },
    {
      "title": "OWASP API Top 10: How to Secure Your APIs, Complete Guide",
      "url": "https://www.pynt.io/learning-hub/owasp-top-10-guide/owasp-api-top-10"
    },
    {
      "title": "Semantic Versioning 2.0.0",
      "url": "https://semver.org/"
    },
    {
      "title": "RFC 8594: The Sunset HTTP Header Field",
      "url": "https://www.rfc-editor.org/rfc/rfc8594.html"
    },
    {
      "title": "Sunset Header — API Provider, Schemas",
      "url": "https://apis.io/providers/sunset-header/"
    },
    {
      "title": "Hyrum's Law",
      "url": "https://lawsofsoftwareengineering.com/laws/hyrums-law/"
    },
    {
      "title": "Hyrum's Law: API Compatibility and Hidden Dependencies — Urhoba",
      "url": "https://www.urhoba.net/en/post/hyrums-law"
    },
    {
      "title": "Semantic Versioning (SemVer) - Glossary",
      "url": "https://ethora.com/glossary/semantic-versioning/"
    },
    {
      "title": "Characteristics of Good APIs - DaedTech",
      "url": "https://daedtech.com/characteristics-good-apis/"
    },
    {
      "title": "Principle of least astonishment",
      "url": "https://en.wikipedia.org/wiki/Principle_of_least_astonishment"
    },
    {
      "title": "Principle of Least Astonishment",
      "url": "https://lawsofsoftwareengineering.com/laws/principle-of-least-astonishment/"
    },
    {
      "title": "APIs and the Principle of Least Surprise - DaedTech",
      "url": "https://daedtech.com/apis-principle-least-surprise/"
    },
    {
      "title": "Enforcing API consistency - Speakeasy",
      "url": "https://www.speakeasy.com/blog/enforcing-api-consistency"
    },
    {
      "title": "API-First Approach: What It Is and How to Adopt It",
      "url": "https://www.moesif.com/blog/technical/api-development/Embracing-the-Future-How-the-API-First-Approach-is-Revolutionizing-Software-Development/"
    },
    {
      "title": "A Guide to API-First Design Principles and Practices",
      "url": "https://requestly.com/blog/api-first/"
    },
    {
      "title": "Microservice API Evolution in Practice: A Study on Strategies and Challenges",
      "url": "https://arxiv.org/pdf/2311.08175"
    },
    {
      "title": "API-first vs Code-first: Choosing the Right Approach for Your Project",
      "url": "https://medium.com/@tiokachiu/api-first-vs-code-first-choosing-the-right-approach-for-your-project-868443e73052"
    },
    {
      "title": "Mastering REST APIs: HATEOAS (Hypermedia as the Engine of Application State)",
      "url": "https://medium.com/@bvsahane89/mastering-rest-apis-hateoas-hypermedia-as-the-engine-of-application-state-b4a4d598fb01"
    },
    {
      "title": "RESTful or RESTless -- Current State of Today's Top Web APIs",
      "url": "https://arxiv.org/pdf/1902.10514"
    },
    {
      "title": "Application of HATEOAS Principle in RESTful API Design",
      "url": "https://ieeexplore.ieee.org/document/10029427/"
    },
    {
      "title": "Why API first approach matters and what it means for development in 2026",
      "url": "https://buildwithfern.com/post/what-is-api-first-approach"
    },
    {
      "title": "Core API Quick Start",
      "url": "https://www.marqeta.com/docs/developer-guides/core-api-quick-start"
    },
    {
      "title": "The Most Effective API Quick Start Guides, in 7 Examples - ReadMe: Resource Library",
      "url": "https://blog.readme.com/the-most-effective-api-quickstarts-in-8-examples"
    },
    {
      "title": "How to Design a Quick Start Guide for Your API",
      "url": "https://www.apimatic.io/blog/how-to-design-a-quick-start-guide-for-your-api"
    },
    {
      "title": "Quick start guide",
      "url": "https://developers.asana.com/docs/quick-start"
    },
    {
      "title": "Documentation/API documentation - MediaWiki",
      "url": "https://www.mediawiki.org/wiki/Documentation/API_documentation"
    },
    {
      "title": "GitHub - OpenAPITools/openapi-generator: OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3) · GitHub",
      "url": "https://github.com/openapitools/openapi-generator"
    },
    {
      "title": "10+ Tools To Automatically Generate SDKs for Your API",
      "url": "https://nordicapis.com/10-tools-to-automatically-generate-sdks-for-your-api/"
    },
    {
      "title": "How to Document REST APIs with OpenAPI",
      "url": "https://oneuptime.com/blog/post/2026-01-26-openapi-rest-documentation/view"
    },
    {
      "title": "7 SDK Generator Tools for APIs in 2025",
      "url": "https://medium.com/@atejada/7-sdk-generator-tools-for-apis-in-2025-824f86d4dfc0"
    },
    {
      "title": "GitHub - pact-foundation/pact-net: .NET version of Pact. Enables consumer driven contract testing, providing a mock service and DSL for the consumer project, and interaction playback and verification for the service provider project. · GitHub",
      "url": "https://github.com/pact-foundation/pact-net"
    },
    {
      "title": "Stop Breaking My API: A Practical Guide to Contract Testing with Pact",
      "url": "https://medium.com/@mohsenny/stop-breaking-my-api-a-practical-guide-to-contract-testing-with-pact-33858d113386"
    },
    {
      "title": "API Contract Testing",
      "url": "https://stevekinney.com/courses/enterprise-ui/api-contract-testing"
    },
    {
      "title": "API Contract Testing with Pact — Consumer-Driven Contracts for Microservices",
      "url": "https://codelit.io/blog/api-contract-testing-pact"
    },
    {
      "title": "Circuit Breaker Pattern in Microservices - by Scortier",
      "url": "https://grindengineer.substack.com/p/circuit-breaker-pattern-in-microservices"
    },
    {
      "title": "Circuit Breaker Pattern — Build Resilient Microservices - DevKits - DEV Community",
      "url": "https://dev.to/hezeclark/circuit-breaker-pattern-build-resilient-microservices-devkits-2fd6"
    },
    {
      "title": "Bulkhead pattern",
      "url": "https://en.wikipedia.org/wiki/Bulkhead_pattern"
    },
    {
      "title": "Circuit Breaker Pattern Explained: The Complete Guide - Ajit Singh",
      "url": "https://singhajit.com/circuit-breaker-pattern/"
    },
    {
      "title": "Best API Gateways in 2026: A Developer's Guide to Choosing - Zuplo",
      "url": "https://zuplo.com/learning-center/best-api-gateways-2026"
    },
    {
      "title": "What Is an API Gateway? - Palo Alto Networks",
      "url": "https://www.paloaltonetworks.com/cyberpedia/what-is-api-gateway"
    },
    {
      "title": "What Is an API Gateway? How It Works, Benefits & Use Cases",
      "url": "https://konghq.com/blog/learning-center/what-is-an-api-gateway"
    },
    {
      "title": "API Monetization Strategy: Models & Azure Setup",
      "url": "https://www.technetmagazine.com/api-monetization-strategy/"
    },
    {
      "title": "API Monetization: Models, Strategies, and What Actually Works",
      "url": "https://treblle.com/blog/api-monetization-models-strategies-and-what-actually-works"
    },
    {
      "title": "Unlocking API Revenue: Monetization Strategies for Product and Project Managers",
      "url": "https://www.theneo.io/blog/api-monetization-strategies"
    },
    {
      "title": "API Monetization: Models, Strategies & Implementation Guide",
      "url": "https://apisix.apache.org/learning-center/api-monetization-guide/"
    },
    {
      "title": "API Monetization Platforms Compared (2026): Metering, Billing - Zuplo",
      "url": "https://zuplo.com/learning-center/api-monetization-platform-comparison"
    },
    {
      "title": "API Economy — Definition & Meaning",
      "url": "https://opag.io/intangibles/glossary/api-economy"
    },
    {
      "title": "What Is The “API Economy” And How Brands Can Benefit From It",
      "url": "https://medium.com/ipg-media-lab/what-is-the-api-economy-and-how-brands-can-benefit-from-it-b46210d0434d"
    },
    {
      "title": "API Gateway Architecture: Rate Limiting, Authentication and Traffic Management Patterns for Scale",
      "url": "https://www.askantech.com/api-gateway-patterns-rate-limiting-authentication-traffic-management-scale/"
    },
    {
      "title": "API Monetization Models and Strategies that Work",
      "url": "https://blog.axway.com/learning-center/apis/enterprise-api-strategy/api-monetization-models"
    },
    {
      "title": "The 5 API monetization models (and which fits your AI product)",
      "url": "https://credyt.ai/blog/5-api-monetization-models"
    },
    {
      "title": "What is API Economy",
      "url": "https://tektelic.com/what-it-is/api-economy/"
    },
    {
      "title": "Supreme Court Declines Ruling in Oracle v. Google Copyright Case - SGR Law",
      "url": "https://www.sgrlaw.com/supreme-court-declines-ruling-in-oracle-v-google-copyright-case/"
    },
    {
      "title": "Oracle v. Google",
      "url": "https://www.eff.org/cases/oracle-v-google"
    },
    {
      "title": "Google v. Oracle: Supreme Court Rules for Google in Landmark Software Copyright Case",
      "url": "https://www.congress.gov/crs-product/LSB10597"
    },
    {
      "title": "SCOTUS Says 'Fair Use' in Google v. Oracle Copyright Battle",
      "url": "https://www.mcdermottlaw.com/insights/scotus-says-fair-use-in-google-v-oracle-copyright-battle/"
    },
    {
      "title": "News & Analysis as of",
      "url": "https://www.jdsupra.com/topics/google/fair-use"
    },
    {
      "title": "Google LLC v. Oracle America, Inc.",
      "url": "https://supreme.justia.com/cases/federal/us/593/18-956/"
    },
    {
      "title": "Planet of the APIs: U.S. Supreme Court Rules Google’s Use of Java APIs in Android Is Fair Use",
      "url": "https://www.airdberlis.com/insights/blogs/thespotlight/post/ts-item/planet-of-the-apis-u.s.-supreme-court-rules-google-s-use-of-java-apis-in-android-is-fair-use"
    },
    {
      "title": "Interoperability - Digital Markets Act (DMA) - European Commission",
      "url": "https://digital-markets-act.ec.europa.eu/developer-portal/interoperability_en"
    },
    {
      "title": "Interoperability, Privacy, and the Limits of the Digital Markets Act",
      "url": "https://privacyinternational.org/long-read/5862/interoperability-privacy-and-limits-digital-markets-act"
    },
    {
      "title": "Oracle Am., Inc. v. Google Inc., No. 13-1021 (Fed. Cir. 2014) :: Justia",
      "url": "https://law.justia.com/cases/federal/appellate-courts/cafc/13-1021/13-1021-2014-05-09.html"
    },
    {
      "title": "Implications Around PSD2 and Open Banking",
      "url": "https://www.okta.com/resources/whitepapers/implications-around-psd2-and-open-banking/"
    },
    {
      "title": "What are open banking APIs? Complete guide to specifications and standards",
      "url": "https://tyk.io/learning-center/open-banking-apis-explained/"
    },
    {
      "title": "Open Banking APIs Explained: What PSD2 Compliance Actually Requires From Your Engineering Team - DEV Community",
      "url": "https://dev.to/lycore/open-banking-apis-explained-what-psd2-compliance-actually-requires-from-your-engineering-team-4l2o"
    },
    {
      "title": "PSD2 Regulation: Definition, Key Features and Compliance",
      "url": "https://qwist.com/en/resources/wiki/what-is-psd2/"
    },
    {
      "title": "Open finance",
      "url": "https://en.wikipedia.org/wiki/Open_finance"
    },
    {
      "title": "APIs - Scholarly Resources - Data & Statistics Sources - LibGuides at University of California San Diego",
      "url": "https://ucsd.libguides.com/data-statistics/apis"
    },
    {
      "title": "The ESA Climate Change Initiative Open Data Portal",
      "url": "https://climate.esa.int/en/data/"
    },
    {
      "title": "List of APIs - Text and Data Mining (TDM) at University of Toronto - Research Guides at University of Toronto",
      "url": "https://guides.library.utoronto.ca/c.php?g=744383&p=5387165"
    },
    {
      "title": "Research Paper APIs for Scientific Literature in 2026",
      "url": "https://intuitionlabs.ai/articles/research-paper-apis-scientific-literature"
    },
    {
      "title": "Socrata Developers",
      "url": "https://dev.socrata.com/"
    },
    {
      "title": "What is Cloud Provisioning? Process, Types & Best Practices",
      "url": "https://spacelift.io/blog/cloud-provisioning"
    },
    {
      "title": "Semantic interoperability",
      "url": "https://en.wikipedia.org/wiki/Semantic_interoperability"
    },
    {
      "title": "API governance: Where Equixly delivers value and why it matters now",
      "url": "https://equixly.com/blog/2025/12/30/equixly-api-governance/"
    },
    {
      "title": "API Sprawl in 2026: Why 354+ APIs Per Enterprise Breaks Traditional Gateways - Zuplo",
      "url": "https://zuplo.com/learning-center/api-sprawl-edge-native-gateways-scale"
    },
    {
      "title": "API Sprawl Leads to API Chaos: Regain Control of Your Enterprise - digitalML",
      "url": "https://www.digitalml.com/api-sprawl-leads-to-api-chaos/"
    },
    {
      "title": "What Is the Model Context Protocol (MCP) and How It Works",
      "url": "https://www.descope.com/learn/post/mcp"
    },
    {
      "title": "Model Context Protocol",
      "url": "https://en.wikipedia.org/wiki/Model_Context_Protocol"
    },
    {
      "title": "The 2026-07-28 Specification",
      "url": "https://blog.modelcontextprotocol.io/posts/2026-07-28/"
    },
    {
      "title": "Tools - Model Context Protocol",
      "url": "https://modelcontextprotocol.io/specification/2025-06-18/server/tools"
    },
    {
      "title": "Managing API Sprawl: The Growing Risk Of Shadow APIs & How To Mitigate It",
      "url": "https://www.cybersecurityintelligence.com/blog/managing-api-sprawl-the-growing-risk-of-shadow-apis-and-how-to-mitigate-it-8068.html"
    }
  ],
  "license": "https://creativecommons.org/licenses/by/4.0/"
}