Issues that should be considered in mobile App Server API design

In the 2014, the popularity of mobile apps did not fade, and was not replaced by Web sites like desktop software.
Not only that, more and more traditional applications, websites are also beginning to make their own mobile apps, which we often say iOS client, Android client.
This seems to be back to the CS architecture years ago, when we use VB, VC, Delphi on the Windows platform to develop a variety of applications quickly.
The difference is that today's mobile app is basically a network of data from the server side, the client is just a simple presentation layer of tools.

Not just mobile apps, including service-oriented SOA architectures, require a unified, prescriptive interface
So what are some of the issues that need to be noticed when doing such a backend interface?

1. Cross-platform

The so-called cross-platform refers to our interface to be able to support different terminals, such as Android, iOS, WindowsPhone and desktop software, websites, etc.
A set of interfaces that support multiple, "Write once,run Anywhere" as in the Java slogan of the year.
Of course, the server-side interface is not much related to the terminal, but the interface should take into account the different end of the cost of access,
Using a common solution, such as communication protocol, the most commonly used HTTP protocol, if it is instant communication, can adopt the Open XMPP protocol,
The game can be done using a reliable TCP protocol, unless TCP is not enough, then the use of custom UDP protocol.
Data exchange takes the form of XML or JSON, and so on.
In short, the goal is to make it easy for different ends to use your interface.

2. Good response speed

If you want to use an indicator to measure the performance of the interface, then I think the most important thing is the speed of response.
The interface should return the data to the requestor at the fastest speed.
Imagine, when we open a page, if "Try to load in" the kind of hint more than 35 seconds,
We're going to get impatient, and the mobile app is mostly used by users in a fragmented time,
In a limited time, users can not wait to get more information, even if your app interface design is better, users will not buy.

Improving responsiveness is a commonplace problem, and should generally be done in the following steps:
Initially, to function-oriented, to ensure that the function is complete, to meet business needs, this stage can use dynamic language, such as Java, PHP, ASP.
With well-designed database structure and index, can meet a certain demand;
Second, with the increasing number of users, there are some caching scenarios that can be considered, and caching is a balm to solve performance problems, often with an immediate effect.
The most commonly used static file cache, memcached memory cache, and so on.
Then, the throughput rate of a single machine is not, and the load balancer adds several more machines on the line. Seven or eight machines, it is feasible to support the interface call of tens every day.
Alternatively, a CDN solution is used to deliver the vast majority of static resources to the CDN.

In short, to achieve the goal is fast, a page, seconds to open the best, more than three seconds to find out why.

3, the interface for mobile clients to consider

Interface is not only to provide data and function is finished, but also should fully consider the characteristics of the mobile side, for the mobile side to provide a more convenient and fast interface.
For example, in the mobile side, the drop-down refresh and pull-up load are more common features, if the interface still follow the traditional web thinking,
Providing only read-by-page results in additional data requests and calculations on the mobile side. In this case, the interface should provide additional support for both types of operations.

For example, for a news reader app, the latest news list of articles, especially the first few, users can easily click to see,
And then the old list of articles, a user slide to load several pages of the situation is less, and the more outdated news users are very few points.
If, when the interface returns to the news list, for the latest list, the body of the article (or part of the body, such as the content of a screen) can be passed directly to the client.
This way, when the user opens the News detail page, it is no longer available from the server side, which can be opened in seconds.

For example, when accessing the first page, the interface can return the article content, as shown below, content=1 to load the article content
Newslist?page=1&pagesize=20&content=1
Other pages, newslist?page=5&pagesize=20&content=0, do not load the article content.

Of course, the client should be well with the interface, collocation, to maximize performance.
For example, the mobile side has left and right slide to see the previous, next article or the function of the picture,
If, when a user requests an article, the server side also returns the contents of the next article,

So when the user looks at the next article, is not very soon.

Of course, this preload scheme can not be abused, if the pre-loading data hit rate is lower, also not, wasted a lot of traffic.

4. Consider the network situation and power consumption of the mobile terminal

If you let us say which kind of app is better, it may not be enough, but if you let us say which apps are bad,
We will definitely say those apps that are big, memory-intensive, interface-friendly, and cost-consuming.

For mobile app developers, network traffic and battery power are issues that have to be considered.
However, you might say that this has nothing to do with the interface, the server-side interface can also control the client's network traffic and power?

For network conditions, the interface should have the ability to provide different content for different networks,
Generally, the mobile internet is nothing more than 2G (GSM, GPRS, EDGE), 3G (CDMA, TDSCDMA, WCDMA), WIFI,
Imagine if your app gives users a video, audio, a lot of pictures without notifying the user if the traffic is going to cost them.
Users will think, after all, the domestic traffic costs are still very expensive.
Also take the above news list interface as an example, if we can know the user's network situation, only in the case of WiFi to the user to transfer cover, thumbnails and the like,
is not able to help users save a lot of traffic it.
Newslist?page=1&pagesize=20&content=1&network=wifi

For power, first we need to figure out which aspects of the app will consume power.
For example, the app has a lot of calculations, a very dazzling visual image will consume power, in addition, the constant mobile network links will also consume a lot of power,
We all know that mobile networks communicate through radio waves, so the launcher needs to consume a certain amount of power to transmit and receive wireless signals.
In particular, frequent links constantly switch between network devices and mobile base stations, which consumes a fraction of the power.

Therefore, for the interface, as far as possible to transfer more data with fewer links,
For example, for us, version updates, and some system configuration information, you can completely return to the client through a single link.

5. Universal Data Interchange Format

Currently, the data Interchange format for interfaces and clients is basically two, XML and JSON, which should now be used for most of the JSON.
The data exchanged consists of two kinds of parameters that are passed when the client requests the server-side interface, and that is the data returned to the client by the server side.

For the request parameters of the client, more and more interfaces are now required to be in JSON format, rather than the most common key_value in the past.
For example, an interface requires username and password two parameters
The way to Key_value pair is:
Username=hutuseng&password=hutusengpwd
It is then sent via Get or post.
In the case of data exchange via JSON, the format is as follows and is directly post to the server side.
{
' username ': ' Hutuseng ',
' Password ': ' Hutusengpwd '
}

There are two questions to note about the JSON data format returned by the server side:
One is the Chinese character coding problem, because the JSON (JavaScript) internally supports Unicode encoding, which converts Chinese characters into Unicode encoding to save
So in the return results, for Chinese, you can output Chinese directly, you can also output the Unicode encoding of Chinese,
The JSON parser will parse nicely.
For example, the following two ways are possible.
{"Code": "208", "Data": "\u53c2\u6570\u4e0d\u5b8c\u6574"}
{
"Code": "208",
"Data": "parameter is incomplete"
}
The second is the data type of the field, especially the number type, in JSON, as far as possible into the number format,
Like what
{
' UserID ': 128
}
Do not write
{
' userid ': ' 128 '
}

6. Interface Statistic function

In the PC-side website, we will add a statistical function to our website, or write their own statistical system, or use third-party such as GA, Baidu and so on.
The Mobile interface API requires us to implement our own statistical functions,
At this point we need to collect as much as possible the client's information, in addition to the traditional IP, user-agent, but also should collect some mobile-related information,
Like what
Mobile OS, Android or iOS, what are the versions,
The network condition that the user uses, is 2G, 3G, 4G or WiFi
What version information the client app is.

This will help us to better understand the use of our users.

7, the client and the service side of the Feishou balance

In the previous C/S, b/s structure, we have discussed this problem many times, the client is thin point good or fat point good, of course, there is no fixed answer, need their own according to the actual situation to do trade-offs.
However, in mobile development, client-side modifications can be time-consuming, especially if iOS apps are audited by Apple
In addition, the current human cost of iOS developers, Android developers is generally high, talent shortage,
Based on these two points, can be implemented on the server side of the function should not be placed on the client, after all, the server-side program modification is more convenient, flexible, faster than the client.

8. Implicit user and explicit user

Explicit user and implicit user, I don't know whether these two words are used exactly.
Explicit user refers to the user system in the app, a username, password the correct legitimate user, called the explicit user,
Usually explicit users are required to sign up and can perform some personal-related actions after logging in.

Implicit users mean that the app itself does not have a user system, or a user who uses our app without logging in.
In this case, the UDID generated by the client can be used to identify a user.

With user information, we are able to understand the usage habits of different users, not just the overall statistics of all users,
With the information of these individuals, you can do some user grouping, personalized recommendations and other things.

9, security issues

Network security has shifted from the desktop Internet to the mobile Internet, from the client to the interface API.

The traditional impregnable web site is likely to be compromised by a bit of negligence on the interface. Now, in many white hats or hacking ideas,

First look at the mobile interface whether there is a vulnerability, and then see if the site is vulnerable.

Client app communication with the interface is easy to get, just sniff it on the middle route.
Such tools as Whireshark and tcpdump make the job easier.

So, the security of the interface can not be sloppy, brute force, ah, SQL injection AH, forged requests and data Ah, repeated submissions AH also to consider,
If the data is particularly sensitive, you can consider the use of SSL/TLS, such as encrypted transmission, or the client, server-side contract an encryption algorithm and key, the data transmitted to and from the encryption, decryption
If you do not adopt a restful API, you can take security measures for Web service based on WSDL and soap.

10. Good interface documentation and test procedures

The interface documentation is sometimes set at the beginning of the project, and the front and back developers are developed according to the interface specification,
Some are written after the completion of the interface development.
The interface document should be clear and unambiguous, including the number of interfaces, the address of each interface, parameters, request method, data Interchange format, return value, etc. must be written clearly.

Interface test procedures, if available, can also be provided, convenient debugging of the front and back.

11, the maintenance of the version

As business changes, client apps and server-side APIs change, adding new functionality, modifying existing functionality,
Add function Fortunately, if the interface needs to be modified, then it faces the same interface to serve different versions of the client at the same time.
Therefore, the server-side interface should also be done with the corresponding version maintenance.

Issues that should be considered in mobile App Server API design