Library vs Framework vs API
Tags: api
Published: 2022-05-12 04:16:30

What are libraries, frameworks, and APIs? These terms get thrown around a lot and sometimes even used interchangably to describe the same thing. 

So let me begin by saying that libraries, frameworks, and APIs are all different things. They may be used to accomplish the same task, but are all fundamentally different. "What are those differences?" I hear you ask. Let me explain each one:

## Library
 **Basically, a library is just a bunch of methods/fields that can be reused to easily accomplish a task, or more usually a domain of tasks.**
 
 **Pros:**
 <ul>
	<li>More developer freedom</li>
	<li>Usually easier to use</li>
	<li>Able to add/remove/replace on-the-fly</li>
</ul>

 **Cons:**
<ul>
	<li>Developer is responsible for the structure</li>
	<li>Longer road to finished product</li>
	<li>Bigger possibility for human error</li>
</ul>

As I have annoyingly promoted throughout my blog posts thus far, I am developing my library *Impart*. The reason Impart is not a framework is because of the tool access. You can render a WebPage or start a Website anytime. There is no template for how the code is meant to be written, it provides the tools and gives *you* the freedom to use them.

## Framework
 **Think of a framework as a more controlling library.  A framework will handle the general flow of an application with no say from the developer.**
 
 **Pros:**
 <ul>
	<li>Framework is responsible for the structure</li>
	<li>Shorter road to finished product</li>
	<li>Less possibility for human error</li>
</ul>

 **Cons:**
<ul>
	<li>Less developer freedom</li>
	<li>Usually more complex than libraries</li>
	<li>Integration is more difficult</li>
</ul>

A great example of a framework is the .NET framework. Well... I should say .NET, as .NET Core (now called .NET) replaced it as the Microsoft framework solution with an open source license and better cross-platform capabilities. Microsoft makes things way too complicated, especially with their branding of "open source developer platform" and naming their main CLI "dotnet". Tangeant aside, just know by .NET I mean the cross-platform framework that is specifically a framework because it controls the flow of an application. By "it controls" I really mean the individual frameworks underneath it because .NET is just a bunch of frameworks for doing specific tasks. (possible blog post about what is included in .NET upcoming?)

## API
 **This term is misused a lot. I don't think I have ever heard a code-related term be used incorrectly as much as API has. In short, an API (Application Programming Interface) is really just the exposed (public) part of an internal library/framework.**
 
 **Pros:**
 <ul>
	<li>Better user security</li>
	<li>Simpler than hardware-level interactions</li>
	<li>Less possibility for human error</li>
</ul>

 **Cons:**
<ul>
	<li>Less developer freedom</li>
	<li>Parameter passing can be a pain</li>
	<li>Integration is more difficult across systems</li>
</ul>

Going back to Microsoft, I love Windows' API: *Win32*. This API allows for system commands that Windows just doesn't trust the developer to do on their own. This can include things like editing the clipboard to having a password dialogue pop up. Given, parameter passing into the external methods can get annoying with the different types and having to create custom structs for certain tasks. But I do understand why Win32 exists. It adds a layer of security and standarization to an otherwise unsecure and non-regulated way of completing system-level tasks.

## Web API
 **This is a type of API meant for sending, receiving, and processing information via web requests. This section will not have a pro/con portion considering that they are literally essential to web communication. I will instead elaborate on the common ways of implementing a web API.**
 
 **REST (Representational State Transfer):**
 <ul>
	<li>Standardization of incoming requests</li>
	<li>More flexible</li>
	<li>Generally uses JSON formatting</li>
	<li>Stateless</li>
	<li>Uses HTTP(S)</li>
	<li>Responses can contain executable code</li>
</ul>

 **SOAP (Simple Object Access Protocol):**
<ul>
	<li>Generally less code required</li>
	<li>More strict</li>
	<li>Only uses XML formatting</li>
	<li>Can use HTTP(S), SMTP, and TCP</li>
</ul>

My apologies for a longer wait for this post, I have been busy lately and this required a fair amount of research to compile together all of this information. It is very possible I made a mistake, so feel free to correct any misinformation in the comments.

Adapted from [this amazing comment](https://dev.to/kspeakman/comment/po8f).

Thanks for reading!

([Cover image source](https://external-content.duckduckgo.com/iu/?u=http%3A%2F%2F2.bp.blogspot.com%2F-jKhddlzy2Pw%2FUPWFkzQ9MJI%2FAAAAAAAAADY%2FQrYdMSSH3lQ%2Fs1600%2Fhacking.jpg&f=1&nofb=1))