REST 的约束采用的就是掌控 Web 的基本原则。这些原则是：
- 用户代理与资源交互，任何可命名和表达的事物都可称为资源。每项资源都有一个唯一的统一资源标识符 (URI)。
- 与资源的交互（通过其唯一的 URI 定位）使用 HTTP 标准动词（GET、POST、PUT 和 DELETE）的统一接口完成。交互中声明资源的媒体类型也很重要，它使用 HTTP 内容类型标头指定。（XHTML、XML、JPG、PNG 和 JSON 就是一些广为人知的媒体类型。）
- 资源是自我描述的。处理资源请求所需的全部信息均包含在请求本身内（这样服务可以没有状态）。
- 资源包含到其他资源的链接（超媒体）。
您为什么应关注 REST？
现在我对 REST 做一些解释，您可能正在想为什么要对它加以关注。作为开发人员，您需要一定的动机来学习和采纳任何风格、技术或模式。如果您阅读此杂志，您可能是常与 Microsoft 技术打交道的开发人员。要实现客户端-服务器应用程序，您可能使用的是另一种体系结构风格：远程过程调用 (RPC)。无论您用过的是专用 RPC 系统（例如 DCOM 或 .
NET Remoting），还是可互操作的 RPC 技术（例如，使用
ASMX 或 WCF 的 SOAP），它们都是在 Microsoft 平台上展现的客户端-服务器风格。那么，为什么要学习或使用 REST？
据我所知有两个主要原因。首先，REST 在许多方面所表现出的重要功能和优点都远胜于
RPC 技术。其次，Microsoft 正在将自身许多实现从 RPC 技术（例如 SOAP）转为 REST。这意味着即使您对使用 REST 构建自己的系统尚在犹豫，随着 Microsoft 和其他公司将更多的框架和技术转向 REST，您仍需了解如何与之交互。
以下是一份其他优点的列表（并非全部优点都已列出）：
缓存 使用 HTTP 向 RESTful 端点申请数据时，用到的 HTTP 动词是 GET。对于 GET 请求响应中返回的资源，可以用多种不同的方式进行缓存。Conditional GET 就是可供选择的一种实现细节，客户端可以向服务验证他的数据是否为最新版本；RESTful 端点可以通过它进一步提高速度和可伸缩性。
扩展 REST 鼓励每项资源包含处理特殊请求所需的所有必要状态。满足这一约束时，RESTful 服务更易于扩展且可以没有状态。
副作用如您使用 GET 请求资源，RESTful 服务应该没有副作用（遗憾的是，与其他一些 REST 约束相比，这一约束更容易被打破）。
幂等 统一接口另外两个常用到的主要 HTTP 动词是 PUT 和 DELETE。用户代理想要修改资源时最常使用 PUT，DELETE 可以自我描述。要点（也就是“幂等”一词所强调的）是您可以对特殊资源多次使用这两个动词，效果与首次使用一样——至少不会有任何其他影响。构建可靠的分布式系统时（即错误、网络故障或延迟可能导致多次执行代码），这一优点可提供保障。
互操作性 许多人将 SOAP 捧为建立客户端-服务器程序最具互操作性的方法。但一些语言和环境至今仍没有 SOAP 工具包。有一些虽然有工具包，但采用的是旧标准，不能保证与使用更新标准的工具包可靠沟通。对于大多数操作，REST 仅要求有 HTTP 库（当然，XML 库通常也很有帮助），它的互操作性肯定强过任何 RCP 技术（包括 SOAP）。
简易性与其他优点相比，这一优点更主观一些，不同的人可能有不同的感受。对我而言，使用 REST 的简易性涉及到代表资源的 URI 和统一接口。作为一名 Web 冲浪高手，我理解在浏览器中输入不同的 URI 可以得到不同的资源（有时也被称为 URI 或 URL 黑客，但绝无恶意）。由于有多年使用 URI 的经验，所以为资源设计 URI 对我来说得心应手。使用统一接口简化了开发过程，因为我不必为每个需要建立的服务构建接口、约定或 API。接口（客户端与我的服务交互的方式）由体系结构约束设置。
正如我所说的，这并不是一份详尽的列表，您也不能因此认定 REST 是唯一一种经常使用的技术。您应该了解的是它的长处，以便在需要时能够加以利用。
目前，wcf也可以通过以下新特性完成restful功能架构
编程模型有两个主要的新属性：WebGetAttribute 和 WebInvokeAttribute；还有一个 URI 模板机制，帮助您声明每种方法响应用的 URI 和动词。基础架构的组成是一个绑定 (WebHttpBinding) 和一种行为 (WebHttpBehavior)，为使用 REST 提供适宜的连网堆栈。此外，自定义的 ServiceHost (WebServiceHost) 和 ServiceHostFactory (WebServiceHostFactory) 还提供了一些托管基础架构方面的帮助。