API stands for Application Programming Interface and is a framework that allows software to communicate with outside services automatically and procedurally.
An API is a mechanism for two components to communicate with one another, using a pre-defined set of protocols. Think of it as a backend way for software services to talk to one another, rather than a user having to do it manually.
The most ubiquitous example of APIs in action is the way weather apps populate data. Behind the scenes of the iOS weather app, an iPhone communicates with a number of weather data sources (APIs) to populate the app with weather data.
These components, UV Index, Sunset, Wind, and so on, are basically blank containers within the iOS app, placeholders to be filled with weather data from a source. Upon opening the app, the weather data source populates each component with data, all done behind the scenes using an API.
APIs are wonderful because they allow the calling application the ability to not have to store data locally. Continuing with the weather app example, your phone does not have any weather data on it. The weather data exists in a data source like The Weather Channel and only populates when your phone opens the weather app, which launches the API requests.
This lets Apple’s weather app remain lightweight and fast. It is simply an aggregation of weather data components—left blank—and the magic of APIs is what turns it into a usable application.
There are four different ways that APIs communicate:
REST API functions are often mixed up with CRUD functions due to a couple of overlaps.
REST APIs provide full functionality via HTTP protocols between a REST client and a REST server. A request is sent from a client via HTTP, and the server produces an HTTP response in a given format; JSON, XML, HTML, and more.
REST requests and responses are both self-descriptive, meaning information on how to process each is self-contained within the message.
Internal connects via HTTP to APIs and business applications. In Internal, requests can be made to any HTTP, REST, GraphQL, or SOAP API using Internal’s HTTP data source.
Within an HTTP request, users can give a name, host, port, headers (key and value), and any authentication credentials. Once authenticated, the data source can be saved and will be linked to a specific environment.
For more information or help getting started, check out Internal’s HTTP data source documentation.