我的同事最近老是抱怨我给的API非常的多，而且难以记住。
因为我的URL是这样的：
在传统的URL模式中，比如，我要参加某个活动，URL可能是POST：myapp.com.cn/1/api/12
然后，假如要获得参加计划的人的列表，URL可能是：POST：myapp.com.cn/1/api/13
这种方式显然不太妥。这是一个业务的增删改查，应该采用一个URL才可以。
我在写API的时候也遇到了这样的问题。一个增删改查会有好多的业务码。
实际上，应该使用GET方法来获取列表，使用POST来参加某个活动，使用DELETE来退出某个活动。
这才是REST风格。
真是只有经历过这些才知道人家为什么是对的啊！！！！！书本上的知识真的要去实践了，走走弯路，才知道什么是对的，什么是错的。就好像以前有人问我。数据验证是写在model层好还是controller层好。我告诉他，你每个都去试一下，自然就知道写在那个层比较好了。
但是现在我认为写在model层也并不是最好。直接分一个数据验证层才是好的。为什么？因为我实践过
回复内容：
我的同事最近老是抱怨我给的API非常的多，而且难以记住。
因为我的URL是这样的：
在传统的URL模式中，比如，我要参加某个活动，URL可能是POST：myapp.com.cn/1/api/12
然后，假如要获得参加计划的人的列表，URL可能是：POST：myapp.com.cn/1/api/13
这种方式显然不太妥。这是一个业务的增删改查，应该采用一个URL才可以。
我在写API的时候也遇到了这样的问题。一个增删改查会有好多的业务码。
实际上，应该使用GET方法来获取列表，使用POST来参加某个活动，使用DELETE来退出某个活动。
这才是REST风格。
真是只有经历过这些才知道人家为什么是对的啊！！！！！书本上的知识真的要去实践了，走走弯路，才知道什么是对的，什么是错的。就好像以前有人问我。数据验证是写在model层好还是controller层好。我告诉他，你每个都去试一下，自然就知道写在那个层比较好了。
但是现在我认为写在model层也并不是最好。直接分一个数据验证层才是好的。为什么？因为我实践过
看到有人没有正确理解表操作跟rest的关系，以下是我曾经在知乎回答过的一个问题，希望可以帮助理解
原题地址：http://www.zhihu.com/question/21662167/answer/18918959
楼主应该对REST有基本了解，所以基本概念我就不再重复，只说一下楼主比较糊涂的点 资源并不是对底层存储对象或者程序Model的直接映射 并不是说你有User表和Role表，就一定要设计对应的资源。 实际上RESTful资源和底层存储服务之间的关系类似于关系式数据库内的表和视图的关系，视图是根据实际查询需要组合多个表形成的关系集合。 无论你的存储服务到底是关系式数据库还是NoSQL数据库甚至文本文件，对于访问资源的客户端来说都是一样的。 所以创建一个用户，同时设置其角色，完全可以用POST /user直接完成 // 创建具有foo和bar两个角色的新用户 POST /user {name: (string), passwd: (string), roles: ['foo', 'bar']} // 如果response header能够包含以下两条最好 // 以201状态响应，用Location告知新资源url HTTP/1.1 201 Created Location: /user/1 // 修改用户的角色为foobar PUT /user/1 {roles: ['foobar']} // 修改用户的密码 PUT /user/1 {passwd: (string)} 至于/UserRoleRelation这样粒度比较小的资源，我建议先不要，资源的粒度应该是先粗后细，根据业务后续的演化和实际需要再考虑是否抽象更细粒度的资源，一开始就搞得太细的话，任何一次操作都会被分解为多次网络IO，且系统复杂度容易搞得比较高。 把具体的数据库表映射为资源，然后把CRUD动作对应到GET/POST/PUT/DELETE上，既傻又不安全，本来这些东西都是为业务服务，因为业务需求而存在的，结果抽象时却不围绕业务设计，这是本末倒置。 正确的思路应该是，忘记什么数据库和程序Model，只从HTTP的角度考虑，根据业务，需要设计哪些资源(url)，GET/POST时接受和响应哪些参数，把这些敲定之后，再从数据库和程序Model上去考虑如何配合。
我更推荐学习一下 Github 和 Dropbox 的 API 设计，个人觉得比 Twitter 要好。
唔，不了解的话，不应该先看别人是怎么做的吗，看看有没有成熟的方案，这是twitter的api结构，可以学习下。
https://dev.twitter.com/rest/public
前几天翻译的 用 JSON 构建 API 的标准指南：中文版
感谢 @bornkiller 协助翻译。
不知道你原来对于REST的理解是来源于哪本书，但多看书，同时还得看好书。
REST架构的提出者在08年写了一篇文章痛斥人们普遍对REST理解不足。而REST(Representational State Transfer/表述性状态转移)并不仅仅是HTTP协议中GET/POST/DELETE/PUT 与 DataTable中Create Read Update Delete操作的映射。
而人们之所以把RESTful理解成对表的CRUD，则可能是受到了Rails中对REST支持的影响而产生了误解。按Roy Fielding的说法，RESTful必须是超文本驱动（使用超媒体作为应用状态的引擎），但按他老人家的定义，那90%标榜REST的API都不能说自己是RESTful的，因此Richardson对REST模型做了一个分级，大部分的RESTful API集中在一级成熟度上，而Fielding论文中所描述的REST设计则属于Web-aware，分级模型中的三级。
因此在这里提醒下楼主，不是随便一个类似domain/Res/ID就能说自己是RESTful的。既然要玩REST，至少得看一次原著者的首倡论文吧，哪怕看的一知半解也不会设计出你描述中开头那段API。
顶楼主，实践出真知啊，就冲这个，不赞都不行。
