API technology allows two software applications to connect, communicate and collaborate. At its core is a combination of technologies that do two things. First, web services harness the power of internet “backbone” communication protocols to provide a robust, secure channel for connecting two applications and transmitting data. Second, standards like JSON and XML provide data-interchange formats (“objects”) that are easy for humans to read and write and for machines to generate and parse.
Imagine if instead of two applications communicating using internet protocols and JSON objects, Mary and Sue are texting each other using a secure messaging service. The unique thing about this conversation is that Mary and Sue have agreed to only use a pre-arranged set of questions that are always asked and answered in a highly structured way.
So a conversation that starts like this:
Mary: How are you today? Sue: I am fine
becomes a structured exchange like this:
“Application” Mary “asks”:
>Get /Service/HowAreYou/now
“Application” Sue “responds”:
>{“myStatus” : “fine”}
Mary and Sue can also have more complicated exchanges. Mary can ask questions that include more “parameters” and Sue can respond with more detail and options.
Mary: How’s the weather there?
Sue: We are having a storm! Rain, lighting, rough surf and high winds from the east.
Becomes:
“Application” Mary:
> Get/Service/TheWeather/now
“Application” Sue:
>{
“weatherCondition” : “stormy”,
“rain” : “yes”,
“lightning” : “yes”,
“surfConditions : “rough”,
“windSpeed” : ”25”,
“windDirection” : “east”
}
There are some obvious advantages to this approach.
- Neither application knows or cares about the internal workings or data structures of the other. They have agreed upon a standard format for asking and answering questions that reliably lets them connect and share. As long as they can speak “API”, what they do internally “on their own” time is their own business.
- The format is flexible and extensible. It’s pretty easy to update or change the objects or the options for each member of an object. This flexibility is a major advantage since it provides a path for future improvement while preserving the past for compatibility. If “Application Sue” wants to start reporting the pollen count as part of the “weather” service, we can just add that as a new member of the weather JSON object:
>{
“weatherCondition” : “stormy”,
“rain” : “yes”,
“lightning” : “yes”,
“surfConditions : “rough”,
“windSpeed” : ”25”,
“windDirection” : “east”,
“pollenCount” : “low”
}
Applications that want to use this new information about pollen counts can do so; those that don’t simply ignore it.
The format can be read by humans and machines. You just proved that by reading this far! This can increase clarity while minimizing errors and the need for special codes, hardware, etc.
There’s more to it of course. In addition to using “Get” services to “ask” questions, Mary can use “Put” services to tell things to Sue. “Put” is very powerful and Mary can use it to actually change Sue’s status or the weather! And there is security checking, error handling and the like. But, basically this is how it all works.