restful

Restful API 简单示例--HelloWorld 1. 环境 (1). j2ee luna (2). Tomcat7 (3). Jersey2.24 (jaxrs-ri-2.24.zip) 2. 流程 (1). 创建DynamicWebProj, eg: RestfulWs_01 (2). 解压jaxrs-ri-2.24.zip,将api/ext/lib文件价下的jar拷贝到WEB-INF/lib下 (3). 新建包com.tsh.rest.resources (4). 创建类 package com.waylau.rest.resources; import javax.ws.rs.GET; import javax.ws.rs.Path; import javax.ws.rs.PathParam; import javax.ws.rs.Produces; import javax.ws.rs.core.MediaType; @Path("/hello") public class HelloResource { @GET @Produces(MediaType.TEXT_PLAIN) public String sayHello() { return "Hello world from tsh"; } @GET @Path("/{param}") @Produces(

# REST: 表征性状态转移(Representational State Transfer) # RESTful规范：web数据请求接口设计规范 ''' 1）通常使用https请求 2）域名：有api关键字出现 -- https://api.example.com (存在跨域问题) -- https://example.com/api 3）版本：不同版本需要标注 -- https://example.com/api/v1 | -- https://example.com/api/1 -- https://example.com/api/v2 | -- https://example.com/api/2 4）资源：请求的目标数据称之为资源，资源一般都有名词复数表示 -- https://example.com/api/v1/books (之前不规范的案例: /get_books/) 5）操作方式：不从请求链接体现操作方式，从请求方式上决定操作方式 -- get：https://example.com/api/v1/books 获取所有 -- post：https://example.com/api/v1/books 新增一本 -- put：https://example.com/api/v1/book/1 更新id=1的一本 -- patch：https://example

RESTful介绍 REST与技术无关，代表的是一种软件架构风格，REST是Representational State Transfer的简称，中文翻译为“表征状态转移”或“表现层状态转化”。 推荐阅读 阮一峰 理解RESTful架构 RESTful API设计指南 API与用户的通信协议 总是使用 HTTPs协议 。 域名 https://api.example.com https://example.org/api/ 版本 1. 将版本信息放在URL中，如：https://api.example.com/v1/ 2. 将版本信息放在请求头中。 路径 视网络上任何东西都是资源，均使用名词表示（可复数） https://api.example.com/v1/zoos https://api.example.com/v1/animals https://api.example.com/v1/employees method GET ：从服务器取出资源（一项或多项） POST ：在服务器新建一个资源 PUT ：在服务器更新资源（客户端提供改变后的完整资源） PATCH ：在服务器更新资源（客户端提供改变的属性） DELETE ：从服务器删除资源 过滤 通过在url上传参的形式传递搜索条件 https://api.example.com/v1/zoos?limit=10

之前讲了RESTful API 的统一资源接口这个约束，里面提到了资源是通过URI来进行识别的，每个资源都有自己的URI。URI里还涉及到资源的名称，而针对资源的名称却没有一个标准来进行规范，但是业界还是有一些最佳实践的。那么我们首先看看这些最佳实践对资源命名是如何建议的。 资源命名 下面让我们来看看 RESTful API 资源命名的一些最佳实践。 使用名词，而不是动词 一个资源的URI代表的是一个实际上或概念上存在的东西，因此，它应该是名词，所以也就不应该出现动词，动词应该使用HTTP方法来表达。 需求 ： 我们看这样一个需求的例子：“我想获得系统里所有的用户”。 常见错误做法 ： 你可能把API的URI设计成这样：api / getusers。这样的设计是不好的，因为里面出现了一个动词get。 分析 ： 这个句话的主要动词就是“获取”，而想要获取的资源（也就是主要的名词）是“用户”。 正确的做法 ： 需求里面主要的动词应该通过HTTP方法来体现，“获取”对应的HTTP方法就是GET。而“用户”这个资源可以用英文user或者users来表示（是否使用复数一直存在争议，两种方法都行，但你在使用的时候需要保持一致）。所以正确的uri应该是 GET api / user。 人类能读懂 还是上面那个需求：“我想获得系统里所有的用户”。 我们可以把uri设计成 api/u 或者 api

1 什么是 RESTful 百度一下 RESTful，查到的资料很多都讲得不清楚，看完了都不知道说的是啥，导致很多人对 RESTful 不甚了解。来看一下常见的解释： （1）神一样的描述 REST 并不是“休息”的意思，而是 Representational State Transfer 的简称，即 表现层状态转移。 “表现层状态转移”是什么鬼？ （2）云里雾里的描述 REST 指的是 一组架构约束条件和原则，如果一个架构符合 REST 的约束条件和原则，就称之为 RESTful 架构。 RESTful 是一种软件架构风格，而不是标准。 这能看懂一点了，但还是云里雾里的。 （3）大神的总结 再看知乎大神 Ivony 的一句话精辟概括： 用 URL 定位资源，用 HTTP 动词（GET，POST，DELETE，PUT）描述操作。 RESTful 是一种 web 服务设计风格，风格意思就是大家默认的但不是强制的。 2 RESTful 详解 2.1 用 URL 定位资源 REST 的主体是资源，所谓“资源”，就是网络上的一个具体信息，例如：一张图片，一段文字、一种服务。总之就是一个实际存在的东西，而 URL 就是用来指向这个资源的。 例如： https://api.example.com/users 这个 URL 一看就知道是对 user 资源的操作。URL 中只使用名词来指定资源

接口抽象 RESTful Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 来抽象所有 Web 系统的服务能力，而不同的是，SOAP 应用都通过定义自己个性化的接口方法来抽象 Web 服务，这更像我们经常谈到的 RPC。例如本例中的 getUserList 与 getUserByName 方法。 RESTful Web 服务使用标准的 HTTP 方法优势，从大的方面来讲：标准化的 HTTP 操作方法，结合其他的标准化技术，如 URI，HTML，XML 等，将会极大提高系统与系统之间整合的互操作能力。尤其在 Web 应用领域，RESTful Web 服务所表达的这种抽象能力更加贴近 Web 本身的工作方式，也更加自然。 同时，使用标准 HTTP 方法实现的 RRESTful Web 服务也带来了 HTTP 方法本身的一些优势： 无状态性（Stateless） HTTP 协议从本质上说是一种无状态的协议，客户端发出的 HTTP 请求之间可以相互隔离，不存在相互的状态依赖。基于 HTTP 的 ROA，以非常自然的方式来实现无状态服务请求处理逻辑。对于分布式的应用而言，任意给定的两个服务请求 Request 1 与 Request 2, 由于它们之间并没有相互之间的状态依赖，就不需要对它们进行相互协作处理，其结果是：Request 1 与 Request

一、REST简单介绍 REST代表Representational State Transfer，是一种URI风格，是一组架构约束条件和原则。REST风格服务调用就是解析URL请求，将请求由逻辑构建处理，并将处理结果返回给前端的一种调用形式。这个风格被广泛用于微服务系统之间的交互，一般前后端分离的项目采用这种风格，而不是一种标准。总结来说rest设计规范通过URL表示接口名，HTTP请求方式来区分请求类型，同时前端根据HTTP状态响应做相应的操作 二、URI介绍 URI:统一资源定位符（Uniform Resource Locator），资源（Resource）就是网络上的一个实体，或者说是网络上的一个具体信息，每一个资源类和其资源实体都可以用一个URI地址来唯一标识，比如https://cnblogs.com标识博客资源类，https://cnblogs.com/p/2478932.html表示一个唯一的博客资源实体，它的资源类是cnblogs.com，资源实体表示就是2478932 对资源类和对资源实体的访问和操作被称为资源请求（ResourceRequest），请求中包含要访问的资源类、资源实体（可选）以及资源动作。如上所述，资源类和资源实体可以由一个唯一的URI表示，而资源动作（即对资源增删改查）则需要用方法（Method）和参数（Param）表示。 基于资源的请求示例

1.7 RESTful 风格 1.7.1 RESTful 风格介绍 RESTful 是一种软件架构风格！ RESTful 架构风格规定，数据的元操作，即 CRUD(create, read, update 和 delete, 即数据的 增删查改 ) 操作，分别对应于 HTTP 方法： GET 用来获取资源， POST 用来新建资源（也可以用于更新资源）， PUT 用来更新资源， DELETE 用来删除资源， 这样就统一了数据操作的接口，仅通过 HTTP 方法，就可以完成对数据的所有增删查改 工作 1.7.2 RESTful 接口设计 HTTP 协议请求方法 SpringBoot 注解 URL 功能说明 POST @PostMapping /users 创建一个用户 GET @GetMapping /users 查询用户列表 GET @GetMapping /users/id 根据 id 查询一个用户 PUT @PutMapping /users/id 根据 id 更新一个用户 DELETE @DeleteMapping /users/id 根据 id 删除一个用户 来源： https://www.cnblogs.com/lulli/p/11854643.html

简介 在前后端分离的开发模式中，后端（服务器端）的主要任务是通过API给UI前端提供数据，前端主要负责数据的展示，前后端的交互主要通过API接口。目前，最好的接口的实现方式是通过RESTful来实现前后端解耦合。后端(服务器端)在提供了RESTful API后，需要通过一种方式能够模拟一个从UI客户端发送给服务器端的HTTP请求并能够分析返回的信息，以便进行模块化测试。 SoapUI SoapUI 是一个开源测试工具，通过soap/http来检查、调用、实现Web Service的功能/负载/符合性测试。我们也可以使用SoapUI测试RESTful应用。 Firefox插件-RESTClient 根据插件介绍RESTClient：“是一款用于测试各种Web服务的插件，它可以向服务器发送各种HTTP请求（用户也可以自定义请求方式），并显示服务器响应。” RESTClient主要分为如下四部分，如下图所示： 导航栏。包括上传Request File、密码认证Authentication 和Request Header的信息栏。 请求Request URL视图区域。填写Request Method、REquest URL。 请求Request Body视图区域。填写Request Body。 REST请求返回值Response显示区域。 Chrome插件-Postman Postman

springmvc学习笔记(19)-RESTful支持 标签： springmvc [TOC] 本文介绍RESTful的概念，并通过一个小例子展示如何编写RESTful风格的controller和配置前端控制器，最后展示静态资源的解析 概念 首先附上两篇博客链接 理解RESTful架构 - 阮一峰的网络日志 RESTful API 设计指南- 阮一峰的网络日志 RESTful架构，就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用。 RESTful（即Representational State Transfer的缩写）其实是一个开发理念，是对http的很好的诠释。 1.对url进行规范，写RESTful格式的url 非REST的url： http://...../queryItems.action?id=001&type=T01 REST的url风格： http://..../items/001 特点：url简洁，将参数通过url传到服务端 2.http的方法规范 不管是删除、添加、更新，等等。使用url是一致的，如果进行删除，需要设置http的方法为delete，其他同理。 后台controller方法：判断http方法，如果是delete执行删除，如果是post执行添加。 3.对http的contentType规范