restfulRESTful API 怎么实现用户权限控制

restful api 一般怎么测试

定义了RestFul Api，必须先做单元测试，确保Api可用，然后再交给别人去调用，这样才能确保工作进度 （1）使用Apache的jmeter测试工具，很方便，可以批量测试Api， (2) 使用JerseyClient写测试程序。

因为我们用的是jersey实现的RestFul。

(3) 使用浏览器插件工具，我用的是火狐的插件RESTClient （4）使用curl命令行工具。

使用工具测试Api，GET方法还好，如果是POST方法需要指定方法的Headers(数据格式),Body（请求参数），Api的url。

Body请求参数，如何获取呢，在这里我使用了Gson，先用java组织参数对象，然后用Gson将参数对象转化为json串。

Gson gson = new Gson(); String wqtString = gson.toJson(wqt); System.out.println(wqtString) 举例说明： 我们框架中封装了一个查询参数WebQueryTerm。

我获取到它的json串格式为： {"page":{"number":1,"size":10,"total":0,"sorts":[{"field":"creationTime","type":"DESC"}]},"terms":[{"field":"appType","operator":"equal","value":"0"}]} 其中 page表示分页属性。

number当前页，size一页显示多少条数据， sorts排序：field表示排序字段。

type表示排序类型，是desc降序还是asc升序 terms表示查询。

field表示查询字段；operator表示是模糊查询Like还是精确查询Equal，value表示你输入的查询值。

追答 这里简单说一下，怎么使用火狐的RESTClient。

(1)首先，在火狐浏览器菜单-附件组件-插件，中搜索RESTClient，并安装 (2)打开RESTClient，点击菜单Headers。

输入自定义Request Headers。

例如Name = Content-Type Value=application/json 点击okay！ （3）选择Method，我选择Post，因为我测试获取应用列表，带分页，带查询条件。

（4）输入api资源的url：http://192.168.1.183:8080/osd/rest/app/get_app_list （5）输入上面的请求参数json串。

(6)点击Send请求API。

结果查看：Response Headers如果Status Code =200 ok则表明API没有异常 再看Response Body返回数据，是否满足你的要求。

测试工作完成！

restful api 怎么用

web api文档工具列表 swagger ——swagger框架可以通过代码生成漂亮的在线api，甚至可以提供运行示例。

支持scala、java、javascript、ruby、php甚至 actionscript 3。

在线 demo 。

i/o docs ——i/o docs是一个用于restful web apis的交互式文档系统。

使用 json 模型根据资源、方法和参数定义 apis。

i/o docs 将生成 javascript 客户端接口，可通过这些接口来调用系统。

服务器端基于 node.js 开发。

在线demo apiary.io ——能够快速启动和运行文档，包括github集成和i/o验证——更多建议可以前往reddit查看上关于 siyfion讨论。

o ——o是一个快速而随意、hundred-line-long、迭代程序风格的文档生成器。

它会以html的方式显示评论和代码。

dexy ——非常灵活的一款文档工具，支持任何语言编写的api。

doxygen ——doxgen可以从一套归档源文件开始，生成html格式的在线类浏览器，或离线的latex、rtf参考手册。

对于未归档的源文件，也可以通过配置doxygen来提取代码结构。

更多建议可以前往reddi上查看 gkumar007相关讨论。

turnapi ——是一款付费的文档api工具。

里面包含了智能wiki编辑器、基于标准的markdown、文档分支、还可以与git、svn、mercurial同步、整洁的主题、友好的界面。

以上仅是作者在实践中发现的一些很好的工具，如果你有更好的建议或工具推荐，欢迎与我们分享。

什么是标准的 restful apl

REST不是一个标准，而是一种软件应用架构风格。

基于SOAP的Web服务采用RPC架构，如果说RPC是一种面向操作的架构风格，而REST则是一种面向资源的架构风格。

REST是目前业界更为推崇的构建新一代Web服务（或者Web API）的架构风格。

由于REST仅仅是一种价格风格，所以它是与具体的技术平台无关的，也就是说采用REST架构的应用未必一定建立在Web之上.

RESTFul API 在安全方面需要注意什么

大方向无非是： 敏感信息走 HTTPS 加密连接。

API 缓存的意义不大，其实最好是全部走 HTTPS。

防范 XSS 跨站攻击，毕竟还是 HTTP 协议 防范 DDoS 攻击（比如通过访问频率限制）

WebService为什么不如RESTful API流行

REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。

REST提出设计概念和准则为： 1.网络上的所有事物都可以被抽象为资源(resource) 2.每一个资源都有唯一的资源标识(resource identifier)，对资源的操作不会改变这些标识 3.所有的操作都是无状态的

RESTful API 怎么实现用户权限控制

本文是基于RESTful描述的，需要你对这个有初步的了解。

RESTful是什么？ Representational State Transfer，简称REST，是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。

REST比较重要的点是资源和状态转换， 所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。

它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。

而"状态转换"，则是把对应的HTTP协议里面，四个表示操作方式的动词分别对应四种基本操作： 1. GET，用来浏览(browse)资源 2. POST，用来新建(create)资源 3. PUT，用来更新(update)资源 4. DELETE，用来删除(delete)资源。

资源的分类及操作 清楚了资源的概念，然后再来对资源进行一下分类，我把资源分为下面三类： 1. 私人资源 (Personal Source) 2. 角色资源 (Roles Source) 3. 公共资源 (Public Source) "私人资源"：是属于某一个用户所有的资源，只有用户本人才能操作，其他用户不能操作。

例如用户的个人信息、订单、收货地址等等。

"角色资源"：与私人资源不同，角色资源范畴更大，一个角色可以对应多个人，也就是一群人。

如果给某角色分配了权限，那么只有身为该角色的用户才能拥有这些权限。

例如系统资源只能够管理员操作，一般用户不能操作。

"公共资源"：所有人无论角色都能够访问并操作的资源。

而对资源的操作，无非就是分为四种： 1. 浏览 (browse) 2. 新增 (create) 3. 更新 (update) 4. 删除 (delete) 角色、用户、权限之间的关系 角色和用户的概念，自不用多说，大家都懂，但是权限的概念需要提一提。

"权限"，就是资源与操作的一套组合，例如"增加用户"是一种权限，"删除用户"是一种权限，所以对于一种资源所对应的权限有且只有四种。

角色与用户的关系：一个角色对应一群用户，一个用户也可以扮演多个角色，所以它们是多对多的关系。

角色与权限的关系：一个角色拥有一堆权限，一个权限却只能属于一个角色，所以它们是一(角色)对多(权限)的关系 权限与用户的关系：由于一个用户可以扮演多个角色，一个角色拥有多个权限，所以用户与权限是间接的多对多关系。

需要注意两种特别情况： 1. 私人资源与用户的关系，一种私人资源对应的四种权限只能属于一个用户，所以这种情况下，用户和权限是一(用户)对多(权限)的关系。

2. 超级管理员的角色，这个角色是神一般的存在，能无视一切阻碍，对所有资源拥有绝对权限，甭管你是私人资源还是角色资源。

数据库表的设计 角色、用户、权限的模型应该怎么样设计，才能满足它们之间的关系？ 对上图的一些关键字段进行说明： Source name: 资源的名称，也就是其他模型的名称，例如：user、role等等。

identity: 资源的唯一标识，可以像uuid，shortid这些字符串，也可以是model的名称。

permissions : 一种资源对应有四种权限，分别对这种资源的browse、create、update、delete Permission source : 该权限对应的资源，也就是Source的某一条记录的唯一标识 action ：对应资源的操作，只能是browse、create、update、delete四个之一 relation：用来标记该权限是属于私人的，还是角色的，用于OwnerPolicy检测 roles: 拥有该权限的角色 Role users : 角色所对应的用户群，一个角色可以对应多个用户 permissions: 权限列表，一个角色拥有多项权利 User createBy : 该记录的拥有者，在user标里，一般等于该记录的唯一标识，这一属性用于OwnerPolicy的检测，其他私有资源的模型设计，也需要加上这一字段来标识资源的拥有者。

roles : 用户所拥有的角色 策略/过滤器 在sails下称为策略(Policy)，在java SSH下称为过滤器(Filter)，无论名称如何，他们工作原理是大同小异的，主要是在一条HTTP请求访问一个Controller下的action 之前进行检测。

所以在这一层，我们可以自定义一些策略/过滤器来实现权限控制。

为行文方便，下面姑且允许我使用策略这一词。

*策略 (Policy) * 下面排版顺序对应Policy的运行顺序 SessionAuthPolicy： 检测用户是否已经登录，用户登录是进行下面检测的前提。

SourcePolicy： 检测访问的资源是否存在，主要检测Source表的记录 PermissionPolicy： 检测该用户所属的角色，是否有对所访问资源进行对应操作的权限。

OwnerPolicy： 如果所访问的资源属于私人资源，则检测当前用户是否该资源的拥有者。

如果通过所有policy的检测，则把请求转发到目标action。