When two (or more) systems communicate with each other through an API, there is a protocol with pre-defined functions that make this communication possible. But, of course, there isn't just one way how systems transfer data and information. There are several types of APIs used for various use-cases, as we explained in our previous article. For every kind of API, there are specific protocols that define the rules for the accepted data types and commands. And today's the day where we give you some understanding of the beautiful world of API architecture. 

Step-by-Step

Learning about API architecture is near as "easy" as learning how to build or repair a car. To call something a "car," the vehicle needs to fulfill certain conditions: having three to four tires, one wheel, and being moved by an engine or motor. Although the main parts "under the hood" of a car might be the same, there are already considerable differences in their structural engineering depending on their fuel sources (try comparing a gasoline-driven car with an electric one). And you can narrow the differences down even more. Meaning, you might get a bigger picture of cars in general, but it's an immense task to grasp everything about every single car existing. 

It's the same here with APIs. So again, we won't be able to go into every detail on this matter, but we'll give you an overview of every significant aspect.

Types & Classes

In our previous article about APIs, we talked about the three main types of APIs: 

• Internal / Private APIs
• Partner APIs
• External APIs / Public APIs

But APIs can also be classified as:

• Local APIs 
• They offer OS or middleware services to application programs. Examples: Microsoft's .NET APIs, TAPI (Telephony API) for voice applications, and Database Access APIs)

• Program APIs 
• They are based on Remote Procedure Call (RPC) technology, making a remote program component appear local to the rest of the software.

• Web APIs 
• They are designed to represent widely used resources such as HTML pages to be accessed using a simple HTTP protocol. Each web URL enables a web API. 

Web APIs 

For clarification: when we talk about "APIs," we usually mean "Web APIs" since this, from a developer perspective, is our main focus here. But what's so special about them? Well, applications that rely on APIs have traditionally been written in specific programming languages. But with the rise of the internet and cloud services, there've been a lot of changes. The massive advantage of Web APIs is that they can be accessed from any programming language and web pages created in HTML or with software generation tools.

Technically speaking, Web APIs usually send data back and forth using HTTP requests. These requests often return textual data in the form of a JSON or XML response - but that's a topic we'll cover in another article.

Web Services

When talking about APIs, you'll instantly be confronted with the term "Web Services." Unfortunately, "APIs" and "Web Services" often get confused or even used interchangeably since they are overlapping tech terms. By definition, "Web Services" are software systems designed to support communication and interaction between two systems over a network. While APIs can use any protocols or design styles, web services usually use the SOAP protocol (but sometimes REST, UDDI, and XML-RPC as well). But again: "Protocols" will get their own article on here, so don't worry if you're overwhelmed by all those terms at the moment. 

For now, you need to know that while all Web Services are APIs, not every API is a Web Service.