导航:首页 > IDC知识 > rest服务器

rest服务器

发布时间:2021-01-19 02:53:01

1、如何构建REST风格的WEB地图服务

REST英文全称为Representational State Transfer(表述性状态迁移),是2000年Roy Thomas Fielding博士在他的毕业论文中首次提出的概念,国内一帮精英已经把Fielding的论文翻成了中文,但是看完论文还是很难搞清REST到底是什么。Leonard Richardson与Sam Ruby的新书《RESTful Web Services》对REST作了简单而具体的诠释,提出了面向资源架构(The Resource-Oriented Architecture)的设计方法。根据对书中内容的理解,我这里作一简单的总结,不一定对,仅供参考。
1 什么是REST
REST是一组设计原则,或说是一种风格,不是架构,Fielding在他的论文中表示符合REST原则的web服务将在可见性、可靠性与可伸缩性等方面获益,而且符合万维网创建的初衷。
Google map(http://maps.google.com/)就是REST风格的web服务一例,当光标热点移动时,左下角随之变化的URI可以看出它是根据URI在提供相应的web服务。
REST是一组广义的设计原则,REST本身并没有与Web、HTTP或URI绑定,REST设计原则包括客户-服务器、无状态、缓存、统一接口、分层系统等。既然原则中要求无状态,又何来表述性状态呢?REST原则的无状态指服务器端不保存客户应用状态,连接→请求→响应→断开,客户的上一次请求与下一个请求没有关系(这其实是HTTP的特征)。服务器端响应客户请求返回资源的表述及相关链接(想像一下google返回的页面),该表述的本身就是客户的当前状态,客户按照表述中提供的链接选择下一个表述,迁移到下一个状态。这是我从字面上对REST的解释,也就是服务器通过表述为状态迁移提供指导,而状态的迁移权掌控在用户手里,客户根据自己的需要选择链接,由当前状态迁移到下一个状态。这个解释很肤浅,下面的面向资源架构从根本上对REST作了技术上的诠释。
2 面向资源架构
面向资源架构是一种REST风格的架构,它以资源为研究对象,通过划分资源、定义资源,然后用超媒体将资源串起来,提供客户所需求的服务。面向资源架构包括四个组成元素,具有四个属性。四个组成元素是:资源、资源名、资源表述和链接。四个属性是:可寻址、无状态、连通和统一接口。
2.1 四个元素
(1) 资源
就象面向对象设计取决于问题域对象划分一样,面向资源设计的首要任务就是划分资源,实际上面向资源是极端的面向对象,因为REST中规定了统一接口约束,要求对资源的操作必须是可见的(如HTTP中标准的GET、PUT、DELETE、POST,带暗箱操作的POST不算),因此资源的操作方法是不能自行定义的。
在面向资源设计中的资源可以是任何具有超文本链接价值的东西,资源可以是数据资源,也可以是物理对象,物理对象本身不能在网上传输,但物理对象的元数据可以。当统一接口方法不能满足需求时,可以通过设计资源将操作名词化,例如你“订阅”某个栏目,统一接口中没有“订阅”操作,也不允许你自行定义“订阅”操作,怎么办呢?你可以将“订阅”设计为资源“订阅关系”,“订阅关系”就可以用统一接口中的方法,如GET、PUT、DELETE进行操作了。同样,对于需要异步完成的操作,也可以通过资源将异步操作划分为多个同步操作来完成。总之,资源可以是任何东西,遇到困惑时可以设法通过资源来解决。
(2) 资源名
资源能成为资源的必要条件是:每个资源必须用URI唯一标识。这符合Tim Berners-Lee公理:Web上每一个资源由URL唯一确定。超文本系统、HTTP 和Internet分层协议之间是不能交流的,URI把所有这些协议集成到了web中。资源用URI命名,资源通过URI定位,URI中不仅包含资源的地址,还包含对资源的操作指令,服务器端根据URI中的指令确定客户请求的处理方式。因此,这里的URI不是单纯的网址。
(3) 资源表述
资源是表述的数据源,表述是资源的当前状态(应客户请求返回的网页),对REST风格的服务来说表述是超媒体,表述中不仅包含着当前资源的信息,还包含了相关资源的链接。
因此,表述呈现了资源的当前状态,也链接着资源的其它状态。表述具体涉及资源的数据及数据格式。可用于表述的超媒体格式有多种,如: 应用/XHTML+XML、应用/ATOM+XML、图像/SVG+XML、应用/JSON、应用/WADL+XML。《RESTful Web Services》书中对WADL(Web Application Description Language,https://wadl.dev.java.net)较为推崇,WADL是用于描述HTTP资源特征的XML格式定义(词汇表),书中认为WADL剥离了HTTP请求和响应(表述的建造与解析)的细节,支持URI模板及HTTP统一接口,可以特定符合XML Schema定义的XML表述格式,可简化web服务的客户端编程,与其它超媒体格式相比,WADL有其独特的优点。
(4) 资源链接
资源不是孤立的,是可以连通的,资源通过Link或Form链接,Link与Form本身就是资源表述的一种,因此说表述是超媒体。
2.2 四个属性
(1) 可寻址
每个资源由唯一的URI标识,使资源可定位,也因此使缓存成为可能。
(2) 无状态
客户请求与服务响应通过HTTP 通信,HTTP本身是无状态的,HTTP请求在完全封闭的过程中完成,请求中包含了服务器完成请求所必需的全部信息,请求与请求之间没有关联。这样,服务器端无需等待、无需追踪,它只需要关心客户发送请求时的应用状态就足够了。服务器端的服务之间也不需要分工协作,服务扩展只是将服务插入负载均衡器就行了,这样就增强了服务的伸缩性能。
REST 中的无状态是指仅有一种状态,该状态不在服务器端而在客户端。其实,从资源角度来说,服务器端也有状态,那就是资源状态。服务器应客户请求返回资源的表述,资源通过HTTP由资源状态迁移到客户应用状态;客户向服务器上传资源表述(例如Amazon的S3服务),客户应用状态通过HTTP迁移到服务器变成了资源状态,这是不是应该是REST的真正含义?
(3) 连通
资源应该以某种方式连通,也就是资源是链接的,不需要用户在浏览器中键入URI执行跳转。Link或Form链接是资源连通的超媒体。
(4) 统一接口
面向资源架构利用了HTTP的统一接口,HTTP统一接口提供了四种基本操作方法GET、PUT、DELETE和POST,面向资源架构要求所有服务按HTTP标准方式使用GET、PUT、DELETE和POST,这样安全性好,没有副作用产生,其次响应结果具幂等性(数学上术语),即同一请求返回的结果总是相同的(如:任何数不管乘零多少次结果总是零),除非底层资源发生变化。
3 以一个Web地图服务为例
这是《RESTful Web Services》书中一个最简单的例子,因为Web地图是只读的服务。我只是简单总结,以便大家对REST风格的架构有一个直观的认识。
设计步骤如下:
l 分析数据集
l 将数据集划分为资源
对每一个资源
l 用URI给资源定名
l 选择统一接口方法
l 设计客户端→服务器的表述
l 设计服务器→客户端的表述
l 用超媒体链接或表单将资源挂接到现有资源链中
l 正面设想一下该发生什么
l 反面设想一下什么可能发生

(1) 分析数据集
本数据集为各大星球二维平面图,可以通过地理坐标及地名在地图上定位,并展示以点为中心的平面图。
(2) 将数据集划分为资源
资源大体分三类:
l 预定义的一次性资源,如同一个web主页,充当其它资源的顶级入口。你能GET它,但不能DELETE或PUT它。
l 每个对象的资源,每个对象有自己的资源集合,你可以GET、DELETE或PUT对象的资源。
l 经数据处理后获取的资源,例如根据查询条件返回的结果。

2、REST和SOAP Web Service的区别比较

restful是一种架构风格,其核心是面向资源;而webService底层SOAP协议,主要核心是面向活动。

SOAP:简单对象访问协议,很轻量,同时作为应用协议可以基于多种传输协议来传递消息(Http,SMTP等)。

客户端和服务器端的通讯方式 

REST 与代理服务器 (Proxy Servers)  

一般代理服务器的实现根据 (URI, HTTP Method) 两元组来决定 HTTP 请求的安全合法性。

当发现类似于(http://localhost:8182/v1/users/{username},DELETE)这样的请求时,予以拒绝。

对于 SOAP,如果我们想借助于既有的代理服务器进行安全控制.

REST 与缓存服务器 (Cache Server)  

使用 HTTP 协议的 SOAP,由于其设计原则上并不像 REST 那样强调与 Web 的工作方式相一致,所以,基于 SOAP 应用很难充分发挥 HTTP 本身的缓存能力,图 7. SOAP 与缓存服务器 (Cache Server)

总结:

REST对于资源型服务接口来说很合适,同时特别适合对于效率要求很高,但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的,对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义,关键还是看应用场景。成熟度SOAP虽然发展到现在已经脱离了初衷,但是对于异构环境服务发布和调用,以及厂商的支持都已经达到了较为成熟的情况。不同平台,开发语言之间通过SOAP来交互的web service都能够较好的互通。

3、怎样用通俗的语言解释什么叫 REST,以及什么是 RESTful

REST (REpresentation State Transfer) 描述了一个架构样式的网络系统,比如 web 应用程序。它首次出现在 2000 年 Roy Fielding 的博士论文中,他是 HTTP 规范的主要编写者之一。REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。Web 应用程序最重要的 REST 原则是,客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启,客户端不会得到通知。此外,无状态请求可以由任何可用服务器回答,这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。在服务器端,应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体,它向客户端公开。资源的例子有:应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个惟一的地址。所有资源都共享统一的界面,以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法,比如 GET、PUT、POST 和 DELETE。Hypermedia 是应用程序状态的引擎,资源表示通过超链接互联。另一个重要的 REST 原则是分层系统,这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层,可以限制整个系统的复杂性,促进了底层的独立性。当REST 架构的约束条件作为一个整体应用时,将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构,改进了子系统之间交互的可见性。REST 简化了客户端和服务器的实现。RESTful的实现:RESTful Web 服务与 RPC 样式的 Web 服务了解了什么是什么是REST,我们再看看RESTful的实现。最近,使用 RPC 样式架构构建的基于 SOAP 的 Web 服务成为实现 SOA 最常用的方法。RPC 样式的 Web 服务客户端将一个装满数据的信封(包括方法和参数信息)通过 HTTP 发送到服务器。服务器打开信封并使用传入参数执行指定的方法。方法的结果打包到一个信封并作为响应发回客户端。客户端收到响应并打开信封。每个对象都有自己独特的方法以及仅公开一个 URI 的 RPC 样式 Web 服务,URI 表示单个端点。它忽略 HTTP 的大部分特性且仅支持 POST 方法。由于轻量级以及通过 HTTP 直接传输数据的特性,Web 服务的 RESTful 方法已经成为最常见的替代方法。可以使用各种语言(比如 Java 程序、Perl、Ruby、Python、PHP 和 Javascript[包括 Ajax])实现客户端。RESTful Web 服务通常可以通过自动客户端或代表用户的应用程序访问。但是,这种服务的简便性让用户能够与之直接交互,使用它们的 Web 浏览器构建一个 GET URL 并读取返回的内容。在REST 样式的 Web 服务中,每个资源都有一个地址。资源本身都是方法调用的目标,方法列表对所有资源都是一样的。这些方法都是标准方法,包括 HTTP GET、POST、PUT、DELETE,还可能包括 HEADER 和 OPTIONS。在RPC 样式的架构中

4、REST真的完全适合微服务架构吗

REST (REpresentation State Transfer) 描述了一个架构样式的网络系统,比如 web 应用程序。它首次出现在 2000 年 Roy Fielding 的博士论文中,他是 HTTP 规范的主要编写者之一。REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。Web 应用程序最重要的 REST 原则是,客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启,客户端不会得到通知。此外,无状态请求可以由任何可用服务器回答,这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。在服务器端,应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体,它向客户端公开。资源的例子有:应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个惟一的地址。所有资源都共享统一的界面,以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法,比如 GET、PUT、POST 和 DELETE。Hypermedia 是应用程序状态的引擎,资源表示通过超链接互联。另一个重要的 REST 原则是分层系统,这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层,可以限制整个系统的复杂性,促进了底层的独立性。当REST 架构的约束条件作为一个整体应用时,将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构,改进了子系统之间交互的可见性。REST 简化了客户端和服务器的实现。RESTful的实现:RESTful Web 服务与 RPC 样式的 Web 服务了解了什么是什么是REST,我们再看看RESTful的实现。最近,使用 RPC 样式架构构建的基于 SOAP 的 Web 服务成为实现 SOA 最常用的方法。RPC 样式的 Web 服务客户端将一个装满数据的信封(包括方法和参数信息)通过 HTTP 发送到服务器。服务器打开信封并使用传入参数执行指定的方法。方法的结果打包到一个信封并作为响应发回客户端。客户端收到响应并打开信封。每个对象都有自己独特的方法以及仅公开一个 URI 的 RPC 样式 Web 服务,URI 表示单个端点。它忽略 HTTP 的大部分特性且仅支持 POST 方法。由于轻量级以及通过 HTTP 直接传输数据的特性,Web 服务的 RESTful 方法已经成为最常见的替代方法。可以使用各种语言(比如 Java 程序、Perl、Ruby、Python、PHP 和 Javascript[包括 Ajax])实现客户端。RESTful Web 服务通常可以通过自动客户端或代表用户的应用程序访问。但是,这种服务的简便性让用户能够与之直接交互,使用它们的 Web 浏览器构建一个 GET URL 并读取返回的内容。在REST 样式的 Web 服务中,每个资源都有一个地址。资源本身都是方法调用的目标,方法列表对所有资源都是一样的。这些方法都是标准方法,包括 HTTP GET、POST、PUT、DELETE,还可能包括 HEADER 和 OPTIONS。在RPC 样式的架构中,关注点在于方法,而在 REST 样式的架构中,关注点在于资源 -- 将使用标准方法检索并操作信息片段(使用表示的形式)。资源表示形式在表示形式中使用超链接互联。Leonard Richardson 和 Sam Ruby 在他们的著作 RESTful Web Services 中引入了术语 REST-RPC 混合架构。REST-RPC 混合 Web 服务不使用信封包装方法、参数和数据,而是直接通过 HTTP 传输数据,这与 REST 样式的 Web 服务是类似的。但是它不使用标准的 HTTP 方法操作资源。它在 HTTP 请求的 URI 部分存储方法信息。好几个知名的 Web 服务,比如 Yahoo 的 Flickr API 和 del.icio.us API 都使用这种混合架构。RESTful的实现:RESTful Web 服务的 Java 框架有两个 Java 框架可以帮助构建 RESTful Web 服务。erome Louvel 和 Dave Pawson 开发的 Restlet(见 参考资料)是轻量级的。它实现针对各种 RESTful 系统的资源、表示、连接器和媒体类型之类的概念,包括 Web 服务。在 Restlet 框架中,客户端和服务器都是组件。组件通过连接器互相通信。该框架最重要的类是抽象类 Uniform 及其具体的子类 Restlet,该类的子类是专用类,比如 Application、Filter、Finder、Router 和 Route。这些子类能够一起处理验证、过滤、安全、数据转换以及将传入请求路由到相应资源等操作。Resource 类生成客户端的表示形式。JSR-311是 Sun Microsystems 的规范,可以为开发 RESTful Web 服务定义一组 Java API。Jersey是对 JSR-311 的参考实现。JSR-311 提供一组注释,相关类和接口都可以用来将 Java 对象作为 Web 资源展示。该规范假定 HTTP 是底层网络协议。它使用注释提供 URI 和相应资源类之间的清晰映射,以及 HTTP 方法与 Java 对象方法之间的映射。API 支持广泛的 HTTP 实体内容类型,包括 HTML、XML、JSON、GIF、JPG 等。它还将提供所需的插件功能,以允许使用标准方法通过应用程序添加其他类型。RESTful的实现:构建 RESTful Web 服务的多层架构RESTful Web 服务和动态 Web 应用程序在许多方面都是类似的。有时它们提供相同或非常类似的数据和函数,尽管客户端的种类不同。例如,在线电子商务分类网站为用户提供一个浏览器界面,用于搜索、查看和订购产品。如果还提供 Web 服务供公司、零售商甚至个人能够自动订购产品,它将非常有用。与大部分动态 Web 应用程序一样,Web 服务可以从多层架构的关注点分离中受益。业务逻辑和数据可以由自动客户端和 GUI 客户端共享。惟一的不同点在于客户端的本质和中间层的表示层。此外,从数据访问中分离业务逻辑可实现数据库独立性,并为各种类型的数据存储提供插件能力。图1 展示了自动化客户端,包括 Java 和各种语言编写的脚本,这些语言包括 Python、Perl、Ruby、PHP 或命令行工具,比如 curl。在浏览器中运行且作为 RESTful Web 服务消费者运行的 Ajax、Flash、JavaFX、GWT、博客和 wiki 都属于此列,因为它们都代表用户以自动化样式运行。自动化 Web 服务客户端在 Web 层向 Resource Request Handler 发送 HTTP 响应。客户端的无状态请求在头部包含方法信息,即 POST、GET、PUT 和 DELETE,这又将映射到 Resource Request Handler 中资源的相应操作。每个请求都包含所有必需的信息,包括 Resource Request Handler 用来处理请求的凭据。从Web 服务客户端收到请求之后,Resource Request Handler 从业务逻辑层请求服务。Resource Request Handler 确定所有概念性的实体,系统将这些实体作为资源公开,并为每个资源分配一个惟一的 URI。但是,概念性的实体在该层是不存在的。它们存在于业务逻辑层。可以使用 Jersey 或其他框架(比如 Restlet)实现 Resource Request Handler,它应该是轻量级的,将大量职责工作委托给业务层。Ajax 和 RESTful Web 服务本质上是互为补充的。它们都可以利用大量 Web 技术和标准,比如 HTML、JavaScript、浏览器对象、XML/JSON 和 HTTP。当然也不需要购买、安装或配置任何主要组件来支持 Ajax 前端和 RESTful Web 服务之间的交互。RESTful Web 服务为 Ajax 提供了非常简单的 API 来处理服务器上资源之间的交互。图1 中的 Web 浏览器客户端作为 GUI 的前端,使用表示层中的 Browser Request Handler 生成的 HTML 提供显示功能。Browser Requester Handler 可以使用 MVC 模型(JSF、Struts 或 Spring 都是 Java 的例子)。它从浏览器接受请求,从业务逻辑层请求服务,生成表示并对浏览器做出响应。表示供用户在浏览器中显示使用。表示不仅包含内容,还包含显示的属性,比如 HTML 和 CSS。 业务规则可以集中到业务逻辑层,该层充当表示层和数据访问层之间的数据交换的中间层。数据以域对象或值对象的形式提供给表示层。从业务逻辑层中解耦 Browser Request Handler 和 Resource Request Handler 有助于促进代码重用,并能实现灵活和可扩展的架构。此外,由于将来可以使用新的 REST 和 MVC 框架,实现它们变得更加容易,无需重写业务逻辑层。数据访问层提供与数据存储层的交互,可以使用 DAO 设计模式或者对象-关系映射解决方案(如 Hibernate、OJB 或 iBATIS)实现。作为替代方案,业务层和数据访问层中的组件可以实现为 EJB 组件,并取得 EJB 容器的支持,该容器可以为组件生命周期提供便利,管理持久性、事务和资源配置。但是,这需要一个遵从 Java EE 的应用服务器(比如 JBoss),并且可能无法处理 Tomcat。该层的作用在于针对不同的数据存储技术,从业务逻辑中分离数据访问代码。数据访问层还可以作为连接其他系统的集成点,可以成为其他 Web 服务的客户端。数据存储层包括数据库系统、LDAP 服务器、文件系统和企业信息系统(包括遗留系统、事务处理系统和企业资源规划系统)。使用该架构,您可以开始看到 RESTful Web 服务的力量,它可以灵活地成为任何企业数据存储的统一 API,从而向以用户为中心的 Web 应用程序公开垂直数据,并自动化批量报告脚本。什么是REST:结束语REST 描述了一个架构样式的互联系统(如 Web 应用程序)。REST 约束条件作为一个整体应用时,将生成一个简单、可扩展、有效、安全、可靠的架构。由于它简便、轻量级以及通过 HTTP 直接传输数据的特性,RESTful Web 服务成为基于 SOAP 服务的一个最有前途的替代方案。用于 web 服务和动态 Web 应用程序的多层架构可以实现可重用性、简单性、可扩展性和组件可响应性的清晰分离。Ajax 和 RESTful Web 服务本质上是互为补充的。

5、怎样保证到服务器的 REST 请求是由自己的 APP 发起的

简单而直接的答案是:不可能杜绝,尽量减小影响。
Report: Bot traffic is up to 61.5% of all website traffic
2014 Bot Traffic Report: Just the Droids You were Looking for
根据这两篇报道,2013年全球Web流量61.5%是机器人,2014年是56%。

这是一个很有普遍意义的反机器人设计,虽然结果令人失望,但是我们可以从技术角度做一些事情:
0 反作弊策略
最最最重要的!要有反作弊策略,不能只依靠技术手段。这是一个与人斗的过程。
至少你要定义出什么样的行为是机器人,比如每秒30个请求显然不是个真实用户。
1 SSL
先从最简单的入手。用SSL可以杜绝最简单的抓包探测。
2 双向加密
题目中的非对称加密方法。当然别人可以反编译你的客户端,但是要学会反编译,战胜那些混淆代码的工具,需要比较高的专业技能。
3 第三方认证
目前手机是没有,但是XBOX和PS都有。只要这些第三方平台没有被破解,你就可以通过服务器间通讯获得可靠的用户信息。
其实苹果的DeviceToken就是这个东西,但是它没有提供接口让你验证合法性,就等于没有了。

除了技术手段以外,更重要的是运营策略:
1 利益是源头
别人调你的API一定是有用,如果是游戏一般都是刷金币对吧。你控制不要刷出来,自然就没有人刷了。
2 关闭交易通道
攻击你的人一定要有经济利益才会持续的投入,否则就是玩玩。不要让他们赚到钱,就像魔兽世界一样把刷金币和买金币的账号都封掉。这是从制度上消灭它的利益。
3 提高成本
再严密都会有疏漏,比如你的反作弊策略只能覆盖70%的BOT,另外30%的收益依然可能大于成本。这时候可以提高创建新用户的成本,比如第三方硬件平台其实就是一种,你也可以对每个新建的账号收费,收到超过它的平衡点就自然会退出了。

6、在rest接口规范中,post成功创建一个新的资源后,服务器应该返回状态码是多少

2xx
200 OK
所有人都知道 200 OK 是什么。这估计是最经常被滥用的状态码。很多人在应该使用其它 2xx 状态码时都选用了 200 OK 来表示。
201 Created
如果你在设计一个 REST API,或者一个 CRUD API,当你使用 POST(或者 PUT)成功创建一个新的资源后,服务器应该返回 201 Created 同时在 header 的 Location 字段给出刚刚创建好的这个资源的 URI。
例如说,如果你使用 POST 请求通过 \comments URI 创建了一个新的评论,那么服务器应该返回 201 Created,同时带上形如Location: \comments\1234 的字段表明新创建的评论的 URI。
202 Accepted
如果服务器在接受请求后,需要进行一个异步处理才能有结果,并且觉得不需要让 TCP 连接保持到结果出来再返回,它可以返回 202 Accepted,意思是请求已接受,但没有立即可返回的结果。
204 No Content
在一个 REST API 或者 CRUD API 里面,当你使用 PUT 成功更新一个资源后,如果服务器完整接受了客户端的更新,没有拒绝也没有额外更新,那实际上是不需要返回任何东西的,因为现在客户端和服务器端已经拥有完全一致的状态。在这种情况下,服务器可以返回 204 No Content,同时 body 为空,客户端就知道它的状态已经跟服务器端同步了。
206 Partial Content
断点续传和多线程下载都是通过 206 Partial Content 实现的。
请求的 header 必须包含一个 Range 字段,表明自己请求第几个字节到第几个字节的内容。如果服务器支持的话,就返回 206 Partial Content,然后使用 header 的 Content-Range 指明范围,并在 body 内提供这个范围内的数据。
3xx
301 Moved Permanently
永久性重定向。目标由 header 的 Location 字段给出,同时 body 中也应该有指向目标的链接。新请求使用的方法应该和原请求的一致。如果用户使用 HEAD 和 GET 以外的方式发起原请求,客户端在遇到 301 Moved Permanently 后应当询问用户是否对新的 URI 发起新请求。
302 Found
临时性重定向。
这应该是浏览器实现最不符合标准的一个状态码了。理论上,除了临时性这一点,302 Found 跟 301 Moved Permanently 应该是完全一样的。然而实质上,很多浏览器在遇到 302 Found 后就会使用 GET 去请求新的 URI,而无论原请求使用的是何种方法。由于这种现象的普遍存在,使得这成为了一个与书面标准相违背的事实标准,新的客户端在实现时很难选择应该遵守哪一个标准,所以 RFC 2616 专门新增了 303 See Other 和 307 Temporary Redirect 两个状态码来消除二义性。
303 See Other
临时性重定向,且总是使用 GET 请求新的 URI。
304 Not Modified
如果客户端发起了一个「条件 GET」,同时资源确实没被修改过,那么服务器端就应该返回 304 Not Modified,同时 body 不包含任何内容。
所谓的「条件 GET」,是指 GET 的 header 带上了 If-Modified-Since 或 If-None-Match 字段。这两个 header 就是「条件」,如果条件符合了 GET 就应该正常执行,否则就应该返回 304 Not Modified,以便告诉客户端它想要请求的资源在上一次请求之后没有被更新过,客户端可以继续使用之前的版本。
307 Temporary Redirect
临时性重定向,且总是使用原请求的方法来进行新请求。
4xx
400 Bad Request
服务器无法理解请求的格式,客户端不应当尝试再次使用相同的内容发起请求。
401 Unauthorized
请求未授权。如果请求 header 没有 Authorization 字段,服务器端应该在返回 401 Unauthorized 的同时在 header 中用 WWW-Authorization 字段指出授权方式,以便客户端带上登录信息重新发起请求。如果 Authorization 字段已经存在,则表明登录信息不正确。
402 Payment Required
需要支付。这是一个在任何浏览器中都没有被实现的状态码,仅预留将来使用。
百度曾经有一个部门印过一批背上写着 402 Payment Require 的衣服,并且开玩笑说这批衣服最适合在互联网企业员工讨薪时穿。
403 Forbidden
禁止访问。即使使用 Authorization 字段提供登录信息也会得到相同的结果。
如果客户端使用 HEAD 以外的方法请求,403 Forbidden 必须同时在 body 中返回禁止访问的原因。如果原因不能够公开,则应该使用404 Not Found。
404 Not Found
找不到如何与 URI 相匹配的资源。服务器无需指出资源是临时性不存在还是永久性不存在,但如果服务器端知道该资源已经被永久性删除则应该返回 410 Gone。
404 Not Found 是服务器端在不愿意提供理由的情况下拒绝提供资源的最佳借口。
405 Method Not Allowed
请求的方法被拒绝。
如果你有一个 REST API 或 CRUD API 被设计为只读,那么在遇到 PUT、POST 或者 DELETE 方法时服务器端都应该返回 405 Method Not Allowed,同时在 header 的 Allow 字段说明允许的方法(如 GET 和 HEAD)。
409 Conflict
冲突,且需要用户手工解决。
如果你使用 git(或者其他源代码管理软件),你已经知道「冲突」是什么了。409 Conflict 通常发生在 PUT 请求时,如果要更新的资源已经被其他人更新过了,你再更新就可能产生冲突。
410 Gone
如果服务器端将此资源标记为已被永久性删除,则应该使用 410 Gone 而非 404 Not Found,其用意在于告诉客户端资源是被有意删除的,而且删除是永久性的,客户端不应该再保留这个 URI 的链接。
举例来说,你有一个 REST API 或 CRUD API 用于向用户提供优惠信息。有一则优惠的 URI 是 /promotions/1234,但由于优惠活动已经结束了,所以这一则优惠信息不再有效且应当被永久性删除,那么这时候服务器端就应该让该 URI 永远返回 410 Gone 了。
412 Precondition Failed
条件判断失败,操作不会被执行。
在解释 304 Not Modified 时提到了「条件 GET」的概念,但「条件」本身也可以应用于非 GET 请求,这时候如果条件判断失败服务器端就应该返回 412 Precondition Failed,同时拒绝执行客户端请求的方法。
条件请求可以被看作是一种乐观锁。它不需要服务器端有任何逻辑判断操作是否存在冲突,服务器端只要记录资源的时间戳(或其它版本信息)即可。
5xx
500 Internal Server Error
最常见的服务器端错误。
503 Service Unavailable
服务器端暂时无法处理请求(可能是过载或维护)。
返回 503 Service Unavailable 的意思是当前的状况是临时性的,客户端可以稍后重试。服务器端可以在返回时通过 header 的Retry-After 字段告诉客户端多久后可以重试。如果不提供这个字段的话,客户端应当把 503 Service Unavailable 等同于 500 Internal Server Error 处理。

7、如何使用JFINAL搭建REST接口服务器

2.7 configHandler(..)
此方法用来配置JFinal的Handler,如下代码配置了名为ResourceHandler的处理器,Handler可以接管所有web请求,并对应用拥版有完全的控制权,可权以很方便地实现更高层的功能性扩展。
public void configHandler(Handlers me) { me.add(new ResourceHandler());}

8、什么是REST-ful,以及REST-ful的实现

REST 指的是一组架构约束条件和原则
Web 应用程序最重要的 REST 原则是:客户端和服务器之间的交互,在请求之间是无状态的;客户端的每个请求都必须包含理解请求所必需的信息;服务器在请求之间的任何时间点重启,客户端 不会得到通知;无状态请求可以由任何可用服务器回答,十分适合云计算之类的环境;客户端可以缓存数据以改进性能。
在服务器端,应用程序状态和功能可以分为各种资源:每个资源都使用 URI (Universal Resource Identifier) 得到一个惟一的地址。所有资源都共享统一的界面,以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法,比如 GET、PUT、POST 和 DELETE。
另一个重要的 REST 原则是分层系统:这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层,可以限制整个系统的复杂性,促进了底层的独立性。
当 REST 架构的约束条件作为一个整体应用时,将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构,改进了子系统之间交互的可见性。REST 简化了客户端和服务器的实现。
REST-ful的实现:构建 RESTful Web 服务的多层架构
RESTful Web 服务和动态 Web 应用程序在许多方面都是类似的。有时它们提供相同或非常类似的数据和函数,尽管客户端的种类不同。例如,在线电子商务分类网站为用户提供一个浏览器界面, 用于搜索、查看和订购产品。如果还提供 Web 服务供公司、零售商甚至个人能够自动订购产品,它将非常有用。与大部分动态 Web 应用程序一样,Web 服务可以从多层架构的关注点分离中受益。业务逻辑和数据可以由自动客户端和 GUI 客户端共享。惟一的不同点在于客户端的本质和中间层的表示层。此外,从数据访问中分离业务逻辑可实现数据库独立性,并为各种类型的数据存储提供插件能力。

9、移动App开发的后台REST服务器有哪些

如果你喜欢自己搭建而且是iOS

如果你在国内AVOS, 国外Parse

也有一些其他选择

10、什么是REST?

它首次出现在 2000 年 Roy Fielding 的博士论文中,他是 HTTP 规范的主要编写者之一。
REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
Web 应用程序最重要的 REST 原则是,客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启,客户端不会得到通知。此外,无状态请求可以由任何可用服务器回答,这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。
在服务器端,应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体,它向客户端公开。资源的例子有:应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个惟一的地址。所有资源都共享统一的界面,以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法,比如 GET、PUT、POST 和 DELETE。Hypermedia 是应用程序状态的引擎,资源表示通过超链接互联。
另一个重要的 REST 原则是分层系统,这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层,可以限制整个系统的复杂性,促进了底层的独立性。
当 REST 架构的约束条件作为一个整体应用时,将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构,改进了子系统之间交互的可见性。

与rest服务器相关的知识