对于如何设计好一个API，不同的人有不同的看法。
但是不管怎样，我们还是可以找到一些基本的切入点的。

1. 易理解性
   看到API很容易理解他是做什么的
2. 易实现性
   通过各种语言都可以很容易的实现
3. 稳定性
   对于业务的不断升级，API能保持稳定
4. 通用性
   能与当前已经存在的系统方便的对接
5. 扩展性
   能够很容易的扩展现在的API，并且不影响已经存在的API
6. 可描述性
   就是对现实世界的描述能力

所以基于上述几个点我们来分析一下现在流行的RESTful APIs。

易理解性

首先，我们看一下一下易理解性。
RESTful APIs的接口一般是这样的.

/users
/users/1
它简单，但是意义并不明确。
在没有了解RESTful APIs的情况下，并不容易理解。
那么相比较而言
/users/list
/users/item/1
会显得更加的语义明确
同时RESTful APIs的动作是基于HTTP方法的，让应用开发人员理解API的难度加大。
所以在易理解性方面，RESTful APIs的风格并不占优。

实用性

我们再来看看易实现性
RESTful APIs 的方法是基于HTTP方法的，所以要对HTTP协议有深刻的理解，并且理解如何正确的使用HTTP的方法。而大多数API是给应用使用的，这无形中增加了编写应用API的难度，增加了实现成本，也增加了出错的机率。虽然RESTful APIs的创始人是HTTP规范的推进者，但是我们应用开发者不宜跟进这种复杂，低效的设计理念，而值得学习的应该是TCP/IP的分层理念 。
RESTful APIs将网络层协议与应用层API结合的过于紧密，将会导致主次不分，增加问题的复杂度。

稳定性

RESTful APIs在稳定性方法还是比较好的。因为通过规范我们知道RESTful APIs主要用于资源描述，所以他能很好的保持资源与APIs的对应

通用性

如果RESTful APIs的操作是基于HTTP的方法的，但是RESTful APIs就没有任何的通用性可言。因此通用性是很差的。但是由于大部分的应用都是基于HTTP/HTTPS的，所以这个问题到显得并不突出。但是如果是游戏或者是流的协议呢？所以RESTful APIs并不具有较强的通用性

扩展性

RESTful APIs的APIs主要是用于描述资源的，所以扩展性基本上就无从谈起。因为资源本身是不具备扩展性的。但是因为单个API本身具有很强的独立性，所以对于新的资源具备一定的扩展性。

同时由于方法是基于HTTP的方法的，所以不具备快速扩展HTTP方法的可能性。

描述性

由于RESTful APIs是基于资源的表达的，而不是对现实业务的表达的。所以RESTful APIs不具备很强的描述性。
比如我们描述这样的场景：
用户登录
用户退出
对于RESTful APIs来讲，需要使用HTTP AUTH或者是OAUTH来实现，
显然是一个很搞笑的方法。
所以大多数情况，我们会看到很多的API是这样的：
user/login
user/logout.

结论

所以我们基于对上述几个要点的分析，我们可以看到：

针对于资源的操作，RESTful APIs相对适用，但是能力受限。
针对业务的操作，RESTful APIs力不从心，并不能很好的胜任。
Stateless 看上去很美，但是代价不小。

因此我们不能盲目的赞美RESTful APIs，要从实际出发，针对不同的业务场景，选择设计一个适合自己的API规范。

后面我们将进一步探讨如果实现一个良好的API，并且向大家推荐蛋蛋API规范。
也欢迎对API设计感兴趣的同学一起参加讨论。

如果对文章存在异议或者，欢迎点击阅读原文参加讨论。

Egg API规范地址： https://github.com/calidion/egg