RESTFUL协议入门介绍

RESTFUL协议⼊门介绍
PHP⾼级⼯程师之RESTFUL协议
在这⾥和⼤家分享⼀下在写接⼝中要遵循的协议，这⾥我们介绍RESTFUL。

如有不善,多提意见（QQ：1595068971-邮箱：1595068971@）
dudu的讨论的⼈很多，说明RESTful API也开始在.NET 社区中得到重视,其中的回复有很多对REST不正确的观点。

(REpresentational State Transfer)的概念提出已超过10年，不知不觉间已成当今设计开放式API的主流。

或许⼤家⼿边的.NET系统整合都还是使⽤WCF(甚⾄Web Service)进⾏跨主机沟通，但是当微软在 MVC 4 Beta⾥也开始REST架构的。

如果没有先了解 RESTful，那接下去的内容还真有点硬，像是专业名词，例如，你在 Web API ⽂件中可以看到⼤量的 Resource (资源) 这个单字，URI 我还能理解，跟Resource 有什么关系？
关于REST及RESTful的概念，已有不少⽂章介绍，这⾥整理⼏篇我觉得不错的参考:
维基百科的定义:
REST理论的中⽂详述，其中你可以了解到WCF Restful属于RPC 样式的 Web 服务， Web API属于RESTful Web 服务。

InfoQ的专⽂介绍，⽂中甚⾄有Roy T. Fielding当年REST博⼠论⽂的中⽂翻译链接。

另外值得⼀提的，⼤家可能没听过的⼤名，但如果得知他是HTTP规格的主要作者及Apache HTTP Server项⽬的发起⼈之⼀，应该不会有⼈怀疑他在Web技术领域的分量。

上⾯的⽂章建议⼤家认真的读⼀下，这⾥我们简要的介绍下REST 做⼊门介绍，理解整个 REST 能让我们在 Web API 的路上更顺畅。

REST是什么？
REST ( REpresentational State Transfer )，State Transfer 为 "状态传输" 或 "状态转移 "，Representational 中⽂有⼈翻译为"表征"、"具象"，合起来就是 "表征状态传输" 或 "具象状态传输" 或 "表述性状态转移"，不过，⼀般⽂章或技术⽂件都⽐较不会使⽤翻译后的中⽂来撰写，⽽是直接引⽤ REST 或 RESTful 来代表，因为 REST ⼀整个观念，想要只⽤六个中⽂字来完整表达真有难度。

REST ⼀词的出于《
》论⽂，我们先简单从标题来看，它应该是⼀种架构样式 (Architectural Styles) 与软件架构 (Software Architectures)，⽽且是以⽹络(Network-based) 为基础，重点就是：
架构样式 (Architectural Styles)
软件架构 (Software Architectures)
⽹络 (Network-based) 为基础
REST 本⾝是设计风格⽽不是标准。

REST 谈论⼀件⾮常重要的事，如何正确地使⽤ Web标准，例如，HTTP 和。

想要了解 REST 最好的⽅式就是思索与了解 Web 及其⼯作⽅式。

如果你设计的应⽤程序能符合 REST 原则 (REST principles)，这些符合 REST 原则的 REST 服务可称为 "RESTful web service" 也称 "RESTful Web API"。

"-ful" 字尾强调它们的设计完全符合 REST 论⽂⾥的建议内容。

资源 RESOURCE
在 REST 中的资源 (Resource) 代表整个⽹络上的资源。

⽹络上提供了各式各样的资源，⽽⽹络上的资源由 URI (统⼀资源标识
符,Uniform Resource Identifier) 来提供。

回想，你如何连上我的博客，你可能通过浏览器直接输⼊此域名来到达⾸页，也能⽤书签或⽹络上的链接，经点击后来连上我的博客。

然后，你想看这⼀篇名为「REST ⼊门介绍」的⽂章，所以以你接下去点击这⽂章的标题连结，接去下阅读。

我们简易了解⼀下整个流程：
1. 通过URL ( /shanyou ) ， Client 向 /shanyou 发出请求
2. /shanyou 收到请求，回应⾸页给 Client
3. Client ⼜点击 REST ⽂章连结 (假设是 ) 向发出此篇⽂章的请求
4. /shanyou 收到请求，响应 REST ⽂章内容给 Client
Client 的通过 URI 来获取资源的具体象征 (Representational)。

Client 取得这些具体象征使这些应⽤程序转变其状态 (以浏览器⽽⾔，取得HTML、CSS、JavaScript … 来⽣成界⾯)，随着不断取得资源的具体象征， Client 端不断地改变其状态，这样不断的反复 (iterations ) 过程就是所谓的 Representational State Transfer。

使⽤ WEB 标准
上述是最接近⽇常的范例，这些⾏为在 HTTP 规范中称之为 GET，也就是通过URL 来 GET 我想要的资源。

另⼀常⽤的例⼦是填写表单，例如，登⼊表单，我想进⾏登⼊动作，就必须先发送账号与密码给某⼀资源，此资源会验证你所传送的数据是否正确，再进⾏后续动作。

我们发送信息给资源的⾏为在 HTTP 规范中称之为 POST。

在第 5.1.1 Method ⼀节定义了⼋⼤类 HTTP ⽅法，除了我们常⽤的 GET 与 POST 之外，在 REST 中常⽤的还有 PUT 与 DELETE。

此GET, POST, PUT, DELETE 正好可以对应我们 CRUD (Create, Read, Update, Delete) 四种数据操作。

HTTP Method 与 CURD 数据处理操作对应
HTTP⽅法数据处理说明
POST Create新增⼀个没有id的资源
POST Create新增⼀个没有id的资源
GET Read取得⼀个资源
PUT Update更新⼀个资源。

或新增⼀个含 id 资源(如果 id 不存在)
DELETE Delete删除⼀个资源
RESTFUL WEB SERVICE
RESTful Web Service (⼜称 RESTful Web API) 是⼀个使⽤ HTTP 并符合 REST 原则的 Web 服务。

我们知道，通过 URL 可以传送 GET 请求，在表单指定 method="GET|POST" 来送出请求。

但我们要处理 PUT 或 DELETE 的请求呢？通过 RESTful 我们可以简单 URI 来定义资源并和 HTTP ⽅法配合使⽤。

Resource 与 HTTP ⽅
法的对应
资源资源说明GET PUT POST DELETE
Products是⼀组资源集合列出该组资源集合中每个资源
的详细信息
更新当前整组资
源
新增或附加⼀个新资源。

该操作传回
新资源的URL
删除整组资
源
Products/1是单个资源取得指定的资源的详细信息
更新或新增指定
的资源
新增或附加⼀个新元素
删除指定的
元素
以上表格有没有很像我们⼀般在对数据库表格的操作顺序，进⼊⼀个 Table 的数据⾸页 (通常是列表)，此页⾯会有「新增、更新、删除、详细」等连结，你想进⾏什么操作，就点那⼀个连结。

在 RESTful 每个资源有⾃⼰独⽴的 URI， Client 从资源集合或单个资源开始进⼊，不管是资源集合或单个资源，我们都能与 HTTP ⽅法配合使⽤，例如，GET 下载，PUT 更新，POST 新增，DELETE 删除。

是⼀个框架(framework)，能让你在 .NET Framwork 之上架设 HTTP 服务 (HTTP Services)。

Web API 是 .NET Framework 上构建应⽤程序的理想平台。

在 Julie Lerman's 的⼀⽂中，⽤了⼀张图来简明说明 Web API：。