restful源码（基于restful）
本文目录一览：
- 1、如何根据UML模型设计和实现RESTful书签服务
- 2、怎么通过url向一个restful服务发出delete请求
- 3、基于RESTful API 怎么设计用户权限控制
- 4、如何判断wmts服务是kvp 格式还是restful
如何根据UML模型设计和实现RESTful书签服务
trufun plato uml建模工具官方授权i码邦解答uml问题restful源码，可以到i码邦社区提问restful源码，有专人解答。
i码邦——全球首发手机版专业Java编程神器。
IDE无需搭建环境，即时编译运行，有i码邦就够restful源码了；
教程源码restful源码：Java教程，源码分享，实战是提高能力restful源码的捷径；
问答社区：随时随地，有问必答！；
微课堂：每课一点，边讲解边实践，当堂消化，当堂掌握。
怎么通过url向一个restful服务发出delete请求
DELETE方法是用来删除URL所指定的资源的，作为HTTP协议规定的方法之一，当然可以被使用，只是需要注意下面的一些细节，避免系统设计意外。
1、具体实现上，服务器可能会有自己变通的处理方式，比如出于安全、数据完整性的考虑，把`删除`转义为`禁用`，毕竟删除数据是危险的，需要意识到这一点
2、提交DELETE请求时，不能包含Entity Body。排除传输编码的要求，Entity Body实际上就是HTTP消息体：
The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response.
The message-body differs from the entity-body only when a transfer-coding has been applied,
message-body = entity-body
| entity-body encoded as per Transfer-Encoding
对于GET/POST/PUT方法，传递Entity Body都不会有问题，但对于DELETE方法，由于该方法传递Entity Body没有明确定义的语义，所以有些服务器实现会丢弃/忽略DELETE请求的entity body，或者拒绝该请求。参见HTTP协议草稿（）4.3.5 DELETE章节：
A payload within a DELETE request message has no defined semantics;
sending a payload body on a DELETE request might cause some existing
implementations to reject the request.
注意（过时的）老版本的RFC2616（）里面没有特别说明这一点。
3、PUT/DELETE方法从语义上来讲，对资源是有破坏性的，PUT更改现有的资源，而DELETE摧毁一个资源，带有破坏性质的方法有时候会被防火墙或者IT管理人员特别关注，所以当提供PUT/DELETE接口服务时，需要确保服务器前置的防火墙没有block这些方法。当然如果走的是HTTPS协议，无需担心这一点。
java中使HttpDelete可以发送body信息
RESTful api中用到了DELETE方法，android开发的同事遇到了问题，使用HttpDelete执行DELETE操作的时候，不能携带body信息，研究了很久之后找到了解决方法。 我们查看httpclient-4.2.3的源码可以发现，methods包下面包含HttpGet, HttpPost, HttpPut, HttpDelete等类来实现http的常用操作。 其中，HttpPost继承自HttpEntityEnclosingRequestBase，HttpEntityEnclosingRequestBase类又实现了HttpEntityEnclosingRequest接口，实现了setEntity的方法。 而HttpDelete继承自HttpRequestBase，没有实现setEntity的方法，因此无法设置HttpEntity对象。 这样解决方法就明显了，我们可以自己实现一个MyHttpDelete类，继承自HttpEntityEnclosingRequestBase，覆盖其中的getMethod方法，使其返回“DELETE”。
public class MyHttpDelete extends HttpEntityEnclosingRequestBase {
public static final String METHOD_NAME = "DELETE";
public String getMethod() {
return METHOD_NAME;
}
public MyHttpDelete(final String uri) {
super();
setURI(URI.create(uri));
}
public MyHttpDelete(final URI uri) {
super();
setURI(uri);
}
public MyHttpDelete() {
super();
}
}
使用delete方法时，直接可以按下面方式操作
DefaultHttpClient httpClient = new DefaultHttpClient();
MyHttpDelete delete = new MyHttpDelete("");
ListNameValuePair nameValuePairs = new ArrayListNameValuePair();
delete.setEntity(new UrlEncodedFormEntity(nameValuePairs));
HttpResponse response = httpClient.execute(delete);
基于RESTful API 怎么设计用户权限控制
本文是基于RESTful描述restful源码的，需要你对这个有初步的restful源码了解。
RESTful是什么？
Representational State Transfer，简称REST，是Roy Fielding博士在2000年restful源码他的博士论文中提出来的一种软件架构风格。
REST比较重要的点是资源和状态转换，
所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。
而"状态转换"，则是把对应的HTTP协议里面，四个表示操作方式的动词分别对应四种基本操作：
1. GET，用来浏览(browse)资源
2. POST，用来新建(create)资源
3. PUT，用来更新(update)资源
4. DELETE，用来删除(delete)资源。
资源的分类及操作
清楚restful源码了资源的概念，然后再来对资源进行一下分类，restful源码我把资源分为下面三类：
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。
如何判断wmts服务是kvp 格式还是restful
一．rest + rest iserver自带的图层叠加范例,就属于这种场景，点击显示源码即可查看， 这里就不列出一一讲解了，注意两点就可以了，一是map的allOverlays属性设置为true;二是一定要使用异步加载的方法，即需要监听地图加载完成的事件
