回复内容：
楼主应该对rest有基本了解，所以基本概念我就不再重复，只说一下楼主比较糊涂的点资源并不是对底层存储对象或者程序model的直接映射并不是说你有user表和role表，就一定要设计对应的资源。实际上restful资源和底层存储服务之间的关系类似于关系式数据库内的表和视图的关系，视图是根据实际查询需要组合多个表形成的关系集合。无论你的存储服务到底是关系式数据库还是nosql数据库甚至文本文件，对于访问资源的客户端来说都是一样的。所以创建一个用户，同时设置其角色，完全可以用post /user直接完成// 创建具有foo和bar两个角色的新用户post /user{name: (string), passwd: (string), roles: [‘foo’, ‘bar’]}// 如果response header能够包含以下两条最好// 以201状态响应，用location告知新资源urlhttp/1.1 201 createdlocation: /user/1———————————————————// 修改用户的角色为foobarput /user/1{roles: [‘foobar’]}———————————————————// 修改用户的密码put /user/1{passwd: (string)}至于/userrolerelation这样粒度比较小的资源，我建议先不要，资源的粒度应该是先粗后细，根据业务后续的演化和实际需要再考虑是否抽象更细粒度的资源，一开始就搞得太细的话，任何一次操作都会被分解为多次网络io，且系统复杂度容易搞得比较高。把具体的数据库表映射为资源，然后把crud动作对应到get/post/put/delete上，既傻又不安全，本来这些东西都是为业务服务，因为业务需求而存在的，结果抽象时却不围绕业务设计，这是本末倒置。正确的思路应该是，忘记什么数据库和程序model，只从http的角度考虑，根据业务，需要设计哪些资源(url)，get/post时接受和响应哪些参数，把这些敲定之后，再从数据库和程序model上去考虑如何配合。
lynda上有视频教程，教你怎么设计restful api，还是不错的effective design of restful apis
从现在已有的框架来看，对资源的操作一般都是映射到对象方法上的。对资源的设计是粗粒度的，而不是从底层数据库出发来设计资源。用成熟的框架来完成restful设计，一般还是资源-对象-关系数据库，之间包含了两层映射。
楼上说的在理,restful 系统设计应该从业务出发，而不应该从底层数据库出发。先构思你系统当中业务范畴与功能 ，然后在将数据库crud归入业务操作，考虑数据库如何去配合业务流程。