前后端分离开发，RESTful接口如何设计.docx资源-CSDN文库

版权申诉

前后端分离

149 浏览量 2023-12-03 11:37:17 上传评论收藏 1.3MB DOCX 举报

资源推荐

资源详情

资源评论

前后端分离开发，RESTful 接口如何设计

REST（Representational State Transfer）架构风格是一种世界观，把信息提升为架构中的一等公民。通过 REST 可以

实现系统的高性能、可伸缩、通用性、简单性、可修改性和可扩展等特性。这篇文章解释了主要的 HTTP 操作，对 HTTP

响应码进行描述，并列举相关开发库和框架。此外，本文还提供了额外的资源，对每个主题进行了更深入的探

讨。

简介

REST 架构风格不是一种可以购买的技术，也不是一个可以添加到软件开发项目中的开发库。首先也是最重要的，REST

是一种世界观，把将信息提升为构建架构中的一等公民。

的博士论文

“

架构风格和基于网络的软件架构设计

”

介绍和整理了

“

”

系统的思想和相关术语。

这是一篇学术论文，虽然使用正式语言，但是仍然易于理解并且提供了实践基础。

总结一下，RESTful 通过体系结构的特定选择能从部署的系统中获得理想特性。尽管这种风格定义的约束细节并没有为

所有场合设计，但是的确可以�泛适用。

由于 Web 对消费者偏好有多重影响，REST 风格的倡导者鼓励企业组织在其边界内使用相同原则，就像他们在面向外部

客户的网页上做的那样。本文将讨论现代 REST Web 实现中的基本约束和属性。

基础概念

REST 表示什么含义？以无状态方式传输、访问和操作文本数据。当正确部署后，REST 为互联网上不同应用程序之间提

供了一致的互操作性。无状态（stateless）这个术语�关重要，它使得应用程序可以用不可知的方式进行通信。 RESTful

API 通过统一资源定位符地址（URL）公开服务。URL 名称将资源的区分为接受内容或返回内容。RFC 1738 中定义了

URL

scheme，可以在这里找到:

https://tools.ietf.org/rfc/rfc1738.txt

RESTful URL 类似于下面这个 library API：

http://fakelibrary.org/library

实际公开的不一定是某种任意的服务，而是代表对消费者有价值的信息资源。URL 作为资源句柄，可以请求、更新或删

除内容。

开始把服务发布到某个地方，然后开始与 REST 服务进行交互。返回的内容可能是 XML、JSON 格式，或者更确切地

说是像 Atom 或自定义 MIME 类型等超媒体格式。虽然一般建议尽可能重用现有的格式，但是对正确设计的媒体类型正

在变得越来越宽容。

需要请求资源的时候，客户机会发一个超文本传输协议（HTTP）GET 请求，例如在浏览器中键入一个 URL 然后点击回

车，选择书签，或者点击锚引用链接。

curl

http://fakelibrary.org/library

curl ‒H "Accept:application/json" http://fakelibrary.org/library

译注：杜威�进制图书分类法由美国图书馆专家⻨尔威

杜威发明，于

1876

年�次发表，历经

次的�改版。该分

类法以三位数字代表分类码，共可分为

个�分类、

100

个中分类及

1000

个�分类。

http://fakelibrary.org + /book/isbn/978-0596801687

通过编程方式与 RESTful API 交互，有数�个客户端 API 或工具可供选择。使用 curl 命令行工具，可以输入以下命令：

上面的命令使用默认格式，但你可能不需要这种格式的信息。幸运的是 HTTP 有一种机制，可以指定返回信息的格式。

在请求中指定 "Accept" 头，如果服务器支持这种格式，会以指定的格式返回。这个过程称为内容协商，这是 HTTP

中未被充分利用的功能之一，可以使用一个类似于上面例子中的 curl 命令来指定：

由于资源名称与内容格式是独立的，从而让请求不同格式信息成为可能。虽然 REST 中的

“

”

的含义是

“

表现

”

而

非“资源

”

，

但是应该在构建系统时允许客户端指定请求的内容格式，请牢记这一点。在我们的例子中 library API 可能

包含以下 URL：

http://fakelibrary.org/library：图书馆基本信息，搜索图书、DVD等相关资源基本功能的链接。

http://fakelibrary.org/book：存放书籍的

“

信息空间

”

。从概念上说，这里可能会存放所有的书籍。显

然，如果这个问题得到解决，我们不会希望返回所有图书，而是希望通过类别、搜索关键词等来检索图书。

1234

：在书籍的信息空间里，我们可以指定类别浏览，例如成人小

说、�童书籍、园艺书籍等。使用杜威�进制图书分类法是可行的，但我们也可以想象自定义分组。问题的关

键在于，这种

“

信息空间

”

可能是无限的，而且可能收到人们实际关心的信息类型影响。

978

0596801687

：提到某本具体的书，应该包括书名、作者、出版

商、系统中的拷贝数、可用拷贝数等信息。

就图书馆用户而言，上面提到的这些 URL 可能就是只读的，但是图书馆员使用应用程序时实际上可以操作这些资源。

例如添加一本新书，可以向 main/book 地址 POST 一个 XML。使用 curl 提交，看起来可能像这样：

此时，服务器可能会对提交的内容进行校验，创建与图书相关的记录，并返回响应代码201——表示已创建新资源。新资源的

URL 可以在响应的 Location 头中找到。

请求一个重要特性：每次请求都包含了充足的状态信息来响应请求。这为服务器的可见性和无状态创造了条

件，并为扩展系统和识别发送的请求内容提供了理想特性。对于缓存结果也非常有帮助。服务器地址和请求状态组合成可

计算的

键值，并形成一个结果集：

接下来我们会先介绍

请求。客户端在需要时发出

请求获取指定资源。客户端可以在本地缓存请求结果，服务器

可以在远程缓存结果，系统的中间层可以在请求链路中间缓存结果。这是一个与具体应用程序无关的特性，可以加入系统

设计中。

正因为可以操作资源，也就意味着并不是每个人都可以这样做。我们完全可以建立一个防护模型，要求用户在操作前验证

身份，证明他们具有该操作的授权。在本文的最后，将提供一些提升

服务安全性的内容。

REST Vs

SOAP

curl ‒u username:password -d @book.xml -H "Content-type: text/xml" http://fakelibrary.org/book

把 REST 与 SOAP 划等号是错误的。在这两者之间进行比较，带来的困扰远多于好处。简单来说，它们不是一回事。尽

管可以用这两种方法解决许多架构问题，但是它们不能相互替换。

这种混淆很大程度上源于对

“

是通过 URL 调用 Web 服务

”

这句话的误解。这种观点与 RESTful 架构的功能相

距甚远。如果不全面深入理解 RESTful 的架构实现，就很容易误解 REST 实践的本意。

利用 REST 的最佳方式，是将生产和消费过程中的信息与技术分离实现解耦，进而更好地管理系统，让架构具备以下特

性：

高性能

可扩展

通用

简洁

可修改

这并不是说，基于 SOAP 构建的系统不能具备上述特性。而是当技术、组织或过程的复杂性造成不能在单个事务中完成

请求的生命周期时，这种情况 SOAP 能够发挥最佳效果。

Richardson 成熟度模型

Leonard Richardson 引入了一种成熟度模型，部分阐述了 SOAP 与 REST 之间的区别，并提供一种对不同类型的系统

进行分类的框架。许多人不恰当地称之为

“

”

。可以将这种分类看作系统中不同 Web 技术组件紧密程度的度量标

准：包括信息资源、HTTP 作为应用层协议和作超媒体作为控制媒介。

称其为“成熟度模型”似乎意味着应该只构建“成熟度”最高的系统。这种看法是不合适的。第 2 级是有价值的，从 2

级向 3 级转变通常只是采用了一种新的 MIME 类型。然而，从 0 级到 3 级的转变要困难得多，因此增量式升级转变通

常也会增值。

首先，确定希望公开哪些信息资源。采用 HTTP 作为处理这些信息资源的应用协议，包括内容协商。接下来，当一切就

绪时，使用基于超媒体的 MIME 类型，这样就可以充分享受 REST 的好处了。

动词

动词是用来与服务器资源交互的方法或操作。RESTful 系统中有限的动词让刚接触该的使用者感到困惑和沮丧。看似武

断和不必要的约束，目的是鼓励以应用程序无关的形式提供可预测的行为。通过明确、清晰地定义这些动词的行为，客

SOAP：简单对象访问协议（Simple Object Access Protocol）。是交换数据的�种协议规范，是�种轻量的、简单

的、基于XML的协议。�条 SOAP 消息就是�个普通的 XML �档，包含必需的 Envelope 元素、可选的 Header

元素、必需的 Body 元素和可选的 Fault 元素。

剩余10页未读，继续阅读

评论收藏

内容反馈

版权申诉

小小哭包

粉丝: 1902
资源: 3901

前后端分离开发，RESTful 接口如何设计.docx

最新资源

前后端分离开发，RESTful 接口如何设计.docx

前后端分离开发，RESTful 接口应该这样设计.docx

用于前后端分离接口设计原型

前后台分离开发接口模板

前后端分离做权限控制设计.docx

前后端分离必备的接口规范.docx

使用Eclipse开发基于SpringBoot+JAX-RS的Restful服务.docx

前后端分离springmvc和RESTful理解.docx

JavaScript跨域调用基于JSON的RESTful API_.docx

restful前后端分离api接口文档模板

restful设计风格.docx

Web项目前后端分离的设计与实现.docx

基于Python Flask的简易RESTful API接口，可实现基本的前后端分离+源代码+文档说明

基于前后端分离技术的web开发框架设计.pdf

某小公司RESTful、共用接口、前后端分离、接口约定的实践.docx

RESTful风格的Java后台管理系统开发平台，前后端分离模式，前端采用路由单页面模式.rar

RESTful架构实战.docx

Restful WCF调研.docx

Restful api规范.docx

REST开发者RESTful资源指南.docx

基于SpringBoot+JPA的微信服务号平台点餐系统，前端使用Vue.js，前后端分离，前后端之间通过RESTful接口互通

基于前后端分离架构的图书馆Web系统设计与实现.docx

基于SSM的前后端分离电商网站的设计与实践.docx

基于SpringBoot和Vue开发的前后端分离毕业论文(设计)管理系统-源码

springboot+vue前后端分离脚手架项目.docx

restful前后端分离开发笔记

RESTful图书管理系统架构设计-restful api 设计最佳实践WORD范本.docx

DDD 领域驱动设计 架构（分层六边形RESTful）.docx

Python Flask高级编程之RESTFul API前后端分离精讲第二章节

最新资源

DDD 领域驱动设计架构（分层六边形RESTful）.docx