REST不一定绑定到HTTP。基于rest的web服务只是遵循基于rest的体系结构的web服务。

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

不太……

http://en.wikipedia.org/wiki/Representational_State_Transfer

REST was initially described in the context of HTTP, but is not limited to that protocol. RESTful architectures can be based on other Application Layer protocols if they already provide a rich and uniform vocabulary for applications based on the transfer of meaningful representational state. RESTful applications maximise the use of the pre-existing, well-defined interface and other built-in capabilities provided by the chosen network protocol, and minimise the addition of new application-specific features on top of it.

http://www.looselycoupled.com/glossary/SOAP

(简单对象访问协议 web服务消息的标准。 SOAP基于XML定义了一个信封 格式和各种规则 描述它的内容。见过( WSDL和UDDI)作为三者之一 web服务的基础标准， 它是用于 交换web服务，但不是 意思是唯一的;REST的支持者 说它增加了不必要的东西 的复杂性。

不，REST是HTTP应该使用的方式。

今天我们只使用了HTTP协议的一小部分方法——即GET和POST。REST的方法是使用协议的所有方法。

例如，REST规定使用DELETE来删除URI后面的文档(可以是文件、状态等)，而使用HTTP，您可能会滥用GET或POST查询，如…product/?delete_id=22。

HTTP是一种应用协议。REST是一组规则，遵循这些规则，您就可以构建具有特定约束集的分布式应用程序。

如果您正在寻找REST中区分RESTful应用程序与任何HTTP应用程序的最重要的约束，我会说“自描述”约束和超媒体约束(又名hypermedia as the Engine of application State (HATEOAS))是最重要的。

自描述约束要求RESTful请求在用户意图中是完全自描述的。这允许中介(代理和缓存)安全地对消息进行操作。

HATEOAS约束是关于将您的应用程序转换为一个链接网络，其中客户端的当前状态基于它在该网络中的位置。这是一个棘手的概念，需要比现在更多的时间来解释。

REST是一种设计大型系统(如web)的特殊方法。

它是一组“规则”(或“约束”)。

HTTP是一个试图遵守这些规则的协议。

REST api必须是超文本驱动的

Roy Fielding的博客中有一组方法来检查你正在构建的是HTTP API还是REST API:

API designers, please note the following rules before calling your creation a REST API: A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification. [Failure here implies that identification is not separated from interaction.] A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as HTTP’s PATCH method or Link header field. Workarounds for broken implementations (such as those browsers stupid enough to believe that HTML defines HTTP’s method set) should be defined separately, or at least in appendices, with an expectation that the workaround will eventually be obsolete. [Failure here implies that the resource interfaces are object-specific, not generic.] A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.] A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC’s functional coupling]. A REST API should never have “typed” resources that are significant to the client. Specification authors may use resource types for describing server implementation behind the interface, but those types must be irrelevant and invisible to the client. The only types that are significant to a client are the current representation’s media type and standardized relation names. [ditto] A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]