REST接口设计风格

REST 一词的出于《Architectural Styles and 
the Design of Network-based Software Architectures》论文,我们先简单从标题来看,它应该是一种架构样式 (Architectural Styles) 与软件架构 (Software Architectures),而且是以网络 (Network-based) 为基础,重点就是:

  • 架构样式 (Architectural Styles)
  • 软件架构 (Software Architectures)
  • 网络 (Network-based) 为基础

REST 本身是设计风格而不是标准。REST 谈论一件非常重要的事,如何正确地使用 Web标准,例如,HTTP 和 URI。想要了解 REST 最好的方式就是思索与了解Web 及其工作方式。如果你设计的应用程序能符合 REST 原则 (REST principles),这些符合 REST 原则的 REST 服务可称为 "RESTful web service" 也称 "RESTful Web API"。"-ful" 字尾强调它们的设计完全符合 REST 论文里的建议内容。

资源 RESOURCE

在 REST 中的资源 (Resource) 代表整个网络上的资源。网络上提供了各式各样的资源,而网络上的资源由 URI (统一资源标识符,Uniform Resource Identifier) 来提供。 
回想,你如何连上我的 博客,你可能通过浏览器直接输入  www.cnblogs.com/shanyou 此域名来到达首页,也能用书签或网络上的链接,经点击后来连上我的博客。然后,你想看这一篇名为「REST 入门介绍」的文章,所以以你接下去点击这文章的标题连结,接去下阅读。我们简易了解一下整个流程:

  1. 通过URL ( http://www.cnblogs.com/shanyou ) , Client 向 http://www.cnblogs.com/shanyou 发出请求
  2. www.cnblogs.com/shanyou 收到请求,回应首页给 Client
  3. Client 又点击 REST 文章连结  (假设是 http://www.cnblogs.com/shanyou/archive/2011/06/30/2095018.html) 向http://www.cnblogs.com/shanyou发出archive/2011/06/30/2095018.html  此篇文章的请求
  4. www.cnblogs.com/shanyou  收到请求,响应 REST 文章内容给 Client

Client 的通过 URI 来获取资源的具体象征 (Representational)。Client 取得这些具体象征使这些应用程序转变其状态 (以 浏览器而言,取得 HTML、CSS、JavaScript … 来生成界面),随着不断取得资源的具体象征, Client 端不断地改变其状态,这样不断的反复 (iterations ) 过程就是所谓的 Representational State Transfer。

使用 WEB 标准

上述是最接近日常的范例,这些行为在 HTTP 规范中称之为 GET,也就是通过URL 来 GET 我想要的资源。另一常用的例子是填写表单,例如,登入表单,我想进行登入动作,就必须先发送账号与密码给某一资源,此资源会验证你所传送的数据是否正确,再进行后续动作。我们发送信息给资源的行为在 HTTP 规范中称之为 POST。 
在 HTTP/1.1 RFC 2616第 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的资源

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

http://www.cnblogs.com/Products/

Products是一组资源集合

列出 该组资源集合中每个资源的详细信息

更新 当前整组资源

新增 或附加一个新资源。该操作传回新资源的URL

删除 整组资源

http://www.cnblogs.com/Products/1

Products/1是单个资源

取得 指定的资源的详细信息

更新 或新增指定的资源

新增 或附加一个新元素

删除 指定的元素

以上表格有没有很像我们一般在对数据库表格的操作顺序,进入一个 Table 的数据首页 (通常是列表),此页面会有「新增、更新、删除、详细」等连结,你想进行什么操作,就点那一个连结。 
在 RESTful 每个资源有自己独立的 URI, Client 从资源集合或单个资源开始进入,不管是资源集合或单个资源,我们都能与 HTTP 方法配合使用,例如,GET 下载,PUT 更新,POST 新增,DELETE 删除。

ASP.NET Web API 是一个框架(framework),能让你在 .NET Framwork 之上架设 HTTP 服务 (HTTP Services)。ASP.NET Web API 是 .NET Framework 上构建 RESTful 应用程序的理想平台。

在 Julie Lerman's 的 How I see Web API 一文中,用了一张图来简明说明 Web API:

webapi_4

<think>我们正在讨论REST风格接口。根据引用内容,REST是REpresentational StateTransfer的缩写,中文直译为“表征状态转移”,它是一种软件架构风格,用于网络应用的开发。RESTful则是形容实现了REST风格的接口。REST风格的核心在于通过HTTP协议定义一组约束和原则,使得接口简洁、可伸缩。关键点: 1. REST是一种风格约定,而不是一个标准或协议。2.RESTful接口使用HTTP方法(GET, POST, PUT, DELETE等)来操作资源,资源通过URI(统一资源标识符)来标识。3.接口设计围绕资源(名词)展开,而不是动作(动词)。例如,使用`/friends`资源,通过HTTP方法DELETE来表示删除朋友,而不是在URI中使用动词如`deleteFriends`。 根据引用[2],一个符合REST风格的接口应该避免在URI中使用动词,而是利用HTTP方法来表示操作类型。例如: -获取朋友列表:GET /friends-添加朋友:POST/friends-更新朋友信息:PUT/friends/{id} -删除朋友:DELETE /friends/{id}引用[3]指出,REST风格可以降低开发的复杂性,提高系统的可伸缩性,并且被许多大型公司(如Amazon、雅虎)采用。 因此,我们可以这样定义:REST风格接口是一种基于HTTP协议,以资源为中心,通过HTTP方法表达操作意图的接口设计风格。现在,生成相关问题:§§相关问题§§1. REST风格接口中常用的HTTP方法有哪些?分别对应什么操作? 2.为什么REST风格接口强调使用名词而不是动词? 3. REST风格接口有哪些优点和缺点? 4.如何设计一个符合RESTful风格的资源URI?5.RESTful接口的安全性如何保证?</think>### REST风格接口的定义与概念 REST(REpresentational State Transfer)是一种软件架构风格,用于设计网络应用的接口。其核心思想是通过**资源**和**状态转移**来构建分布式系统。以下是关键特征: 1. **资源为中心** 所有数据/服务抽象为资源(名词),通过URI唯一标识。例如: `https://api.example.com/users`(用户资源) `https://api.example.com/products`(商品资源) 2. **统一接口** 通过标准HTTP方法操作资源: - `GET`:获取资源(如查询用户列表) - `POST`:创建资源(如新增用户) - `PUT`:更新资源(如修改用户信息) - `DELETE`:删除资源(如移除用户) 引用[2]强调避免在URI中使用动词(如`/deleteUser`),而应通过HTTP方法表达操作。 3. **无状态性** 每次请求必须包含所有必要信息,服务器不保存客户端状态。这提高了可伸缩性和可靠性。 4. **表征转移** 资源以特定表现形式(如JSON、XML)传输,客户端通过操作资源的表征来改变其状态。例如: ```json PUT /users/123 {"name": "Alice", "age": 30} ``` 5. **可缓存性** 响应需明确是否可缓存,减少重复请求。 ### 示例对比 | 非REST风格接口 | REST风格接口 | |----------------------|----------------------| | `GET /getUser?id=123`| `GET /users/123` | | `POST /deleteUser` | `DELETE /users/123` | ### 核心价值 - **简化设计**:标准化HTTP方法降低复杂度[^3] - **解耦客户端与服务端**:通过统一接口实现独立演进 - **高可伸缩性**:无状态设计支持水平扩展 - **广泛适用性**:被Amazon、Yahoo等大型平台采用[^3]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值