What is an API? Application Programming Interface Complete Guide

A system of application programming interfaces represents a fundamental concept by which various software components and resources can interact with one another. Properly designed software will have internal APIs to help organize the code and the component reuse to be able to. In addition, there are a variety of publicly accessible interfaces that allow you to use functionalities that "others" have developed.

What is an API?

An application programming interface is defined as a specification of possible interactions with any software component. This can be illustrated with an example: Imagine the software component as a car. Its interfaces would provide information about what the vehicle "can do" - i.e., accelerate, brake, or turn on the radio. In addition, the vehicle's APIs also provide information on how to trigger the functions mentioned: To accelerate, press the accelerator pedal with your foot.

The API does not have to explain what happens inside the combustion engine when the gas pedal is pressed. Once you've learned to drive a conventional car, you can get behind the wheel of an electric car without having to acquire a whole new skill set. The information about the "what" and the "how" is recorded in the API definition, which represents an abstract variable and should be viewed independently of the vehicle itself.

You should always be aware that some interfaces' names are often used as synonyms for the specification of the interactions and for the software component itself. For example, the term "Twitter API" refers to the set of rules used when interacting with Twitter and is also perceived as a label for the "thing" you are interacting with.

How do interfaces help?

When it comes to software, interfaces are everywhere. They go hand in hand with one of the fundamental concepts of information technology: abstraction. This represents a means of "organizing" the complexity of a system - and simplifying complicated tasks. This principle can be illustrated using the well-known Amazon Dash Buttons: The battery-operated push buttons with an integrated circuit order certain products from Amazon with a "push."

If you want to use the product, first connect it to your WiFi network and your Amazon account using the smartphone app - then link it to a specific product you use every day - such as toilet paper. As soon as your stock runs out, reorder at the push of a button. The same principle also applies to an application programming interface.

Here, too, an interface that appears simple from the outside "hides" the complexity of the processes: The product ID must come from a database, your delivery and billing address must be determined via your account, the nearest logistics center must be contacted - before your delivery can then finally make its way to you.

Now imagine you had to manage all these processes yourself as a customer. You could switch to an alternative procurement option for toilet paper; the complexity and time required for a single order would be far too high. The delivery of your toilet paper is based on a long, computer-aided process chain - but you only have to worry about one thing: pressing the button.

This is exactly how APIs work for software developers and programmers: an excessive amount of complexity is packed into a relatively simple interaction set that can be used from now on so that you don't have to start from scratch every time. Within the framework of a software project, thousands of interfaces can be used, each of which relies on a different API.

How does API integration work?

Interfaces have been part of the standard repertoire of computer scientists and programmers for years. Traditionally, APIs have been used to connect code components running on the same machine. Because networks are ubiquitous today, more and more so-called "public" or "open" APIs are available. Such interfaces are directed "outwards" and can be reached via the Internet. This allows you to create code that can interact with other companies' software code over the network. This process is called API integration.

However, "open" or "public" is not the same as "free" in this context. However, the availability of such APIs greatly simplifies interface integration. There are plenty of open APIs available to you on the web - the tech giants excel at this. The platforms only become real platforms through the possibilities that their interfaces create:

• Google APIs connect your code to the full range of Google services. APIs are very important to the group. That is why a leading interface management platform, Apigee, was acquired a few years ago;

• Facebook APIs give you access to the company's marketing tools, among other things. However, following the Cambridge Analytica scandal, Facebook severely restricted the availability of information through the APIs.

An overview of other important application programming interfaces that you should know can be found here.

Do web services equal APIs?

Perhaps you still remember the term "Web Services" (which was used with pleasure and sometimes inflationary, especially shortly after the turn of the millennium), and the principle of "open APIs" seems somehow familiar to you. A web service is just one open interface type requiring a fairly rigid specification set. This includes, for example, that this is available in WSDL (Web Services Description Language) - an XML variant.

Web services were originally intended to be part of a service-oriented architecture (SOA). Because SOAs could never develop their full potential, web services have yet to make a breakthrough either. Technological advances in service-to-service communication - particularly the advent of the lighter, more flexible REST APIs - have also contributed to the decline of web services in the world of public APIs.

What is REST? And what can it do?

Web services were originally intended to communicate using the SOAP (Simple Object Access Protocol) messaging protocol, which sends XML documents via HTTP. Today, however, most web-based interfaces use the REST (Representational State Transfer) protocol as the underlying architecture.

REST was formally introduced in 2000 by computer scientist Roy Fielding. It includes architectural components, design principles, and interactions to create distributed systems containing various media content (text, image, video). At its core, REST is a way - a style - of building systems that allows flexible communication and presentation of information across the World Wide Web. It also provides the necessary framework to create general-purpose components easily.

Within a REST API, a resource is almost anything, such as a user, a list of tweets, or the list of results when searching for tweets. Each of these resources can be addressed via a "resource identifier." In the case of web-based REST interfaces, this is usually the URL. When an application requests a resource that uses this "identifier," the API returns its current "representation" in a format that the application can process accordingly - such as a JPEG file or an HTML page.

One of the key unique selling points of REST is that it transmits data to the requesting application. Although this leads to great flexibility because the application can "do whatever it wants with the data," it also costs efficiency. After all, "transporting" data over the web for processing takes time.

What is SOAP?

SOAP is a protocol standard for exchanging data between systems connected via networks. Remote procedure calls can also be executed with SOAP. The protocol resides in the application layer's TCP/IP protocol stack and works with TCP and protocols such as HTTP, HTTPS, or SMTP at the lower layers.

Originally, SOAP was the acronym for Simple Object Access Protocol. Since version 1.2, only the short name SOAP has been used. SOAP is a protocol standard for exchanging data between different systems connected via networks, and remote procedure calls can be executed. The protocol works independently of the operating systems, languages, frameworks, or platforms used on the systems. Microsoft originally developed the protocol.

Version 1.0 appeared in 1999. As large companies like IBM joined the protocol standard, the standard was submitted to the World Wide Web Consortium (W3C). SOAP has been a standard recognized by the W3C since version 1.2. The actual specification is divided into several documents.

They include a SOAP tutorial, the normative framework for SOAP messages, the data model for SOAP, and the coding scheme for remote procedure calls. The specifications regulate the format of the messages and how data is mapped and interpreted in messages. In principle, any application-specific information can be transmitted with SOAP.

Similarities and differences between SOAP and REST

In addition to SOAP, there are other protocols and architecture models for the online message exchange of applications. A widely used web service API is REST (Representational State Transfer). While SOAP is a standardized protocol, REST is a paradigm for software architecture in distributed systems. REST is specifically geared toward mobile applications, lean web services, serverless monitoring and serverless computing.

Like SOAP, REST typically uses HTTP. In addition to XML, HTML, JSON, or simple text can be used as message formats. A preferred format is a machine and human-readable JSON. Depending on the intended use and the programming languages ​​used, REST and SOAP each have specific advantages and disadvantages. REST is considered a more modern architecture and is more flexible, faster, and easier to implement. REST APIs are lightweight regarding security and SOAP scores with the integration of WS-Security.

API examples

There are numerous public interfaces on the web with which they can interact - especially on the part of the industry heavyweights. Some prominent examples are:

• Google APIs

  Enable your code to interface with the full range of Google services - from Maps to Translator. Interfaces are so important to Google that the company acquired Apigee - a leading API management platform - for this purpose.

• Facebook APIs

  Provide programmatic access to Facebook social graphs and marketing tools.

To get an idea of ​​how APIs work in practice, in the following two paragraphs, we will take a closer look at the Java API and the Twitter API.

The Java interface

The Java API is a library for "out of the box" software components that are freely available to anyone with the Java Development Kit installed. These components are used to implement common tasks and increase productivity because developers don't have to start from scratch every time.

For example, a basic software component is a list. The Java API defines what you can do with this list: add items, sort the list, and so on. In addition, the interface also defines how these actions take place. Staying with the list example: To sort it, you must specify whether you want to sort it alphabetically, numerically, or by color, for example.

In contrast to the Java API, the Twitter API is a web-based JSON interface that allows software developers to interact with Twitter data programmatically. A request must be made over the internet to access the Twitter API. With a web-based interface, your application sends an HTTP request as a web browser would, except that the answer does not come back as a web page but in a format processed by software. These formats are available in various forms - Twitter relies on the popular and particularly easy-to-use JSON.

A fundamental element of Twitter is a tweet. The Twitter interface defines what you can do with tweets - such as (browsing) or creating. But the API also defines how this works. For example, you need to specify the criteria in search terms or hashtags to search tweets.

How does interface design work?

API design describes the process of formulating the "what" and "how" of an interface. As with all creative endeavors, API design also depends on how much care and know-how the developers put into their job let flow. A high-quality application programming interface:

• is consistent

• able to include context

• and taking user needs into account.

Consistent behavior significantly impacts how quickly the API can be used and how error-prone it is during software development. Generally, APIs that perform similar tasks should "behave" similarly - their technical differences don't matter.

Incorporating context is another form of consistency, although that's related to external factors and not the API itself. It's all about drawing on common best practices and being "inspired" by other APIs that your users are familiar with and how they work are already familiar.

However, your users should be at the top of your list of priorities regarding interface design: You should know who they are and their needs. If you know the "pain points" of your users and help them to get rid of them, the chances of a happy user base are good. If you're ready to start with application programming interfaces, take advantage of this list of free interface development tools.