原文地址：http://u.10-tips-designing-your-mobile
在移动开发中，客户端通常需要一个基于Web云的API服务(Service)来实现C/S通信。最简化这些API的用例通常是获取(Read/Retrieve)云端数据，但并非局限于此，向云端发送数据、用户认证与管理等都可以基于该Web云服务实现。
你若想在你的移动端应用程序中，使用Web云API服务的话，下面10个坑是你应该知道的：
API可能在未来的任何时刻因为需求被添加、删除以及更改。这样就要求停用过时的接口，并通知接口用户，了解更改细节，比如响应类型。
你所构建的Web云服务接口就像是云端与其应用(app)用户所签订的契约，若没有一个合适的版本控制机制，云端修改了这个契约，而另一端可能永远也无法了解到。多版本机制可以让一个暂时无法升级到你最新版本API的接口用户继续使用原来的接口，而不必担心接口会很快地失效。
当Web云服务端更改接口时，没有版本控制的API就会无意地使应用无法工作，对相关应用的稳定性而言，大打折扣。
某种规模或程度下，应用端与服务端通信的数据量会影响请求生成时间与响应时间。这不仅会浪费人们宝贵的时间来看着屏幕上的Loading动画，也会让用户在数据量上花费更多。
为了减少返回数据的冗余量，压缩发送的数据将有益于通信速度与花费。
在设计API时，通常需要将一个请求分成几个间断的步骤，来反映出它时如何被使用的。但是，分散的步骤并非移动应用最高效的实现方式。
这里由一个简单的例子：想象这么一个问题，一个用户在发送一个数据请求并能获取响应之前，必须先将其写入日志。一个合理明了的答案如下两个步骤：
- 验证证书，若通过，则该接口则产生一个Session位(Token，你有更好的翻译就告诉我)
- 当请求产生数据后，Session也被传送过去
但通常，并不需要做到此种地步。一种更优的方法是，当单个请求到达服务端时就传送证书以及所需要的数据，在验证证书时，把相关数据以及Seesion位也一道返回，做之后之用。
这么做的好处是一部分请求会更快、更容易，也会简化程序代码。
你必须尽可能多的考虑所会用到的使用场景，这样就需要更多的文档和支持。不过，如果你的API仅仅(或主要)作为内部使用，这仍然可以接受。
在一个认证或应用初始化进程中，通常含有多条网络请求，这时，通常会把这些请求所获取的所有数据显示到单个页面或一个应用的单个视图(view)上。将一个页面或视图所需要的多个请求，合并成一个网络请求能让总响应时间更快、代价更小。在使用该应用时，优化效果显而易见。
另外，这也将让软件代码更简单易读，尤其是考虑到，当多条请求被发送后，并且只有部分成功返回时，合并请求对于代码易读性的效果将显而易见。若变为没有或者全部成功返回的场景，会使代码更加简洁。
下面将讨论一个富有挑战，也颇具能量的话题——安全。对于一个安全问题，能够及时地反应过来使尤为困难的。
记住考虑以下部分：保护在传输中的数据、保护你的闲置数据、API的无权限/不当使用、恶意/意外数据有机会获取意外序列。
若你某个API返回的数据并非经常改变，就需要劳心实现一个恰当的缓存机制，这样就需要将相关数据保存在内存(RAM)中，来取代反复的磁盘读取操作。这些将涉及到HTTP 中缓存容量的问题。（我们假设你使用HTTP协议来进行C/S通讯）
如果你要在你的服务器上实现缓存，最好也提供一个可以清空缓存的接口来保证数据的准确性。
在客户端，你同样也需要保证此缓存机制能让API调用者(Client)们能正常工作。在用户调用一个API，并被告知使用了上次返回的数据，那么用户和你都可以节省掉一定的时间与资源，若能连那个API调用都省掉，那么就能节约更多的时间与资源。
要了解一个应用如何被使用的一个重要环节即是分析。对于大部分的接口，分析服务都是必不可少的，只有那些已经投入正常使用的接口除外。比如，假设一个应用(app)设法调用API服务器来刷新在一个客户端页面的数据，当一个用户操作这个页面时，在添加一个分离的追踪/分析调用来追踪用户操作时，会生成部分冗余的数据。
最开始，API的使用就表征一个应用程序如何以及何时被使用，在一些其它规模的软件架构中，存在很多丰富的分析工具与框架来获取用户与应用(app)交互的很多详细的数据信息，然后你可以通过分析这些数据，来仔细考虑这些额外的接口调用如何/是否满足追踪用例的目的。
在API中的方法(Methods)、对象(Objects)、属性(Properties)和参数(Parameters)的命名会极大地影响用户理解你的API，在你第一次命名API，首先就能想到某些术语与用法，这件事本身就很有吸引力。像所有的代码一样，你所使用的单词对于使用者如何理解API及其行为，占据了十分重要的部分。一个拥有糟糕命名的API将是一个伟大的代码混淆。混淆就会产生错误，错误就会导致Bug，Bug就会让进度拖延，以及额外的开发代价。因此，花点时间来好好考虑API的名字吧。
如果你在获取用户数据(或者你的服务器记录了请求数据)，你就应当设计一个隐私机制来描述如何使用这些数据。同样你也需要考虑如何存储或保护那些数据，尤其是当那些数据是私人数据或属于/相关于某些人的时候，隐私保护尤为重要。