Mobile software development: integration issues

Convenient and simple solutions to problems when integrating with server capacities - what to do if there is a task to make two products that would perfectly fit in, provide each other with consistent data and work on their own without fail.

With details Yegor Taflanidi, Redmadrobot.
')
If you do not create a self-sufficient product (and there are actually very few of these on mobile platforms), you create a so-called “business” application, which usually has a server behind its back, providing up-to-date data and solving some time-consuming tasks.

The server / client bundle has so strongly grown into the mobile development environment that a modern “smart phone” without an internet connection can simply turn into a brick. Some libraries and frameworks (such as RhoMobile / RhoConnect ) are essentially built around this integration server / client itself, leaving it deep under the hood.

There are many approaches to the implementation of such an architecture (two products that would ideally dock, provide each other with consistent data, and by themselves worked without failures).

• Development can be entrusted to one person (or a closely cooperating team sitting in the same room is the same thing). He will dock all the necessary nodes and most effectively solve all the problems of integration.
• You can give the implementation of the server to your partners involved in the development of server software.
• The customer may have his own team of server developers - as often happens in cases of cooperation with banks.

Whatever option you choose, unfortunately, often even a clearly defined specification of the server / client interaction protocol cannot provide correct integration. And you will have a simple, obvious problem: the client and server protocols do not match .

From the point of view of client development, this leads to the fact that the mobile application receives incorrect data. Or does not receive them at all.
If the architectural design is not “bulletproof” enough, and little time has been allocated for development, the application will “fall down”, display rubbish and generally behave ugly.
Accordingly, the correctness of the feedback is not guaranteed: who said that the serialized data from your application will be adequately recognized on the server?

How to be?

The first thing that comes to mind is the petty decision to adapt all the parsers and serializers in the mobile application to what is already coming from the server.
You get some JSON like this:

 {
	 data: {
		 “Field1”: “value1”,
		 “Filed2”: “value2”
	 }
 }

Instead of what is spelled out in the specification:

 {
	 data: {
		 “Entity”: {
 “Field1”: “value1”,
			 “Filed2”: “value2”
		 }
	 }
 }

Valuable information - “ field1 ” and “ field2 ” as it comes. So why not allow a little trick - read information from what has already been provided?
I have already mentioned the keyword " consistency ". Literally from English, " consistently perform " = " consistently perform, " in the sense that " adhere to a given line of conduct ."

For example, if a phenomenon was originally called a “ phenomenon ”, then it should be called a “ phenomenon ” in the documentation, and in the source code it should be a class “ Phenomenon ”, and in the coming JSONs it should have the key “ phenomenon ”.
When all project participants use the same glossary, this significantly reduces the risk of misunderstanding.
Sooner or later, someone from the developers may find a discrepancy in the documentation - and fix it. And on the other side of the system everything will collapse.
In addition, based on the documentation already written for the server, other clients can later be created for other mobile and, possibly, desktop platforms - and they will come across the same problems: the implementation does not match the documentation.
This will cause the system to crush and rot from the inside.

Solutions

http://apiary.io

A small service - very simple and rather limited in its functionality, but the same and attractive. It provides a mockup implementation of your API.
You get a unique URL on which you can set your mobile app. Included is a neat documentation on all implemented prototypical web services, plus the typical answers that should come from these web services.

For example, you need a server that will give a set of some Entity entities. The list of users, the list of restaurants, the list of ATMs is not important.
Each entity has its own ID, according to which the server should be able to provide detailed information about this entity.
Plus, the API must separately provide, say, service information - the timestamp field - the time of updating the entity with the specified ID.

So, we assume that we have:

Address

Service 1 :

• on a GET request gives a set of entities
• on POST-request gives confirmation of the addition of a new entity

Service 2 :

• on a GET request gives detailed information about the entity;
• on UPDATE-request gives confirmation of the update of the entity

(a small caveat: unfortunately, apiary.io does not allow implementing a full-fledged REST, therefore, it is unlikely that an updated entity will be sent to an UPDATE request).

Service 3 :

• on a GET request gives the date of the last update of the entity.

Etc.

An example of such a "server" is here .

The description of the layout services is extremely simple and declarative.
When creating a new layout API, you are immediately given an example:

 FORMAT: 1A
 HOST: http://www.application.com

 # application
 Notes API.

 # Group Notes
 Notes Notes **

 ## Notes Collection [/ notes]
 ### List all Notes [GET]
 + Response 200 (application / json)

         [{
           "id": 1, "title": "Jogging in park"
         }, {
           "id": 2, "title": "Pick-up posters from post-office"
         }]

 ### Create a Note [POST]
 + Request (application / json)

         {"title": "Buy cheese and bread for breakfast."  }

 + Response 201 (application / json)

         {"id": 3, "title": "Buy cheese and bread for breakfast."  }

This code describes the operation of the service that responds to GET and POST requests.

And the apiary.io service itself can act as a proxy. Through a single switch, you can redirect all traffic coming to the mock-up server to the “combat” back-end, without changing anything in the client’s source code.



It would seem that everything is fine, everything is beautiful, the service allows the team to work without blocking the process, provides a convenient scripting language ...
The problem is that, alas, it does not possess any special logic.
You can simulate the return of an entity depending on its ID, but in any case it will be a finite state machine that is not able to analyze the situation in any way - it has a slightly different purpose.


http://www.soapui.org
If you need to dig a little deeper - it does not matter. There is always an old, proven Soap UI.

SoapUI is a multitasking combine, initially designed and aimed at testing SOAP and REST services in automatic mode. Among other things, he himself is able to act as an appropriate server and provide layout data.

Instructions for action:

Create a project and cut out of it all unnecessary



Create a new layout REST service



Add action



Let the Entities list return



Adding layout data




Let the service return this list only by the presence of an authorization key.

Add the answer for the "unauthorized" user



Switch the Dispatch mode to the “SCRIPT” state and copy one of the following examples of checking the request parameters



Run (after checking the port in the service settings; the default is 8080)



Check




Everything, the model server is ready.

findings

Naturally, the above service is not the only one, and there are a number of its analogues, such as mockable.io , providing similar functionality.
Alas, most of these solutions usually lack flexibility in terms of implementing a full-fledged response to possible network requests.
There are not so many really functional and convenient services for creating layout APIs.
On the other hand, the simplicity of such solutions ensures their relatively rapid deployment, and at some stage in the implementation of the project this may be a decisive factor.
So, apiary.io may well be involved in creating a prototype or proof-of-concept-solution, and as the project evolves, you can already think about a subsequent move to more advanced services with logic, scripts ...
And there you look - already and the combat server is ready.

A separate article, of course, are the BAAS servers, but this is a slightly different story.

How do you solve integration problems?