Cross-Platform Mobile Development - Blog Post #2

Tweet

 

Cross-Platform Mobile Development #2  

Plain web services for Web and Mobile Application

Post 2 of an ongoing series

Written by Pablo Elustondo

In this post we will elaborate on the first principle from our previous post, ‘structuring the server side application around a clear API made with web services’. Here, we introduce web services for a Web and Mobile Application in an extremely simple, conceptual and practical manner using a realistic example. Some concepts in software development, like object orientation or web services, are sometimes explained in a complicated manner with unnecessary jargon and details. In this post, we go back to basics, focusing on conceptual integrity, best practices and simplicity.

Web services are a way to architect the communication between two applications that are connected via the internet/intranet. In Web and Mobile Application Development this two applications are normally classified as ‘the server (or service)” and ‘the client (or app)’. Both servers or clients normally run on a particular application containers: servers run on application servers like Tomcat or ASP.NET and clients run on top of things like browsers, mobile operating systems or PC operating systems. In any case, the concept is very similar, even a browser can be seen as an ‘operating system’ of some sort. The only thing that may change is the programming language, programming interfaces and capabilities that are available on different platforms.  Understanding all those clients under the same conceptual umbrella allows us to architect cross platform applications. The next figure illustrates this:

 When designing web services as described before, we are assuming that we are sending and receiving textual information, using a standard protocol like HTTP.  Of course you can encrypt the information, but from a conceptual point is better to think of textual information that can be read by humans.  Although the information that is exchanged can be arbitrary, we suggest here a best practice to structure this information. This practice is based on best practices for structuring applications using ‘model’ entities and ‘view’ entities. A ‘model’ entity is a way to represent a particular type of information, and a ‘view’ entity is a mechanism to show and interact with that information represented by the ‘model’ entity. For example, our ‘model’ entity can be constituted by an address, a street name, a city, etc and our ‘view’ entity can be Google Maps showing that address in the map. Both the client and the server should use well defined model entities to represent the information that is being manipulated. Using this practice (also called a pattern), the web service is used as a mechanism to send representations of these entities back and forth and to implement a particular operation that should be applied to them.

For example, the client may ask the server for an address, the server will send the address back to the client and then the client will show this address in the map combining that information with other information from other sources. These entities at the client or server side do not need to be identical, both servers and clients will represent entities in a way that is convenient for their role in the application. Clients and servers send and receive a version of those entities that make sense to both according to an established protocol. In other words, servers and clients exchange a ‘representation’ of the entities. The next figure illustrates this concept

 Note: This idea of sending and receiving ‘representation of entities’ using a predefined protocol over HTTP is related with what is referred as REST (Representation State Transfer) protocol.