API – Application interface
Best way to describe an API, is an interface of a wrapper of some source code. This enables interaction with your code via any third party that would like to use the functionality of what you have programmed.

This enables any third party to treat your code, as a blackbox. Putting some input variables in and getting out from your blackbox a result of a sort.

Of course this result can be visual, or any other data output, that you will later process. On occasions it can be just enabling an activation of a method or a procedure in the wrapper.

Programming language based API
Programming view point, a lot was and would be written. Different language syntax were introduced. And they can be a post for another discussion.

I’ll just note, that the best was to see the wrappers in use cases, is within the Object Orient Programming — whether it be OOP (Object Oriented Pascal), or CPP (C Plus Plus) and Java. Where structures and objects using different procedures/methods/properties was defined. Wrapping source code objects in a defined structures.

The way of structured Object programming that was well defined, was shifted onto different source codes that function as a blackboxed application. When programming the actual code, in different places from within the application different calls are made to existing object and interfacing with them.

Same goes when a service/application requires interaction with the code, yet not within the same source code, but as an external interaction to the objects, data and services of the application.

These requirements resulted with many different products and syntax definitions that could be encountered on many different areas of computing. Here are my notes on these definitions of API.

Winamp API – My First spark of a great code and application design by NULLSOFT
My first encounter of a great API was with the WinAMP media player from NULLSOFT. They designed their application in such a way that any given part of the application could be interacted by any third party — while they enabled the following interface interaction:

• Input files — Enabling the player to recognize many additional file types, not always the ones that were defined by default.
• Output Devices – Enabling third party to define new output devices, so that the application will support addition ones other than the default Stero types
• Filters – Enable different audio filters to be defined,

And so on. They defined the application in such way that the interaction included elements such as a skin style for the GUI of the application, something that until then hasn’t been done in such way.

Microsoft API definitions – By chronological releases
Microsoft initiated a set of wrappers when they found the need to do so, and saw the demand from third party developers. Way back on the early days, when there was the MSDOS, and the first Windows — the definition of wrappers was only in its first stages. In the coming years they defined various types of API wrappers for applications. Here is a short list of some that were defined:

• DLL – Dynamic Link Libraries
• OLE – Object Linking and Embedding
• DDE – Dynamic Data Exchange
• ActiveX – COM Automation – Component Object Model
• DCOM – Distributed Component Object Model

This is a vast area, that was defined by Microsoft — and produced many great subproducts., The introduction of the DDE and COM/DCOM, enabled companies to wrap their product as a defined product, and market it to be used by software developers.

The DCOM, enabled the wrappers to be put on a remote machine and launch their task from that machine. Using a Client/Server programming abilities. Yet, all interface to a DCOM object is, mostly, as if it is a standard COM automation object.

As for the developers they had — when interacting from their code — to the blackboxes — to know the basic structure and method of assigning and mapping their application, with the blackboxes they got. Unifying this ability — produced a vast market that could use different ideas.

Google API
As I see the software market, google initiated a set of API for their products (which were mostly web based) as they learned from the existing companies and tech history.

Google viewed the market from a software developer view point. This enabled them to define the API and different interfaces in a way that will be easy for other software engineers to interact with.

On their developers site, you can find many different API to their product. Due to the fact that they became a huge and dominated company in the market, the list of API is parallel to their products services (search engine, mapping, cloud, office products [documents, spreadsheets, presentations], translate engine, social plus services — the list just getting larger as the time goes on).

Google web orientation, required a definition of the interaction with the different services to be done via the web itself. If the beginning of the API definition was done locally, on a single machine — as interaction better one local application to another local application, that ran on a single computer. –> the definition of the google services was shifted to a web based alike connection between each application. As different application ran on different machines, connected by the internet –> done, usually, as client/server based applications.

The web interaction, required a definition of some sort of structure of when passing parameters to process/or receive — This produced a variety of structures on different layers — as structured data elements (such as XML – Extensible Markup Language, or descended that enhanced it — such as KML – Keyhole Markup Language for mapping services for example) — or different definition  of structured language on the transport layer — (such as communication using JSON JavaScript Object Notation – data structures)…

 

Mobile and cross platform API

When mobiles came to existence, many possibilities and enhancements were introduced.

Today, when any application is written — people who know the market and programming will try to cover the following on their first, or later, releases of the application:

• A desktop machine application (Whether it be a linux, windows or mac machines)
• A mobile application (Whether it be an Android, Windows, iOS, or other platforms)
• A web based application (A web based access to the data or services one provides)

There are many examples of such applications from different companies, that offer their services cross platform on all the above points I’ve mentioned. Again the best place to view such cross platform services, is on google products. Yet examples can be found on many other pinpointed services, such as the services of a Cloud Drive (you can check DropBox, OneDrive, GDrive, and others). Or other services such as EverNote.

A good company will expose their services to an existing ISO defined API, or a unique proprietary API. Again this varies on the company and upon their knowledge that they must produce such a feature so that coders will  act as a leverage to boost their product and services.