Access to data in today’s world can be through variety of form factors. The same data is being presented to the user in variety of forms. The journey of user interface in computing started with CLI and now the most popular user interface is Touch. Soon gesture driven interface and natural language processing are going to be most predominant user interface in the computing world.
Evolution of user interfaces in computing.
CLI(Keyboard) -> GUI(Mouse) -> Touch(Smart phones) -> NLP(Home/Alexa) -> Gestures(VR/AR)
The new way of interaction with the computing devices introduced wide range of devices as well.These evolution needed significant change in the way the stand alone computing device interact with the server.Like how the interface evolution happened there was evolution in the way web-services were implemented and orchestrated.
Closely when we look, the data needed for all these interfaces remain the same. However, the way data is presented to the end user varies.
Let’s see the variety of different ways the web services were orchestrated and where we are today.
Traditional SOAP and XML rendering to web – This is most common and traditional approach that was followed over decades for the front-ends to communicate with the server. However, XML was fine with small payload of data. When the size of the XML increased this approach became little complex.
Traditional REST and JSON rendering to web and mobile – During the late 2000’s when mobile devices were getting popular this approach came into predominance. The advantage of REST over SOAP is support on variety of data formats like text, JSON, XML. And REST when used with JSON is more light weight and utilizes less bandwidth.
Utilizing same REST+JSON services for all the user interface – Computing capabilities has given birth to new mobility platforms like voice, gesture, etc. Trying to utilize the same service that was orchestrated before for mobile devices is really bringing down the performance of the new form factor devices. Also this is making the API’s so cumbersome and hard to maintain.
Intelligent API orchestration to address new interfaces – Rest+JSON is good. But, what if the same can be tweaked a bit more to make it even cleaner and light weight. Adding Graph QL to the existing infrastructure will make API simpler. Also, Graph QL is an approach on how you want your API’s to be working rather than a new protocol or technology. Adding Graph QL eliminates versioning of the API’s which is very common and hard to maintain in the mobility space. Same existing API’s can fulfill the data needs of smart phones, voice assistants, gesture based computing systems.
Modern lightweight API orchestration – With IoT devices getting popular, there is a need for more lightweight data transfers than the one discussed above. MQTT is already an established lightweight messaging protocol for sensors and mobile devices. Not every time these sensors need more than binaries to wok on. Some actions like turning on and off a sensor need not have a JSON. JSON might itself be heavyweight for these use cases. MQTT addresses these needs more conveniently. However MQTT has an optional message payload which can take JSON, Text, etc to address other cases where data might be needed. Adding Graph QL on top of this protocol will give developers more convenient way to express API’s.
Defining API is huge responsibility because everything else depends on this layer. Orchestrating the right way will increase and improve performance. It is more important to understand the breadth of the audiences of these API’s.
Something that I have seen quite common in todays API development –
1) Device specific API wrappers
2) Query based API
I think combining both of the above would result in intelligent API design.
Shankar's Blog 