Rest API,一种Web Service接口的风格，定义了规范和约束。主要偏向资源，而资源所指的就是我们页面中的
可控数据。而传统的SOAP所主要偏向的则是过程。而它们则成为了资源运输的管道，通过我们所编写的URI。而
应着两者偏向角度问题的不同，针对所它们设计的URI也会有所不同。
<URI并非绝对某种形式就是某种风格，只能说它的形式相对某种情形下定义了它是某种风格的产物>
关于URI和URL的概念，就是一个相对和绝对的资源标识。如果要深入了解，大家可以自己在到网上深入了解一下。
(如下是两者编写时所产生的URL)
---------------------SOAP----------------------
http://www.test.com/users/1/del
or
http://www.test.com/users?del=1
---------------------REST----------------------
[DELETE] http://www.test.com/users/1
因为SOAP偏向的是过程，因而我们所设计的URI，在当中我们可能需要提供或者说告知我们这个是什么功能。
而REST偏向的是资源，所以增、删、改、查，都与该资源无关。所以在上面我们没有看到对应的表示删除的del单词。
在了解这些内容以后，大致我们能够了解到的一个REST API命名的规范：只使用名词。
而我们说Rest作为一种规范和约束，它着重告诉我们的是我们在命名的时候应该要考虑的某些方面，它规范了
我们的思维，也拓宽了我们的思想。而非单单的使用名词去命名这么简单的就过去了的。
而如何去体现这个概念呢，下面是我在《伯乐在线》看到的博文的地址，我觉得挺实在的，大家可以看一下。
http://blog.jobbole.com/70511/
在此对《伯乐在线》以及本博文的作者JustinWu表示感谢。
当中我们可以看到，作者以实际的业务出发，引导我们去了解在设计API接口名称时候的思维。
而有了作者的参考，我们其实可以针对我们自身的需求去设计数据自身的规范和准则。
以下是我在了解完相关内容后设计命名的一些想法。
注意:删除操作应该杜绝通过规律性的编码去删除对应的数据，预防攻击。可以使用组合唯一的方式。
当然，删除操作是否需要也是需要斟酌的，因为用户数据是非常重要的。
[Method] [URI] [Remark]
[POST] /api/users 向user表中添加一条用户数据
[GET] /api/users 获取user表中所有的用户数据
[PUT] /api/users/1 修改user表中记录为1的用户数据
[GET] /api/users/1 获取user表中编号为1的用户数据
[GET] /api/users/1994/11/28 获取出生日期为1994/11/18的用户数据
[GET] /api/users/1/head_images 获取编号为1的用户的头像信息
[GET] /api/users/1/shops/1 获取编号为1的用户门店为1的门店信息
[DELETE] /api/users/139******34 删除user表中手机号码为139******34的用户数据
以上为个人理解的部分内容，以此与各位共勉，如果您有什么想法，请留言，我们一起进步，一起成长。
索易软件，感谢有您。
Rest API命名感悟
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
- 文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
- 文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
- 文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
