While there are no rules or laws governing exactly how developers must connect their applications to an API from across a network or the Internet, several approaches have emerged as de facto standards for achieving such connections and transmitting and receiving payloads. For example, when it comes to applications connecting to APIs from across the Internet, the majority of API providers make such connections possible over the HTTP protocol (Hypertext Transfer Protocol)--otherwise known as the World Wide Web.
HTTP is the same protocol that makes it possible for Web browsers (as the consuming software) to send and retrieve information to and from Web sites (the services). For example, when you visit the Web site for the National Football League (NFL.com) with your Web browser, your Web browser is exchanging information with the NFL’s Web server over HTTP. In fact, whether you are retrieving game scores or submitting a list of your favorite teams to NFL.com, the site is relying on a special set of HTTP commands called "verbs" (including get, put and post) that are purpose-built for such client/server exchanges of data.
Software relies on HTTP verbs in much the same way that Web browsers use HTTP verbs to exchange information with a Web site. For example, the NFL has mobile applications for iOS and Android that can retrieve game scores and maintain lists of favorite teams. But, instead of retrieving information in a way that’s formatted for easy-to-read display in a Web browser, software like the NFL’s mobile apps retrieve information in more of a machine-readable format that it can subsequently manipulate for display within the mobile app’s user experience. In most cases, the service provider (the NFL, in this case) will provision a special Web address known as an API endpoint for such software to connect to. That Web address is different from the one that a browser would connect to in order to get the same information.
API endpoints that are addressable over the Web and that support the HTTP command structure are often said to be “Web APIs.” To the extent that Web or mobile applications can be primarily composed from calls to multiple Web-based APIs from multiple Web API providers (these composite applications are sometimes called “mashups”), the Web has turned into a programmable platform that’s equally, if not more, powerful than programmable platforms including Windows, Mac and Linux (thus, the name of our site: ProgrammableWeb.com).
At this point, it’s important to note that there are different types of Internet-based APIs. While some don’t follow these exact conventions (some may not even rely on HTTP), the API fundamentals--whereby developers are able to find an API to handle some commodity task instead of taking weeks, months or even years to write their own code--are the same.
Also, whereas some APIs are designed to query or update a database, other APIs simply initiate a process. For example, Sony makes cameras that can be remotely controlled via a Web API through which developers can activate a camera’s shutter. Still other APIs, as mentioned earlier, can add functionality into your application. For example, instead of writing millions of lines of code and licensing third-party mapping data in order to present an interactive map in an application, a developer can accomplish the same thing with about 10 lines of code that engage the API for Google Maps.
Depending on the volume of API calls, an API provider like Google might charge the application developer a fee for using the API (giving rise to the idea of an “API economy”). When that’s the case, the application developer must weigh all the costs of using the API versus developing the functionality from scratch. Or, as is often the case in the API economy, the developer can seek out a more economical provider of a similar service.