Future Proof with API First Development

Our View of the Future
In 1968, Stanley Kubrick brought us the future where we met the Deity. Along the way we viewed a very certain future. A future where it was an everyday event to fly Pan Am to the moon via an airport like space station. Where we went to Bell Telephone phone booths and made video calls home. Where we ate at Howard Johnson’s and when we went beyond our moon, we spoke commands in simple English to our trusty computer Hal.

That was the future.

In 2006, I led a team building a ubiquitous video blog app. Tech Crunch called it a video blog, we called it VLIP, cleverly planning a marketing campaign that included DEVO singing VLIP it. We chose the only technology which ran on all major systems and platforms, Adobe Flash!

Recently, while discussing this experience and the fall of Flash, I may have invented a word: Deubiquitication – What happened when Steve Jobs decided to leave your technology out of his new product.

A couple years later I made a presentation to a major computer maker in Singapore. I was giving them the first look at the registration flow for the new video chat software they were about to install on every laptop they made. I was excited because we had just incorporated the Jetsons, universal symbol of video communications, into our branding.

My audience was insulted. Seems the Jetsons never made an impact in Asia. I won’t tell you the cartoon they recommended. I can tell you that the a major reason why we don’t have video phones is that the automatic makeup machine that Jane Jetson used before answering her video phone has yet to be invented.

Lessons Learned
Believe it or not we have learned several things from the above. From Stanley Kubrick’s 2001: A Space Odyssey we learned that even with great study, we don’t predict the future well. We error in both omission and commission. Howard Johnson, Bell Telephone and Pan Am are gone. No one has been to the moon in decades. Computers and smart devices, however, are everywhere!

From the fall of Flash we learned to beware of proprietary technologies and technology despots.

From the Jetsons experience we learned as one expands ones markets, expect change. (Also to always negotiate an option first on intellectual property.)

2030: A Software Odyssey
What devices will dominate the market in 2030?

I don’t know. Most likely, I will be terribly wrong. The dominant screen and processor may not have been invented yet. Some major event may be totally disruptive.

Future Proof with API First Development
If your application uses data, and most do even if it’s only for tracking usage and user experience, you’ll want to develop your application using protocols that will survive into the foreseeable future. That’s one of the primary objectives of API First Development. Before the application is written, the data flow is planned. What data do we need? What needs to be authenticated? What do we need to track? Then an API is written for these functions. After the APIs are tested, a client or user interface can be developed. More than one client or user interface can be written. The API may initially service an iOS app, a web page, an automotive dashboard, or an airport arrivals board. With API First development, the uses can be extended to other clients and use cases, and as one system fades into another, the data is still available.

How do we know?
In 2016, when we speak of API First development, it is implied that we are speaking of RESTful web APIs. Twitter, Facebook, Google, Linkedin and TokBox all use RESTful APIs. It’s a non-proprietary protocol that can’t be blocked by a vendor. So even if Microsoft, Google and Apple all wanted to keep you from using TokBox APIs in their respective browsers, they can’t! They can’t stop the APIs developed for your new application either.

Representation state transfer (REST) was introduced and defined by Roy Fielding in his 2001 doctoral Dissertation at University of California Irvine which defined a network based software architecture. Quite simply, REST uses the base protocol of the web, HTTP, to send and received data packages. If your computer can receive web pages, it can use REST.

The world wide web is built on the back of two protocols, the hyper text markup language (HTML) and the hyper text transfer protocol (HTTP). Its development was initiated by Tim Berners-Lee at the European Organization for Nuclear Research (CERN) in 1989. The original call is still the most widely used GET; which allows one to GET a file from a server. Most often that file is a web page, but for RESTful APIs it’s a JSON file.

Unless you are a scientist, you can’t debate the ubiquity of JavaScript Object Notation, a simple data model which is easily created and evaluated in just about every web browser on the planet. JavaScript has been around since May of 1995 when Brendon Eich, then a programmer for Netscape created a language to embed in the browser in just 10 days. The language was originally marketed as LiveScript, but Netscape licensed the word Java from Sun and changed the name to JavaScript in September of 1996.

The language was later turned over to the European Computer Manufacturers Association who has maintained the standards since 1997. JSON is part of the JavaScript standard. While developed as a simple data model for browsers, every modern programming language has packages that can create and parse JSON.

Future Proof
RESTful APIs use universal protocols to move data – the fundamental protocols used by the web. If you believe the web will be around in 20 years, then the APIs you write today will still work in 20 years. They may be recording user experience from space station restaurants or providing moon schedule updates to micro screens inside your eyelids, but they will still work.



Lumious – Digital Learning Analytics


contact us
join our team

Lumious, LLC
459 Herndon Parkway, Suite 8
Herndon, VA 20170
Phone: 703.467.8600