What Is an API (Application Programming Interface)?

Application programming interfaces (APIs) are standardized methods for one software program to get information and services from another software program. They are a simple idea that has led to enormous economic benefits for businesses of all sizes and the global economy itself. By dividing up the work required to build an application, hiding complexity, enabling smooth and predictable integration among fast-evolving technologies and commodifying digital services to make them plug-and-play, APIs have become critical accelerators of business technology innovation.

What Is an API?

APIs are effectively software toolkits that let applications communicate with one another to exchange data based on service requests. They act as bridges between software programs, providing gateways to powerful functionality that is created, secured and maintained by software developers. For example, developers of an online store don’t need to understand all the complex security, legal and privacy concerns around credit card payment processing. Instead, they can use an API to connect their store application to a reliable payment processing service, then focus on perfecting the shopping experience that will attract and retain customers.

To do this, APIs abstract and standardize communication between applications, letting applications evolve independently and quickly without breaking their connections to one another. In this sense, APIs are a kind of contract — between service providers and consumers of those services — to provide specific functionality dependably, in a standardized and well-documented way. As long as an API’s structure and behavior don’t change, the underlying software can change frequently, such as fixing bugs and adding new features. Modern AP architectures like REST can also be extended to access new features without breaking existing integrations.

APIs allow programming teams to focus on what’s most important to them, while leaving other technical puzzles and challenges for other specialized teams and organizations to solve and manage.

APIs drive business innovation by providing customers with choice and keeping service markets competitive and affordable. Using APIs lets programmers simplify and isolate parts of their programs that invoke specialized functionality. If the owners of our online store want to change from one payment processor to another, it’s a simple matter of changing out the API-based interface to the new provider.

APIs Integrate Apps With Standardized Communication

Key Takeaways

• APIs package specialized functionality to make software accessible to developers of another application.
• Leveraging external services via APIs helps developers focus on what’s most important to their business, so they can write simpler, more compact, more secure and more scalable applications.
• Internet APIs facilitate software-as-a-service (SaaS) marketplaces, helping to drive online innovation.
• Many modern businesses — e.g., insurance underwriters, banks, credit card providers, logistics and transportation companies — provide APIs to integrate and simplify use of their services by customers, resellers and partners.
• Most of today’s best-known online services provide public APIs that let other applications leverage their features at low or no cost. Examples include maps, translations and social media sites.
• APIs represent a kind of contract that software offers to its users: As long as the API’s structure and behavior doesn’t change, users can invoke the software’s functionality reliably, while underlying applications can improve.

APIs Explained

You can think of an API as a kind of user interface — not the kind with windows, buttons and widgets that makes software accessible to everyone, but one that makes program features and stored data accessible to other software code. APIs fall into four overlapping categories:

• Local APIs: These APIs connect units of code running inside a single computer. The math and analytics libraries NumPy and Pandas, for example, run on the same computer and within the same Python language environment as the application code that calls them. Both the application and the libraries are written in Python.

• Remote APIs: These use local-area networks or the internet to connect software running on different computers. In this case, the application that requests services and the application providing them may be written in different languages and likely run on very different kinds of hardware and platforms.

• Synchronous (or “blocking”) APIs: Synchronous APIs accept requests and force calling applications to wait until results are assembled and returned. This can become a bottleneck and is only used in situations where resource contention and latency are unlikely. Local APIs that work with libraries extending a programming language’s math features are a good example.

• Asynchronous APIs: These let calling programs continue running (perhaps doing other work), then “call back” to the calling program when results are ready. This design makes calling programs a little more complex but handles resource contention and variable latency gracefully. This is important for APIs that may be called on by many client apps simultaneously.

How Do APIs Work?

In a general sense, all APIs follow a similar pattern comprised of these three steps: authentication and access, request and response. Secure access becomes more important the more open an API is and the more sensitive its function. The Google Maps API, for example, is very public, and the services it performs are not generally considered secure. APIs associated with payment processors on the other hand handle confidential information, so security is critical.

API Use Step 1: Authentication and Access

APIs for critical shared services, such as a business’s databases, or for commercial services like credit card payment processors, need to protect themselves against unauthorized use. Likewise, applications that depend on services delivered via APIs need to ensure they’re calling the right service — not an impostor — and need to prevent unauthorized access to the API in their names, for example, by a third party pretending to be them or by someone eavesdropping on the user-to-API communication stream.

The first interaction between a calling application and a called service thus often involves authentication and access control, where:

1. The called service asserts its identity (e.g., “Yes, I am really the Stripe payments API”), and

2. The calling application provides identifying information, plus a secret (like a password) proving it is legitimate. The called service authenticates the caller and may use its identity to impose restrictions. For example, an online store application may be permitted to process payments but will not be permitted to use the API to access and change high-level customer account details — a permission reserved for human administrators.

Depending on the API’s design, a calling application may need to repeat this login process each time it calls the service. This is more typical of private APIs that are called less frequently. More often than not, the API will return a temporary code or token — a unique symbol that the calling application can use to identify itself for some period of time — to speed processing of multiple API requests.

In modern remote API transactions carried out via web protocols such as HTTP, the login and subsequent exchanges are encrypted, with authentication provided using certificates, much like when a person manually logs into a suitably configured secure website using a browser.

API Use Step 2: Request

The calling application then frames a request for services and/or data in a way acceptable to the API. A typical request includes a request verb or equivalent symbol identifying the operation to be performed (e.g., “create and process a new credit card transaction record”) plus the data (parameters) required to do the requested job. In the case of a credit card transaction, parameters might include the card number, associated name, expiration date, CCV code, amount of payment, a date/timestamp, plus a transaction code the calling application can use to match the processed transaction with its own internal records.

API Use Step 3: Response

The called service then returns a response in a standard format defined by the API such as JSON or XML, making it easy for the calling application to determine next steps. Responses may include error codes of various kinds indicating different problems, including:

• Service errors: The called service may be temporarily unavailable, in which case the calling application will need to determine whether and how to inform its users and when it may be safe to try the request again.

• Not found errors: The calling service may have requested access to nonexistent functionality.

• Permission errors: The calling service may have requested functionality it’s not permitted to access.

• Parameter errors: The calling service may have failed to provide all required parameters or may have presented parameters in a form the API does not recognize or is not permitted to process (e.g., credit card transactions cannot have future dates).

• Transaction-specific errors: The requested transaction may exceed the shopper’s available credit card balance and is refused.

If no errors are encountered, the API will typically return a success code along with supporting information. A successful credit card swipe, for example, might return a unique code, generated by the payment processor, enabling later lookup, audit and confirmation that the request was received, and payment processed. This important code would typically be logged and stored in a database by the calling application as part of its record of the transaction.

Benefits of APIs

Now that you have a better understanding of how APIs work, their benefits should make more sense. And it should become clear how the following major benefits of APIs have become foundational pillars for the broader internet economy.

• Division of labor: APIs let programmers, teams and organizations build software to solve problems specific to their businesses without needing to know everything involved in the underlying system that supports the API. A team building a travel site can, for example, use the Google Translate API to translate pages of information into any of a range of languages, without needing to understand the specifics of how computers are programmed and trained to translate between human languages. Similarly, Google Translate’s computational linguists, machine-learning scientists and other specialists can tackle the challenges of providing reliable translations at scale, adding new languages, improving performance, and eliminating errors, while using their APIs to present a very simple interface to millions of organizations and consumers.

• Far faster app development: The decoupling, abstraction and dependency management that APIs provide becomes a contract between calling applications and called services. If documented functions remain unchanged, existing integrations will work, independent of changes made to the applications on either side. Plus, new API functions can be added without causing disruption. This ability of APIs to decouple and abstract units of software from one another is hugely important to today’s software industry and API economy. Decoupling helps coders create new applications much faster. It enables the vast enterprise of “open source,” where teams voluntarily collaborate to create free software, available for use and modification by anyone, and then evolve this software rapidly. APIs enable the “mashup” economy of the web, where simple applications can leverage the power of enormous and complicated systems e.g., Google Maps to deliver value in innovative ways.

• Application interchangeability: APIs are also important in preventing software “lock-in,” which happens when the sunk investment of integrating with a particular service or component is so great that it makes switching seem cost-prohibitive. As time goes by, APIs within specific application categories (e.g., payments, mapping, etc.) tend to broadly standardize, meaning that application makers can more easily switch components or providers to take advantage of lower per-transaction costs, better features, or improved performance.

Who Creates APIs?

Anyone who makes software and wants their software’s functionality to be consumable has incentive to create an API. That includes the world’s largest technology organizations that want to make API-driven services available to global users and customers. But it also includes makers of open-source and proprietary software and firmware that are much narrower in scope, including most of the software kit-of-parts (e.g., databases, load balancers, message brokers, email senders, proxies, web servers, etc.) used in business today, as well as custom software written by organizations for their own use.

The prevalence of APIs has changed the nature of business software. A few decades ago, solutions tended to be monolithic. Today, software vendors focus on building differentiating functionality and integrating complete systems by leveraging APIs to combine their benefits with API-equipped open-source components, often giving customers great freedom in selecting the latter.

APIs also figure prominently in the trend toward automation and self-service. Before APIs were prevalent, well-documented and standardized, it was difficult to create software able to interact with other software. IT teams were overburdened with resource, access and repair requests, all of which required error-prone, manual work. Today, APIs make it much easier to write code to deploy, configure and operate numerous software-based systems and platforms, reducing IT workloads, speeding tasks and avoiding mistakes.

Types of APIs

An important way to group APIs is by the types of people or organizations who use them. The creator of an API establishes its release policy, which usually falls into one of three broad categories: private, for use inside an organization; partner, for use by the organization and its business partners; and public/external, generally available to anyone.

Private APIs

Private APIs are typically created and/or used within organizations to integrate applications and components and provide access to critical local shared services such as corporate databases, directory servers, and email servers. These APIs are called “private” only because they’re intended for use within a single organization. In almost all cases, such APIs will — or should — require authentication and use encrypted connections.

Partner APIs

Partner APIs are created and made securely available by vendors for select business partners and end users. Applications in this category include supply chain integration and point-of-sale terminal integration.

Public APIs

Public, or external, APIs are presented by organizations that want to offer API-mediated services to large groups of users or customers. This includes cloud services, such as those provided by Oracle Cloud Infrastructure, as well as broad-based services like weather apps, web search, Google Translate and others. In many cases, public APIs are strongly secured against unauthorized use. In other cases, APIs may be open to general access by anyone.

In general, the more public an API is, the more security it requires against attacks. APIs accessible on the public internet are carefully monitored by machines and people. They’re often programmed to be rate-limited, which prevents any user or endpoint device (IP address) from making too many requests within a given time frame. Additional layers of protection may also be provided, enabling API owners to turn off inbound traffic from whole IP address ranges, geographic regions, or routes to defend against distributed denial-of-service attacks.

Private, Partner and Public APIs in an Ecommerce Application

Purpose of APIs

Software development has always been a very time-consuming, technical undertaking. The original purpose of APIs was to make software development faster and more efficient by enabling the effective reuse of software code. For example, if a team of expert payments software developers writes a program for credit card transaction processing within a large company, then every other group in that company that wishes to accept credit cards can reuse that code.

Over time, as software became more important for businesses and the economy at large, that same purpose has expanded. It has helped create a kind of “federated” business, in which new business ideas supported by API-based services can be brought to market rapidly and tried out at relatively low cost. In addition, the “technical” bar has lowered, with modern APIs allowing software developers with less knowledge and experience to still make major contributions to their company.

How Can Businesses Use APIs?

Today, businesses of any kind or size can find practical benefits to using APIs, often for many different purposes. While they may seem like something primarily tech companies should pay attention to, APIs are now available for services that virtually any type of business, in any industry, will find extremely valuable.

For example, nearly all businesses now have websites, which they analyze using services such as Google Analytics that employ APIs to track traffic. Other APIs provide the reports and analytics the business requires. Ecommerce sites use APIs to access logistics, payments and shipping services; banks use APIs to help customers download their financial information to popular personal finance apps or websites for analysis; and marketers use APIs when sending email blasts via marketing automation solutions.

API Use Cases

There are literally an unlimited number of use cases for APIs, ranging from a startup that can rapidly develop a minimally viable product by leveraging services available via APIs over the internet, to a local used-car dealer incorporating order-status reporting functionality into its website from a remote source. Here’s an overview of some of the major categories of API use cases:

Component/microservice APIs. Modern business applications are often designed not as monolithic, complex, do-everything units of software, but as collections of smaller, simpler components that each do one thing well and provide APIs to coordinate with complementary solutions. Often referred to as “microservices architecture,” this way of building software enables easier and more flexible scaling and efficient use of compute and other resources.

Cloud service APIs. Cloud computing providers let developers and businesses leverage software-based “virtual machines” that work like physical computers, connect them with one another using virtual networks and take advantage of a host of additional services, all charged on a pay-for-use or subscription basis. There are extensive APIs that let customers automate the cloud data center, setting up and tearing down fleets of virtual machines and other resources very quickly in response to changing business conditions and application traffic requirements.

Web metrics APIs. Need to know how much traffic your new website is receiving? Web analytics software provide tiny JavaScript patches you can include in web page templates. When a visitor arrives at one of your pages, the code on that page calls the API and sends a message containing all kinds of information about the page visited, the user’s location and browser type and other data. The web analytics service then compiles this information, letting you generate reports and derive business insights.

Payment APIs. Anyone who runs an online store quickly learns about the importance of payment APIs in secure credit card transactions. Selecting the appropriate APIs builds customer trust, protects businesses against the liabilities associated with credit card misuse and storage of payment card information and directly impacts the bottom line in several ways. For example, it can accelerate funds availability or reduce profits by taking fees.

Shipping APIs. Integrating web and customer service/operations workstation software with shipping APIs provided by major carriers (USPS, FedEx, UPS) enables scheduled pickups, supplies ordering, more accurate projections of delivery dates, error-free billing and package tracking, among other services.

Mapping APIs. Google Maps, Apple Maps and many other providers offer a wide range of location, routing, trip guidance and coordinated marketing services via APIs. Applications and websites can access these services to provide maps to visitors; route them from place to place; help them locate devices, vehicles or other inventory; and/or promote shopping, restaurants, hospitality and other services to nearby potential customers.

Supply chain APIs. Once available only to the largest companies, supply chain APIs are now available to smaller players in many industries. A plumbing or lighting company or a small general contractor can now easily purchase operations software that integrates with public APIs from distributors and suppliers to help ensure customers always know where orders stand and where required inventory may be available.

Banking APIs. Integrations between popular accounting software and APIs provided by banks, credit card companies and other entities can simplify reconciliation of accounts, enable electronic payments and make tax filings a breeze. They also ensure users are always viewing the latest financial numbers.

SaaS service APIs. Software-based, internet-accessible business services are increasingly central to many organizations’ most important commercial activities. For example, Oracle Marketing provides a full suite of services for defining, populating, executing and measuring results from marketing campaigns in the cloud. Its Eloqua Marketing Automation software provides a comprehensive API that customers can use to manage and extend the service suite and/or integrate it with other applications.

History of APIs

APIs have existed at least as long as software programming using symbolic languages has. The essential features of an API are the ability to invoke a command (e.g., “write these characters to the screen”) using a symbolic label (e.g., print) and the ability to specify variable or literal data for use in that invocation. Take this command: “print(“This is literal data that will be printed on the screen”).” In this example, written in the programming language Python, the word “print” is the command verb. The parentheses — in Python as in many other languages — conventionally enclose arguments (also called parameters) for the command, and the quoted string is a parameter, in this case, specifying the text that will be displayed.

This is an API call in miniature, carried out entirely within a local Python programming environment running on a single computer. As with other APIs, this one is providing segregation of concerns and information-hiding: The writer of a Python program doesn’t need to understand the arcane, many-layered mechanics involved in displaying these characters in, for example, a floating terminal window on a graphical Linux desktop (using a particular font, colors, etc.).

So-called “object-oriented” programming languages (including Python), introduced in the late 1970s, elaborate on this basic model in important ways. These languages enable coders to encapsulate data (variables) and functionality inside code objects that can then be extended and combined. Modern object-oriented languages like Java and .NET build heavily on this model, enabling information-hiding, promoting code reuse and making powerful functionality available to developers in easy-to-use ways.

Telecommunications — prior to the internet and even prior to the arrival of digital transmission — employed APIs from very early on to enable remote integration of phone equipment like telco central-office and private-branch-exchange (PBX) switches. Early phone systems used in-band audio tone signaling and other methods for sending “commands” and “arguments.” Tone dialing, introduced in the 1960s, defines an API and encoding so a telephone, PBX or other phone equipment can send sequences of digits down the audio path of a standard phone line.

APIs really took off, however, once data networking and, later, transmission control protocol/internet protocol (TCP/IP) and the internet arrived and became ubiquitous. Universal any-to-any connectivity meant that any network-connected machine could contact any other machine. Today, this includes mobile phones and Internet of Things (IoT) devices of every kind, in addition to computers.

API Protocols

No history of APIs would be complete without discussing the evolution of API protocols, the earliest of which were an integral part of “the network is the computer” vision that led to the internet. Protocols define rules for API interactions. Here is an overview of the history of API protocols.

Remote Procedure Call (RPC)

Modern, internet-centric APIs got their start in the late 1990s with a range of ideas emerging from innovators like Sun Microsystems. Many of these approaches to standardizing application-to-application communications began as part of efforts to create multi-server compute clusters that combine several — or more — discrete computers in a network-connected cluster that would behave, in some ways, like a single machine.

In conventional software, i.e., not running on clusters, function calls like the print call in Python provide an elegant way of segregating concerns and hiding information, abstracting and decoupling mainline code from specialized libraries. Engineers at Sun and elsewhere working on similar infrastructures realized that function calls could be extended across networks, with certain provisos and caveats. The result was the Remote Procedure Call (RPC) mechanism that, in its simplest version, is designed to let software running on one machine make a synchronous (i.e., blocking) call to a function on another machine and wait for that function to return a result.

Simple Object Access Protocol (SOAP)

As TCP/IP, the internet and the world wide web grew, a host of standard protocols and methods evolved for enabling, structuring, authenticating, and encrypting messages. In 1998, Extensible Markup Language - Remote Procedure Call (XML-RPC) emerged as an initial attempt to pull all these technologies together and to use XML as a data-structuring tool. XML was derived from the Standardized General Markup Language (SGML), the original markup language from which the Hypertext Markup Language (HTML) also evolved. XML-RPC quickly evolved into a more mature form called the Simple Object Access Protocol (SOAP), designed for structuring command and data interchange among web services.

SOAP is a flexible and extensible protocol, enabling relatively easy creation of APIs for a wide range of applications. But SOAP was designed for an earlier vision of the decentralized web that uses XML and other tools for semantic markup and resource coordination (i.e., markup that controls not the appearance of content, but articulates its meaning and purpose in context). In fact, the web has evolved somewhat differently, and a simpler protocol called “Representational State Transfer” (REST) has become the dominant model for APIs.

Representational State Transfer (REST)

In his doctoral dissertation in 2000, Roy Thomas Fielding introduced the architectural style that would swiftly come to dominate the world of internet APIs. He called it “Representational State Transfer,” or REST. REST APIs are called by accessing specific internet uniform resource identifiers (URIs) using one of four standard HTTP methods specified in HTML forms processing: GET, POST, PUT and DELETE. REST APIs also use an HTTP-standard Content-Type designation to describe the encoding and, in some cases, formatting, of subsequent data. REST APIs typically return structured data framed with XML tagging or formatted as JavaScript Object Notation (JSON) datasets. In some cases, REST APIs may return paginated data, meaning that a calling application may need to make several requests to receive all the pages of records comprising a response to an initial query.

REST APIs provide many benefits to coders. You can use a browser, a REST-request-formulating utility like Postman, browser extensions, toolkits like Insomnia, basic Linux commands like “curl” and a host of software development tools for every programming language to explore REST APIs, formulate and test REST queries, field responses and write both APIs and API-calling code. Produced and internally documented with the right tools such as OpenAPI 3.0, REST APIs can be largely self-explanatory, reducing the need for REST API creators to write separate documentation and extensive tutorials before developers can put their APIs to work.

The REST API architecture harnesses the web’s protocol stack for target authentication and both-ways encryption. It functions well even when communications need to follow complex routes through proxies, caches, redirects and other traffic management facilities commonly encountered.

GraphQL

GraphQL is a standard for framing requests and building responsive APIs that was invented by Lee Byron and colleagues at Facebook around 2011, and was open-sourced in 2015. It is similar to REST in that it can use HTTP for transport and make use of a subset of HTTP features (mostly GET and POST). But GraphQL APIs serve so-called graph databases, like Neo4j, which save data as hierarchical collections of name/value pairs connected by relationships in complex networks. As one might expect of a system invented by Facebook, graph databases are tailor-made for storing and searching “social graph” information, where facts about individuals are subsidiary to the relationships connecting them to one another.

Requests in GraphQL are framed as JSON datasets, defining subject and matching conditions for search and the scope and shape of data you wish returned. The GraphQL API searches a database for matching values and returns surrounding data that may be available to fill out the scope. A wide range of tools are also available to assist in formulating GraphQL queries using something closer to an SQL-like database query language.

Examples of APIs

Modern applications typically use many APIs. Let’s explore several examples of APIs by considering those very likely to be used by an ecommerce site. Imagine an ecommerce transaction that begins when a site visitor presses “Submit Order” with items in their shopping cart. This might trigger an asynchronous call to the web server — mediated through a client-side API like jQuery, Axios or React-Async — telling it that the buyer is ready to check out.

On the server side, code calls additional APIs to determine the state of the user session making the checkout request:

• A session-management API, like express-session, may be consulted to figure out whether the user is recognized and logged in, determine what’s in their shopping cart and check to see whether other pre-checkout requirements are fulfilled.
• A database API may be used to see whether items are in inventory and determine base prices for quantities ordered.
• A sales tax API call to a remote tax calculation software may be consulted to determine sales tax.
• A shipping API like FedEx Web Services may be consulted to determine shipping fees, if any.
• Assuming there are no errors, the pending transaction details are stored in the user’s session, and the system responds to the original call by building a checkout page and directing the user’s browser to it.

On the client side, the user confirms details and presses the “Complete Order” button:

• Asynchronous API call to back-end: complete this order.

On the server side:

• The server would then typically call a third-party payment API like Stripe with transaction details, then wait to retrieve payment confirmation.
• Once confirmation is received, the server logs the order for fulfillment, invoking both the database API and logging API.
• It would then generate shipping labels, again via the shipping API, and request order pickup.
• Confirm order to user via email, using a local or remote mail API.
• Reply to the asynchronous call from the user when complete.

On the client side:

• Thank you for your order!

It would be extremely difficult and very slow to write all these services using lower-level function calls, socket connections and other do-it-yourself methods. Using APIs lets businesses profit from the work of hundreds or thousands of other developers.

Future of APIs

The future of the internet is entirely bound up in APIs, which have become vital gateways for interconnection and valuable mechanisms for commerce. With few exceptions, all modern software is written to leverage APIs and provide APIs of its own.

For this reason, APIs represent an enormous attack surface for exploitation. In recent years, hundreds of so-called denial-of-service attacks have been carried out against public APIs, in some cases making large-scale applications and services unavailable for significant periods of time. The most important public APIs are fairly well-defended and closely monitored, and developers are consistently working to improve their security and resilience.

This is less true of millions of APIs now lighting up in internet-connected appliances, vehicles and smaller devices. A sort of arms race is now emerging to create defenses for these fast-proliferating connected tools before attacks against them become widespread. Ubiquitous APIs also create problems in data governance and privacy, largely because they make access to data so simple.

Thus, continued and increasing focus on security, privacy, governance and regulation is likely to remain a major theme impacting the evolution of API technologies and the business models created around them. Increasing ease of use is another important trend. In the near future, expect APIs to become “thicker” as additional software layers, machine-learning classifiers and other technologies are put to work building out and managing APIs that make intelligent use of software features, respond intelligently to queries and make APIs more self-documenting and more discoverable.

APIs are critical to software innovation, helping developers deliver sophisticated applications to market quickly and improve them aggressively, all while taking advantage of others’ expertise and avoiding reinventing the wheel.

API FAQs

Q: What exactly is an API?

A: An API, or application programming interface, is a set of methods enabling an application to provide data and/or perform services for other applications. APIs require calling applications to optionally authenticate, then frame requests in a specific way, providing data in specific formats. The called application then provides responses, also formatted in a specific way.

Q: What is meant by API with example?

A: APIs, or application programming interfaces, are ways for software code to interact with other software code, requesting information or services. Like the connecting bits on Lego bricks, APIs enable complex application software to be constructed from many simpler modules linked together. The Google Maps API, for example, offers a wide range of location, routing and trip guidance information upon request from other applications.

Q: What is an API and how does it work?

A: APIs let one program request data or services from another. They generally work in three steps: authentication, request and response. An API’s documentation should specify how requests are formatted, how errors are managed and what responses are returned by successful queries. Often, a popular API will be supported by Software Development Kits (SDKs) compatible with many programming languages. Programmers can use these SDKs to simplify integrating with APIs in the languages of their choice.

Q: What are different types of APIs?

A: Private APIs are used to connect application components together and enable access by applications to shared business resources, like databases. Partner APIs extend an organization’s key applications to designated partners, whose applications are required to authenticate before access is permitted. Public APIs may be engineered to provide services to anyone, generally without authentication.

Q: When should I use an API?

A: As a general rule, applications should be as simple as possible, since simplicity makes them easier to maintain, secure, improve and scale. Achieving simplicity means that application developers should focus on the parts of a program that are specific and strategically important to their business, and otherwise make use of external resources as much as possible, drawing on others’ expertise for nonstrategic elements. That often means using the best available API-mediated service to provide the nonstrategic elements of business software.