山东大学服务开发技术期末复习

逸仙、

已于 2023-06-05 21:24:41 修改

阅读量1.6k

点赞数 11

文章标签：网络服务器数据库微服务

于 2023-06-05 21:11:38 首次发布

本文链接：https://blog.csdn.net/weixin_49693427/article/details/131056272

版权

山东大学服务开发技术期末复习

课后习题

section 1

1.1 请简要论述为什么引入软件服务？

1.2 简述 W3C 定义的 Web 服务技术栈主要组成。

1.3 简述面向服务架构的三个角色和三个操作。

1.4 简述面向服务架构的技术特征。

1.5 概述服务计算发展过程中的标志性进展。

1.1 引入软件服务的主要原因是为了应对软件系统的规模、用户数量和复杂程度的剧增，降低系统各部分的相互依赖，提高组成单元的内聚性，降低组成单元间的耦合程度，以提高系统的可维护性和可扩展性。软件服务是一种松耦合、可重用、粗粒度、可发现和自我包含的软件功能单元，可以通过标准化的接口和协议在网络上进行交互和组合，满足用户的不同需求。

1.2 W3C 定义的 Web 服务技术栈主要由三个核心协议组成，分别是：

简单对象访问协议（Simple Object Access Protocol,SOAP），负责服务通信，它提供了一个标准的封装结构，用来在各种不同的互联网协议（如 SMTP、HTTP 和 FTP）上传输 XML 文档。
Web 服务描述语言（Web Services Description Language,WSDL），用于描述接口，即 Web 服务支持的一系列标准格式的操作。它指定操作的输入和输出参数表示、服务的协议绑定、消息在线传输方式等。
通用描述、发现和集成（Universal Description Discovery and Integration,UDDI），提供了一种通过搜索名称、标识符、类别或 Web 服务实现规范来发布和发现 Web 服务的全局注册表。

除了这三个核心协议之外，Web 服务技术栈还包括了一些扩展协议，如 WS-Security、WS-Reliable Messaging、WS-Policy 等，用于提供服务质量、过程和合成等方面的支持。

1.3 面向服务架构中的三个角色是：

服务使用者：服务使用者可以是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对注册中心中的服务的查询，获得服务描述（接口契约），通过传输绑定服务，并且调用获得服务的功能。
服务提供者：服务提供者是一个可通过网络寻址的实体，它接受和执行来自使用者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务使用者可以发现和访问该服务。
服务注册中心：服务注册中心是服务发现的支撑者。它包含一个可用服务的存储库，以及提供服务使用者查找服务和服务提供者发布服务的接口。

面向服务架构中的三个操作是：

发布：为了使服务可访问，需要将服务描述发布到一个公共空间（服务注册中心）以使服务使用者可以发现和调用它。
发现：服务请求者通过查询服务注册中心来找到满足其要求和标准的服务，获取服务的描述文件并定位服务端口。
绑定和调用：在检索完服务描述之后，服务使用者继续根据服务描述中的信息来绑定协议、调用服务。

1.4 面向服务架构SOA的技术特征有：

服务是自包含和模块化的，即每个服务都有明确的功能边界和职责，并且可以独立部署和运行。
服务可支持互操作性，即不同来源、不同平台、不同语言的服务可以通过标准化的接口和协议进行交互和组合。
服务是松散耦合的，即服务之间的依赖关系尽可能地减少，服务的实现细节对使用者透明，服务的变化不会影响使用者的正常运行。
服务是位置透明的，即服务的物理位置对使用者不可见，使用者只需要知道服务的逻辑地址和接口契约，而不需要关心服务的具体部署情况。
服务可以组成组合模块使用，即可以根据业务需求将多个服务按照一定的流程和逻辑进行组合，形成更高层次的业务功能。

1.5 服务计算发展过程中的标志性进展有：

Web 时代到来，软件系统的资源和数据的整合需求也扩散至跨越 Web 的更广阔的范围；各种地理上分散、所有权互不隶属、技术上完全异构的软件系统之间迫切需要能够跨越网络的隔离，访问远端的软件功能，这就是 Web 服务。
W3C 成立了 Web 服务工作组，由 IBM 和微软领导，负责 Web 服务相关规范的制定。W3C Web 服务工作组将 Web 服务定义为一个软件系统，支持网络上机器到机器的互操作交互；并制定了一系列 Web 服务的技术规范，搭建起 Web 服务的协议技术栈。
面向服务架构（SOA）作为一种软件架构模式被提出和广泛应用，旨在通过将实施和集成业务流程所需要的各项操作开发成服务来实现对解决方案的解耦。SOA 架构最核心的角色是服务使用者、服务提供者和服务注册中心，最核心的操作是发布、发现和绑定。
API 经济兴起，API 成为了开放能力、数据和功能的主要载体。API 可以帮助开发者快速地应用开发与部署、多通道集成、实现敏捷的服务组合，开拓内部和外部服务的市场。众多企业通过 API 的形式对外提供服务和数据，让物联网、大数据、移动应用等领域有了更大的可创造空间。
微服务架构被提出并流行起来，它是一种架构概念，旨在通过将功能分解到各个离散的服务中，以实现对解决方案的解耦。微服务架构强调每个服务都是独立部署和运行、轻量级通信、高内聚低耦合、自治治理等特点，以提高系统的可扩展性、可靠性和敏捷性。
中台概念被提出并广受关注，它是指在前台（面向用户）和后台（面向数据）之间建立一个共享平台或层次，以提供统一、高效、灵活、可复用的能力或资源。中台概念本质上也是解耦，通过抽象出可被复用的能力或资源（如数据中台、算法中台等），支撑前端业务的快速应变。

section 2

2.1 支撑 Web 迅速发展的四个基石技术是什么？

2.2 “RPC 模式”的 Web 服务是如何运作的？

2.3 如何理解面向资源架构 ROA？

2.4 简述 ROA 模式与 RPC 模式服务的主要区别。

2.5 解释何为表述性状态转移 REST。

2.6 概述 RESTful 服务的优势。

2.7 解释何为幂等性？哪些 HTTP 操作具备幂等性？

2.8 解释服务的“无状态性”对于分布式应用的重要性。

2.9 从网上搜索 5 个可用的 REST API，并尝试访问

2.1 支撑 Web 迅速发展的四个基石技术是什么？

支撑 Web 迅速发展的四个基石技术是：

URI：统一资源标识符，是一种用于标识和定位 Web 上的资源的机制，可以通过不同的协议（如 HTTP，FTP，MAILTO 等）访问资源。
HyperText：超文本，是一种包含了对其他资源的引用（超链接）的文本格式，可以实现资源之间的关联和导航。
HTTP：超文本传输协议，是一种基于请求/响应模式的无状态协议，用于在客户端和服务器之间交换资源的表述。
MIME：多用途 Internet 邮件扩展，是一种用于标识和描述资源内容类型的机制，可以让客户端和服务器知道如何处理不同格式的资源（如 HTML，XML，JSON，图片，音频，视频等）。

2.2 “RPC 模式”的 Web 服务是如何运作的？

“RPC 模式”的 Web 服务是一种基于远程过程调用（Remote Procedure Call）的分布式计算协议，它允许客户端通过网络调用服务器上的服务功能。它通常使用 SOAP（简单对象访问协议）作为消息格式，WSDL（Web 服务描述语言）作为服务接口描述，UDDI（通用描述、发现和集成）作为服务注册和发现机制。它的运作过程如下：

客户端通过 UDDI 查询需要调用的服务的 WSDL 描述，并根据 WSDL 生成相应的代理类或存根。
客户端使用代理类或存根构造 SOAP 消息，并通过 HTTP 或其他协议发送给服务器。
服务器接收到 SOAP 消息后，解析消息内容，并根据 WSDL 找到对应的服务功能进行调用。
服务器将调用结果封装成 SOAP 消息，并通过 HTTP 或其他协议返回给客户端。
客户端接收到 SOAP 消息后，解析消息内容，并获取调用结果。

2.3 如何理解面向资源架构 ROA？

面向资源架构（Resource-Oriented Architecture，ROA）是一种基于 REST（表述性状态转移）原则的 Web 服务架构风格，它将 Web 上的任何事物都抽象为资源，并通过 URI 来标识和定位资源。它使用 HTTP 方法（如 GET，POST，PUT，DELETE 等）来表示对资源的操作，并使用不同的媒体类型（如 XML，JSON，HTML 等）来表示资源的状态。它的核心思想是通过操作资源的表述来实现客户端和服务器之间状态的转移。它具有以下特点：

资源导向：所有的服务功能都被抽象为可寻址和可操作的资源。
统一接口：所有的资源操作都遵循 HTTP 协议规范，并使用标准的 HTTP 方法和状态码。
无状态性：每个请求都是独立的，不依赖于之前的请求或会话状态，从而提高了可扩展性和容错性。
超媒体驱动：资源的表述中包含了对其他相关资源的引用（超链接），从而实现了资源之间的关联和导航。

2.4 简述 ROA 模式与 RPC 模式服务的主要区别。

ROA 模式与 RPC 模式服务的主要区别有以下几点：

ROA 模式是面向资源的，而 RPC 模式是面向操作的。ROA 模式将服务功能抽象为资源，并使用统一的 HTTP 方法来操作资源，而 RPC 模式将服务功能抽象为操作，并使用自定义的方法名来调用操作。
ROA 模式是基于资源状态转移的，而 RPC 模式是基于远程过程调用的。ROA 模式通过操作资源的表述来实现客户端和服务器之间状态的转移，而 RPC 模式通过网络传输参数和返回值来实现客户端和服务器之间过程的调用。
ROA 模式使用 HTTP 协议作为通信协议，而 RPC 模式可以使用多种协议作为通信协议。ROA 模式遵循 HTTP 协议规范，并使用标准的 HTTP 方法和状态码，而 RPC 模式可以使用 HTTP，TCP，UDP 等协议，并使用自定义的消息格式和协议绑定。
ROA 模式使用不同的媒体类型作为资源表述格式，而 RPC 模式通常使用 SOAP 作为消息格式。ROA 模式可以使用 XML，JSON，HTML 等媒体类型来表示资源的状态，并根据客户端的需求进行协商，而 RPC 模式通常使用 SOAP 作为消息格式，并根据 WSDL 来描述服务接口。

2.5 表述性状态转移（REST）是一种网络架构风格，它强调从资源的角度来观察和操作网络，而不是从过程或功能的角度。资源是网络上可以被标识、访问和操作的任何事物，比如文档、图片、服务等。资源通过统一资源标识符（URI）来定位，客户端通过向服务器发送不同的 HTTP 方法（如 GET、POST、PUT、DELETE）来获取或改变资源的表述，即资源的某种具体形式，比如 XML、JSON、HTML 等。通过这种方式，客户端和服务器之间的交互就是一种表述性状态转移的过程，即客户端根据获取或发送的资源表述来改变自己的状态，而服务器根据接收或响应的资源表述来改变资源的状态。

2.6

使用统一的接口操作资源
接口更容易使用
无状态性
安全操作和幂等性
更容易实现缓存
更适合开放的API场景

2.7 幂等性是指对同一个资源执行相同的操作多次，结果和副作用都与执行一次时相同。在 HTTP 协议中，GET、PUT、DELETE、HEAD、OPTIONS 和 TRACE 这些方法具备幂等性，而 POST 方法不具备幂等性。例如，对同一个资源多次执行 GET 方法，只会返回相同的资源表述，不会改变资源或服务器的状态；而对同一个资源多次执行 POST 方法，可能会创建多个新的资源或产生其他不可预期的结果。

2.8 无状态性是指服务端不保存客户端的任何状态信息，每次客户端请求都是独立且完整的，包含所有必要的信息。无状态性对于分布式应用具有重要意义，因为它可以带来以下好处：

简化服务端的设计和实现，无需维护客户端状态信息或会话数据。
提高服务端的可扩展性和可靠性，可以方便地增加或替换服务器节点，避免单点故障或性能瓶颈。
增强服务端和客户端之间的解耦性和通用性，可以支持多种类型和数量的客户端应用。

section 3


3.1 如何理解资源的本质？

3.2 如何理解表述的本质？

3.3 如何理解资源与表述的关系？

3.4 资源操作仅依赖 HTTP 方法够用么？

3.5 如果 HTTP 方法里没有需要的操作方法，这时候该如何设计？

3.6 何为重载的 POST 操作？为什么 REST 架构风格开发中不建议使用重载的 POST?

3.7 HEAD 方法有什么用处？

3.8 为什么需要善用状态码/响应码?

3.9 如何理解超链接在 Web 中的重要作用？

3.10 请以大家熟悉的电商网站购买商品的过程，列出可能涉及的资源、对资源的HTTP 操作

3.1 资源的本质是指任何可以被标识、命名和操作的事物，它可以是物理的或虚拟的，具体的或抽象的。资源是一种对事物的抽象，它可以有多种表现形式，也可以有多种关联关系。资源是面向资源架构中的核心概念，它体现了面向对象的思想。

3.2 表述的本质是指对资源（在某个特定时刻的）状态的描述，它是一种采用某种数据格式书写成的文档，用于在客户端和服务器端之间进行交互。表述可以有多种格式，如json/xml/html/纯文本等，它们由Content-Type报头来指定。表述不仅包含数据，还包含指向相关资源的链接，以实现超媒体策略。

3.3 资源与表述的关系是一种间接的、动态的和多样的关系。客户端和服务器端并不直接操作资源本身，而是通过资源的表述来间接完成交互，这体现了松耦合和前后端分离的设计原则。资源的表述是根据客户端的请求和服务器端的处理而动态生成的，它反映了资源当前或期望的状态。一个资源可以有多种表述，客户端可以通过内容协商或者不同的URL来获取不同格式或结构的表述。

3.4 资源操作仅依赖HTTP方法是不够用的，因为HTTP方法只定义了协议语义，即客户端想要对资源做什么操作，但没有定义应用语义，即资源具体代表什么含义。HTTP方法也不能覆盖所有可能的操作场景，有些操作可能需要更细粒度或更复杂的逻辑。因此，需要结合资源标识符、报头、消息体等其他元素来实现资源操作。

3.5 如果HTTP方法里没有需要的操作方法，这时候可以有以下几种设计方式：

使用已有的HTTP方法来组合实现需要的操作，比如使用GET和POST来实现搜索功能。
使用自定义的HTTP方法来扩展协议语义，比如使用SEARCH或COPY等方法来表示特定的操作。
使用重载的POST操作来传递额外的参数或指令来表示需要的操作，比如在POST请求中添加一个_method字段来指定真正想要执行的方法。
使用超媒体链接来引导客户端进行下一步操作，比如在响应中添加一个action字段来表示可用的操作选项。

3.6 重载的POST操作是指将PUT、DELETE、PATCH、LINK和UNLINK等很多操作混同为一个POST操作，并在请求中添加额外信息来区分真正想要执行的方法。这种方式主要是为了兼容只支持GET/POST方法的浏览器或代理。REST架构风格开发中不建议使用重载的POST操作，因为这样会破坏HTTP方法本身所具有的安全性和幂等性等特性，并且会增加开发和维护成本。

3.7 HEAD方法有以下几种用处：

获取服务器发送过来的报头信息（不是资源的表述），这些报头信息包含了关于资源和响应本身的元数据，比如Content-Type、Content-Length、Last-Modified等。
检查一个资源是否存在，如果存在则返回200（OK），如果不存在则返回404（Not Found）或者410（Gone）。
检查一个资源是否被修改过，如果没有修改则返回304（Not Modified），如果修改过则返回200（OK）和Last-Modified等报头。
验证一个资源的缓存是否有效，如果有效则返回304（Not Modified），如果无效则返回200（OK）和新的报头。

3.8 善用状态码/响应码的原因有以下几点：

状态码/响应码是客户端从响应中最先看到的信息，它简要地说明了请求的结果和进展，可以帮助客户端判断是否需要进一步处理响应。
状态码/响应码是HTTP协议的一部分，它们具有标准化和通用化的含义，可以方便不同的客户端和服务器端进行交互和理解。
状态码/响应码可以用于优化性能和资源利用，比如使用缓存相关的状态码可以避免重复请求相同的资源，使用重定向相关的状态码可以引导客户端访问最新或最合适的资源。

3.9 超链接在Web中的重要作用有以下几点：

超链接将Web上的资源链接在一起，形成一个由数十亿计的页面组成的网状结构，使得Web可以作为一个整体按照连通性原则运转。
超链接可以实现超媒体策略，即通过在资源表述中添加指向相关资源的链接，来帮助客户端实现与网络应用程序的交互，提供更多的信息和功能。
超链接可以实现HATEOAS原则，即通过超文本作为应用程序状态的引擎，使得客户端只需要理解超媒体，就能够与服务器端进行交互，而不需要其他额外知识。

3.10 以大家熟悉的电商网站购买商品的过程为例，可能涉及的资源、对资源的HTTP操作如下：

商品资源：客户端可以使用GET方法获取商品资源的表述，包括商品名称、价格、图片、详情等信息。客户端也可以使用POST方法向商品资源发送评论或评分等信息。
购物车资源：客户端可以使用GET方法获取购物车资源的表述，包括购物车中商品的数量、总价等信息。客户端也可以使用POST方法向购物车资源添加商品，或者使用DELETE方法从购物车资源删除商品。
订单资源：客户端可以使用POST方法向订单资源发送创建订单的请求，包括订单中商品、收货地址、支付方式等信息。客户端也可以使用GET方法获取订单资源的表述，包括订单状态、物流信息等信息。客户端还可以使用PUT或PATCH方法向订单资源发送修改订单或取消订单的请求。

section 5

5.1 概述领域驱动设计（Domain-Driven Design，DDD）的思想。

5.2 概述理解领域、识别资源、划分服务的过程。

5.3 怎样理解“客户端要尽可能忠实地渲染收到的表述并不将自己的主观判断掺杂其中”。

5.4 概述 Rest 成熟度模型几个层级的区别

5.1 领域驱动设计（Domain-Driven Design，DDD）的思想是一种建模方法，它针对一个领域内的各个业务需求进行建模，领域可以简单理解为软件需求分析中的业务场景对应的业务域，每一个领域又可以分为问题域和解决方案域。领域驱动设计本身就是要完成从问题域到解决方案域的映射和抽象，它同时提供了战略（宏观）和战术（细化）上的建模方法和工具。领域驱动设计的目的是让开发者和领域专家能够更好地沟通和理解业务需求，以及设计出符合业务逻辑和规则的软件系统[¹] [²]。

5.2 理解领域、识别资源、划分服务的过程是一种面向资源进行 RESTful 服务设计的方法，它可以参考领域设计的思路进行。首先要定义领域对象，将领域对象建模为对应的资源，然后再考虑这个资源应该暴露哪些能力接口。具体来说，这个过程包括以下几个步骤[³]：

导入场景：分析服务所属的业务场景和用户需求，理解实现这些需求的逻辑。
理解事件：根据业务行为中发生的事件来梳理系统的数据和行为，从而进行合适的建模。
聚合对象：根据业务单一职责和高内聚原则，找出相关联的领域对象，并将它们组织成一个聚合，聚合是一组具有不变性约束和全局唯一标识的实体和值对象。
划分边界：根据业务语义和上下文关系，将多个聚合划分到不同的限界上下文中，限界上下文定义了子领域的边界和内部一致性，以及与其他限界上下文之间的交互方式。
识别资源：根据聚合内部的实体和值对象来识别资源，并确定资源是否需要暴露给外部模块或应用。
划分服务：根据限界上下文和聚合来划分服务，并考虑服务之间的依赖关系、通信方式、事务管理等影响因素。
在边界上定义接口：根据资源所提供的功能和状态转换来定义接口，并遵循 RESTful 的原则和约束。

5.3 “客户端要尽可能忠实地渲染收到的表述并不将自己的主观判断掺杂其中”是指客户端在与服务端交互时，应该按照服务端提供的表述来展示资源状态和可用操作，并不应该对表述进行修改或添加自己的逻辑。这样做有利于保持客户端和服务端之间的松耦合关系，使得客户端可以适应服务端的变化，而不需要频繁地更新或重写。客户端应该把自己的职责限定在用户界面的呈现和用户输入的响应上，而不应该涉及服务端的业务逻辑和规则。

5.4 REST 成熟度模型是由 Leonard Richardson 提出的一种评估 RESTful 服务质量的方法，它将 RESTful 服务分为四个层级[⁴：

第 0 层：使用 HTTP 作为传输协议，但只使用一个 URI 和一个 HTTP 方法（通常是 POST），忽略了资源和超媒体的概念，相当于远程过程调用（RPC）。
第 1 层：使用多个 URI 来区分不同的资源，但只使用一个或少数几个 HTTP 方法，没有充分利用 HTTP 的语义，也没有使用超媒体来指导客户端。
第 2 层：使用多个 URI 和多个 HTTP 方法来对资源进行操作，充分利用了 HTTP 的语义，但没有使用超媒体来指导客户端。
第 3 层：使用多个 URI、多个 HTTP 方法和超媒体来对资源进行操作，充分利用了 HTTP 的语义和超媒体的动态性，达到了 REST 的最佳实践。

section 6

6.1 概述只读的面向资源服务的设计过程。
6.2 资源 URI 设计应该遵循哪些原则？
6.3 为什么需要把资源链接起来？
6.4 如何理解作为查询结果的集合资源？
6.5 为什么需要规划服务交互的响应？

6.1 概述只读的面向资源服务的设计过程。

只读的面向资源服务的设计过程主要包括以下几个步骤：

理解服务功能，确定服务要提供哪些数据和算法。
梳理必要的资源，根据数据和算法的特点，划分和组织资源。
创建只读资源，为每个资源分配一个唯一的 URI，并确定资源之间的层次结构和关系。
设计资源表述，选择合适的数据格式和语义标记，传达资源的当前状态和邻近状态。
把资源互相链接起来，通过超链接和表单等方式，实现资源的连通性和可发现性。
规划服务之间的响应

可以简单回答:

1）资源分析与设计
2）设计资源表述
3）建立资源之间的链接
4）规划服务交互的响应

6.2 资源 URI 设计应该遵循哪些原则？

资源 URI 设计应该遵循以下几个原则：

用路径变量来表达层次结构，如 /parent/child。
用矩阵 URI，在路径变量里用标点符号表达多个信息，如经纬度：/24.9195,17.821。
用查询变量来表达算法的输入，例如：/search?q=jellyfish&start=20。
保持 URI 的一致性、简洁性和易读性，避免使用不必要的参数、符号或缩写。
保持 URI 的可扩展性，预留一些空间来适应未来的需求变化。

6.3 为什么需要把资源链接起来？

把资源链接起来有以下几个好处：

提高资源的可访问性，用户可以通过跟随链接从一个资源跳转到另一个相关的资源，而不需要知道所有资源的 URI。
提高资源的可发现性，用户可以通过链接发现服务提供的更多功能和信息，而不需要额外的文档或说明。
提高资源的可维护性，服务端可以在不影响客户端的情况下修改或增加资源和链接，提高灵活性和兼容性。

6.4 如何理解作为查询结果的集合资源？

作为查询结果的集合资源是指根据用户输入的条件或参数，动态生成并返回一组符合条件的资源。这种资源不是静态存储在服务端的，而是根据算法或逻辑实时计算出来的。这种资源通常用查询变量来表达其 URI，并且可以包含对其他相关资源的链接。例如：

/search?show=ATM

这个 URI 表示搜索当前地图中所有 ATM 银行的集合资源，它可能包含每个银行的名称、地址、位置、地图等信息。

6.5 为什么需要规划服务交互的响应？

规划服务交互的响应是指确定服务在收到客户端请求后，应该如何处理请求，并返回什么样的状态码、头部信息和正文内容。这样做有以下几个目的：

提高服务的可靠性，通过规范化和标准化响应格式，避免出现错误或异常情况。
提高服务的可理解性，通过使用合适的状态码和头部信息，向客户端传达请求处理结果和相关元数据。

section 7

7.1 什么服务安全性很重要？
7.2 RESTful 服务的安全性主要包括哪三个方面的考虑？
7.3 简述 HTTP 标准身份验证的过程。
7.4 简述 Basic 认证与 Digest 认证的区别。
7.5 简述 OAuth2.0 发放令牌和更新令牌的过程。
7.6 简述 JWT 令牌的组成。
7.7 为什么说用户也是一种资源？
7.8 暴露资源可执行接口主要有哪些考虑？

7.1 服务安全性很重要，因为：

它可以保护通过 RESTful 服务提供的数据不被盗取或篡改。
它可以防止 DOS 攻击，导致 RESTful 服务进入非功能状态。
它可以避免商业影响，因为越来越多的平台通过 RESTful 服务传输信息，提供功能性。

7.2 RESTful 服务的安全性主要包括以下三个方面的考虑：

对客户端做身份认证和授权，以验证身份和授予访问资源的权限。
对敏感的数据做加密，并且防止篡改，例如使用 SSL、Base64、随机数等技术。
身份认证之后的访问控制，例如使用基于角色的访问控制（RBAC）机制，限制不同角色和用户组的权限。

7.3 HTTP 标准身份验证的过程如下：

服务器端向客户端返回 401（Unauthorized，未授权）状态码，并在 WWW-Authenticate 头中添加如何进行验证的信息，其中至少包含有一种质询方式。
客户端根据质询提供身份验证凭证，例如用户名和密码，并在请求中添加 Authorization 字段进行验证。
服务器端对客户端的凭证进行检查，如果有效，则处理请求并返回响应；如果无效，则继续返回 401 状态码，并在 WWW-Authenticate 响应报头里指出如何发送有效的凭证。

依据：Basic 认证是最古老也是最简单的标准。认证模式是：用户名 + 密码 + Base64（对用户名和密码做哈希的基础算法）。Basic 认证工作原理是用户输入正确的用户名和密码，系统会允许登录。在未进行认证或认证失败的情况下，服务端会返回 401（Unauthorized，未授权）状态码给客户端，并在响应报文中添加 WWW-Authenticate 标头；客户端输入正确的用户名和密码，认证成功后，浏览器会将凭据信息缓存起来，以后再进入时，无需重复手动输入用户名和密码。

7.4 Basic 认证与 Digest 认证的区别如下：

Basic 认证是最简单的标准，它使用 Base64 编码格式传输用户名和密码到服务端进行认证，但 Base64 不是一种加密，只是一种编码转换，可以被逆向解码，等同于明文，因此 Basic 认证传输认证信息是不安全的，需要配合 HTTPS 来保证信息传输的安全。
Digest 认证是 Basic 认证的升级版，它使用摘要算法（hash）对密码进行加密，并且使用随机数（nonce）来防止重放攻击。摘要算法是一种单向函数，无法通过摘要反推出密码。随机数是由服务器生成并发送给客户端，在计算摘要时附加到密码上去，使得每次计算的摘要随着随机数变化而变化。Digest 认证传输认证信息是相对安全的，但仍然存在一些缺点和风险。

7.5 OAuth2.0 发放令牌和更新令牌的过程如下：

客户端向资源所有者请求授权。授权请求可以直接向资源所有者提出，或者通过授权服务器作为中间人间接提出。
客户端收到一个授权许可，它是一个代表资源所有者授权的凭证。使用本规范中定义的四种授权类型中的一种或使用扩展授权类型来表达。
客户端通过与授权服务器进行身份验证并出示授权许可来请求一个访问令牌。
授权服务器对客户进行认证，并验证授权许可。如果有效，则颁发访问令牌和刷新令牌。
客户端向资源服务器请求受保护的资源，并通过出示访问令牌进行认证。
资源服务器验证访问令牌，如果有效，则提供受保护的请求。
当访问令牌过期时，客户端使用刷新令牌向授权服务器请求一个新的访问令牌。
授权服务器对客户进行认证，并验证刷新令牌。如果有效，则颁发新的访问令牌和刷新令牌。

7.6 JWT 令牌的组成如下：

头部（header）：包含加密算法和令牌类型等信息，使用 Base64Url 编码成第一部分。
载荷（payload）：包含用户信息、签发时间和过期时间等信息，使用 Base64Url 编码成第二部分。
签名（signature）：使用编码后的头部和载荷以及保存在服务器端的一个密钥，然后使用头部中指定的签名算法进行签名，作为第三部分。

7.7 说用户也是一种资源，是因为：

用户本身可以存储一些其他业务逻辑所必要的非敏感信息，例如用户画像、用户偏好、用户行为等，这些信息可以用于提供更加个性化的服务或改进应用。
用户本身可以与其他资源建立某种关联关系，例如用户自定义地点、用户收藏、用户评论等，这些关联可以用于增加用户参与度或拓展业务。
用户本身可以被创建、修改、删除、获取等操作，这些操作需要通过唯一的标识 URI 和统一的接口来实现，符合 RESTful 服务的设计原则。

7.8 暴露资源可执行接口主要有以下几个考虑：

客户端是否可以创建、修改、删除或获取这种资源，以及需要哪些权限和条件。
客户端创建或修改资源时，谁负责决定资源的 URI，客户端还是服务器。
客户端创建或修改资源时，需要提供哪些信息和格式作为资源表述。

section 8

8.1 概述可读写的资源服务的设计过程。
8.2 将多种资源整合到一起，有什么好处？有哪些考虑？
8.3 设计来自客户端的表述与发给客户端的表述有何区别？
8.4 将资源设计为从属资源有什么好处？

8.1 可读写的资源服务的设计过程可以分为以下六个步骤：

资源分析与设计：确定服务提供的资源类型，为每种资源定义 URI，确定资源之间的关系和从属关系，确定资源的属性和状态。
规划资源暴露的操作：确定每种资源支持哪些 HTTP 方法，如 GET、POST、PUT、DELETE 等，以及它们对应的语义和效果。
设计服务端资源表述：确定服务端返回给客户端的资源表述的格式和内容，如 XML、JSON、HTML 等，以及表述中包含的数据、链接、元数据等。
设计客户端资源表述：确定客户端发送给服务端的资源表述的格式和内容，如 XML、JSON、HTML 等，以及表述中包含的数据、链接、元数据等。
建立资源之间的链接：在资源表述中嵌入超媒体控件，如链接、表单等，以便客户端可以根据服务端提供的信息进行导航和交互。
规划服务交互的响应：确定服务端对客户端请求的响应方式，如响应代码、响应报头、响应主体等，以及响应中包含的错误信息、重定向信息、缓存信息等。

8.2 将多种资源整合到一起，有以下几个好处：

提高了服务的可用性和可伸缩性，因为可以根据不同类型的资源分配不同的处理方式和存储方式。
提高了服务的灵活性和可扩展性，因为可以根据不同类型的资源提供不同的功能和接口。
提高了服务的易用性和可维护性，因为可以根据不同类型的资源提供不同的文档和说明。

将多种资源整合到一起，需要考虑以下几个方面：

资源之间的关系和从属关系，如何在 URI 中体现出来，以便客户端可以方便地访问和操作相关联的资源。
资源之间的一致性和完整性，如何在更新或删除某个资源时保证其关联或从属的资源也能得到相应的处理。
资源之间的冲突和竞争，如何在多个客户端同时访问或修改某个资源时保证其正确性和安全性。

8.3 设计来自客户端的表述与发给客户端的表述有以下几个区别：

来自客户端的表述通常是用于创建或修改服务端上的某个资源，所以它需要包含足够的数据来描述这个资源的属性和状态。发给客户端的表述通常是用于展示或返回服务端上的某个资源，所以它需要包含足够的数据来展示这个资源的属性和状态。
来自客户端的表述通常不需要包含超媒体控件，因为它是由客户端主动发起的请求。发给客户端的表述通常需要包含超媒体控件，因为它是由服务端提供给客户端进行导航和交互。
来自客户端的表述通常需要遵循服务端规定的格式和内容，以便服务端能够正确地解析和处理。发给客户端的表述通常需要考虑客户端的需求和偏好，以便客户端能够正确地解析和展示。

8.4 将资源设计为从属资源有以下几个好处：

简化了资源的 URI，因为可以利用从属资源的父资源的 URI 作为前缀，避免了重复或冗余的信息。
体现了资源之间的层次结构和语义关系，因为可以通过从属资源的 URI 明确地表示出它与父资源的关联关系。
方便了资源的访问和操作，因为可以通过父资源的表述提供从属资源的链接或表单，使客户端可以方便地获取或修改从属资源。

section 9

9.1 评价一个服务系统有哪些可量化的指标？
9.2 怎样体现服务请求端与提供端的解耦？
9.3 将服务流程设计为异步处理有什么好处？
9.4 简述竞争消费者模式？
9.5 你身边有没有类似咖啡店这样的服务系统？试举一例子。
9.6 本章展现的例子蕴含了哪些 Restful 服务设计的思想？

9.1 评价一个服务系统有哪些可量化的指标？

一个服务系统的可量化指标可以包括以下几个方面[¹]：
- 单位时间的总体服务吞吐量：指服务系统在一定时间内能够处理的服务请求的数量，反映了服务系统的效率和规模。
- 单个服务平均等待时间：指服务请求从提交到开始被处理所花费的时间，反映了服务系统的响应速度和顾客满意度。
- 单个服务平均服务时间：指服务请求从开始被处理到完成所花费的时间，反映了服务系统的执行能力和质量。
- 单个服务提供者的平均服务能力：指每个服务提供者在一定时间内能够处理的服务请求的数量，反映了服务系统的人力资源利用率和分配合理性。

9.2 怎样体现服务请求端与提供端的解耦？

服务请求端与提供端的解耦是指两者之间不需要直接同步交互，而是通过某种中间介质或机制来传递信息和状态[²]。这样可以增加两者之间的独立性和灵活性，降低耦合度和依赖性，提高可扩展性和可维护性。
在咖啡店的例子中，服务请求端与提供端的解耦体现在以下几个方面：
- 订单队列：收银员将顾客的订单放入一个队列中，咖啡师从队列中取出订单进行制作。这样，收银员不需要等待咖啡师完成制作，也不需要知道咖啡师的具体情况，只需要关注订单队列的状态。同样，咖啡师不需要等待收银员接收订单，也不需要知道收银员的具体情况，只需要关注订单队列中的内容。
- 杯子记号：收银员在顾客的杯子上写上简写姓名或者打印一个不干胶贴，作为订单的唯一标识。这样，咖啡师可以根据杯子记号来识别不同顾客的订单，而不需要与顾客直接沟通。同样，顾客可以根据杯子记号来取走自己的咖啡，而不需要与咖啡师直接沟通。
- HTTP 操作：顾客通过 HTTP 动词（如 POST, PUT, OPTIONS 等）来向咖啡订单服务发送表述（如 XML 文件），表达自己的操作意图（如创建、修改、查询等）。这样，咖啡订单服务可以根据 HTTP 动词和表述来处理不同类型和内容的请求，而不需要与顾客直接沟通。同样，顾客可以根据 HTTP 响应（如状态码、报头、表述等）来获取咖啡订单服务处理结果和下一步操作提示，而不需要与咖啡订单服务直接沟通。

9.3 将服务流程设计为异步处理有什么好处？

将服务流程设计为异步处理有以下几个好处[³]：
- 提高并发性：异步处理可以使多个任务同时进行，而不需要等待前一个任务完成。这样，可以提高服务系统的并发性，增加单位时间内的服务吞吐量，优化资源利用率。
- 提高响应性：异步处理可以使服务请求快速得到响应，而不需要等待服务提供者完成处理。这样，可以提高服务系统的响应性，减少顾客的等待时间，提高顾客满意度。
- 提高可扩展性：异步处理可以使服务请求和提供之间的耦合度降低，而不需要依赖于特定的服务提供者。这样，可以提高服务系统的可扩展性，方便增加或减少服务提供者的数量，适应不同的业务需求。

9.4 简述竞争消费者模式？

竞争消费者模式是一种设计模式，用于使多个并发使用者能够处理在同一消息通道上接收的消息[⁴。这种模式使系统能够同时处理多条消息，以优化吞吐量，提高可伸缩性和可用性，并平衡工作负载。
在咖啡店的例子中，竞争消费者模式体现在以下方面：
- 消息通道：订单队列是一个消息通道，用于存储和传递顾客的订单信息。
- 并发使用者：咖啡师是并发使用者，用于从订单队列中获取和处理订单信息。
- 竞争消费：当订单队列中有多个订单时，多个咖啡师可以同时从队列中取出不同的订单进行制作。当订单队列中只有一个订单时，只有一个咖啡师可以取出该订单进行制作。这样，咖啡师之间就形成了竞争消费的关系。

9.5 你身边有没有类似咖啡店这样的服务系统？试举一例子。

我身边有类似咖啡店这样的服务系统的例子是快递公司[⁵。快递公司也是一个提供物流服务的系统，它也有类似于咖啡店的角色、实体、交互和工作流。具体如下：
- 角色：快递公司有寄件人、收件人、快递员、分拣员等角色。
- 实体：快递公司有快递包裹、运单、分拣架等实体。
- 交互：快递公司有寄件、收件、分拣、派送等交互。
- 工作流：快递公司有以下工作流：
  - 寄件人通过电话或网站预约寄件，填写运单信息，付款。
  - 快递员上门取件，将快递包裹和运单一起放入车辆中。
  - 快递员将车辆中的快递包裹和运单送到分拣中心。
  - 分拣员根据运单信息将快递包裹和运单放入对应的分拣架中。
  - 分拣员将分拣架中的快递包裹和运单装入对应目的地的车辆或飞机中。
  - 快递员将车辆或飞机中的快递包裹和运单送到目的地分拣中心或派送点。
  - 快递员根据运单信息将快递包裹和运单派送给收件人，并签收。

9.6 (存疑)

资源导向：服务以资源为中心，通过 URI 来标识和访问资源，通过 HTTP 方法来操作资源，通过表述来传递资源的状态和信息。
统一接口：服务遵循 HTTP 协议的规范，使用标准的 HTTP 方法、状态码、报头和媒体类型，提供一致的服务接口。
无状态性：服务不保存客户端的上下文信息，每个请求都是独立的，可以被任何服务节点处理，提高了服务的可扩展性和可靠性。
超媒体驱动：服务在资源的表述中包含了与其他资源的链接，指导客户端如何进行下一步的操作，实现了应用状态的转移。

section 12

12.1 解释在 SOA 中，UDDI 是如何起到服务发布中介作用的？
12.2 为什么服务接口需要开放？
12.3 OpenAPI 工具 Swagger 的运作机制是什么？

2.1 在 SOA 中，UDDI 是如何起到服务发布中介作用的？

UDDI 是一种用于描述、发现和集成 Web 服务的协议，它定义了一系列技术规范，使商家可以用来描述自身、他们的产品和服务，以及他们在 Web 的商业过程。UDDI 还提供了一个全球企业注册表（UDDI 中心），能使跨越多个平台上的企业方便地搜索和发现对方。这个注册表将是免费的。

UDDI 的核心是一个 XML 文档，称为 WSDL（Web 服务描述语言），它描述了 Web 服务的功能、位置和接口。WSDL 文档可以被发布到 UDDI 中心，也可以被直接传递给服务消费者。UDDI 中心提供了一个标准化的查询接口，使服务消费者可以根据不同的条件（如服务类型、地理位置、关键字等）搜索和查找合适的 Web 服务。

因此，UDDI 在 SOA 中起到了服务发布中介的作用，它为 Web 服务提供了一个统一的目录，使服务提供者和服务消费者能够互相发现和沟通，从而实现服务间的集成和协作。

12.2 为什么服务接口需要开放？

服务接口是指服务提供者向外部暴露的一组操作，用于访问和使用服务资源。服务接口需要开放的原因有以下几点：

开放服务接口可以增加服务的可见性和可用性，使更多的潜在用户和合作伙伴能够发现和利用服务资源，从而扩大服务的影响力和价值。
开放服务接口可以促进服务的标准化和规范化，使不同的平台、语言和技术能够通过统一的协议和格式进行交互，从而提高服务的互操作性和兼容性。
开放服务接口可以激发服务的创新和改进，使第三方开发者能够基于现有的服务资源构建新的应用和功能，从而丰富服务的多样性和灵活性。
开放服务接口可以实现服务的解耦和分离，使前端和后端能够各自独立开发、测试和部署，通过 API 进行交互，从而提高服务的可维护性和可扩展性。

12.3 OpenAPI 工具 Swagger 的运作机制是什么？

Swagger 是一种基于 OpenAPI 规范（OAS）的 API 开发工具框架，支持从设计和文档到测试和部署的整个 API 生命周期的开发。Swagger 的运作机制主要包括以下几个方面：

Swagger 通过注解或者 YAML/JSON 文件来定义 API 的元数据、路径、参数、响应等信息，遵循 OAS 的标准格式。
Swagger 通过代码生成器或者插件来根据 API 定义生成客户端或者服务器端代码，支持多种编程语言和框架。
Swagger 通过 UI 或者编辑器来可视化展示 API 定义，并提供交互式的测试功能，支持在线修改和预览 API 文档。
Swagger 通过 Inspector 或者 Hub 来检查 API 的请求和响应，并提供协作和管理功能，支持分享和发布

section 13

13.1 解释微服务架构的核心思想。
13.2 概述微服务架构的 9 大特性。
13.3 概述 Spring Cloud Netflix 技术体系。
13.4 概述 Spring Cloud 微服务架构技术体系。
13.5 结合本章学习，综合论述你对微服务架构的理解。

13.1 微服务架构的核心思想是通过将业务功能和需求分解到各个不同的服务中进行管理，实现对业务整体解耦。围绕业务模式创建应用服务，应用服务可独立地进行开发、迭代、部署，从而可以使项目架构更加清晰明确。

13.2 微服务架构的 9 大特性是：

通过服务实现组件化，服务具有明确的服务边界，更易于开发和管控，最主要是也更易于单独部署和扩展。
围绕业务能力组织开发，团队是跨职能的，包括开发所需的全部技能：用户体验、数据库和项目管理，每个团队都要实现包括用户界面、持久性存储和外部协作等全部功能的一个微服务。
针对产品而不是项目，团队更适合全生命周期维护软件产品，对开发的软件负全部责任。这与目前流行的 DevOps 思想一致，即开发、技术运营与质量保障整合在一起。
智能端点和哑管道，服务间尽可能地解耦和内聚，每个服务拥有自己的域逻辑，只接收请求，适当地应用逻辑并产生响应。服务间使用简单的 REST 式的简单协议，避免复杂的编排协议。
去中心化治理，允许团队采用不同的、适用的技术，因为团队要对他们构建的软件的各方面负责，包括 7*24 小时的运营，传统的集中治理模式显然是不适合的。
分散化的数据管理，让每个服务管理自己的数据库，或者同一数据库技术下的不同实例，亦或完全不同的数据库系统。这种情况下，分布式事务难以处理，因此微服务架构更强调服务间的无事务协作。
基础设施自动化，利用云计算等技术快速构建、部署和运行微服务，并提供基础设施自动化技术。
为失败设计，通过断路器等机制来缓解分布式系统中可能出现的故障，并提供后备选项来实现容错功能。
进化设计，通过构建一些微服务 API 的方式来添加新的功能，实现更细粒度的发布计划。

13.3 Spring Cloud Netflix 是基于 Netflix 公司开源的一套微服务框架（Netflix OSS）进行封装和整合而成的。Netflix OSS 提供了一系列解决方案来支持微服务架构中常见的问题和挑战。Spring Cloud Netflix 技术体系主要包括以下几个方面：

服务发现框架——Netflix Eureka：提供了一个服务注册中心、服务发现客户端和一个可方便查看所有注册服务的界面。Eureka 是 C/S 架构，由 Server 端和 Client 端组成；Eureka Server 主要用于定位服务，以实现负载均衡和中间层服务器的故障转移； Eureka Client 使得与服务的交互变得更加容易，所有微服务使用 Eureka 的服务发现客户端来将自己注册到 Eureka 的服务器上。
客服端负载均衡——Netflix Ribbon：提供了一种基于 HTTP 和 TCP 的客户端负载均衡器。Ribbon 可以在服务实例之间分配负载，并提供多种负载均衡策略。
服务网关——Netflix Zuul：提供了一个反向代理的功能，将请求转发到粗粒度服务上，并做一些通用的逻辑处理，如鉴权、限流、路由、监控等。Zuul 可以精确控制 API 层，集成 Spring Cloud 服务发现和客户端负载均衡解决方案，以简化配置和维护。
服务调用映射——Open Feign：提供了一种声明式的 Web 服务客户端，通过编写简单的接口和使用注解就可以定义好 HTTP 的请求参数、格式、请求地址等信息。Feign 不做任何请求处理，通过处理注解相关信息生成 Request，并对调用返回的数据进行解码，简化了 HTTP API 的开发。
监控和断路器——Hystrix：提供了一种能进行“熔断”和“降级”的库，可通过添加等待时间容限和容错逻辑来帮助控制分布式服务之间的交互。Hystrix 通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现容错功能，提高了整个系统的弹性。Hystrix 还提供了一个监控面板（Hystrix Dashboard）和一个监控聚合工具（Turbine）来实时观察 Hystrix 熔断信息。

13.4 Spring Cloud 微服务架构技术体系是一个完整的微服务架构，包括一整套帮助开发者在 Spring Boot 基础上轻松实现微服务项目的组件。Spring Cloud 微服务架构技术体系主要包括以下几个方面：

服务发现——Service discovery：提供了 DiscoveryClient 实现，可以支持多种流行的注册中心，如 Eureka、Consul、Zookeeper 等。Spring Cloud Load Balancer 可以在服务实例之间分配负载。
API 网关——API gateway：提供了 Spring Cloud Gateway 组件，可以支持多种协议和路由规则，集成 Spring Cloud 服务发现和客户端负载均衡解决方案，以简化配置和维护。
云配置——Cloud configuration：提供了 Spring Cloud Config 组件，可以减轻配置管理的负担，并提供与 Git 等版本控制系统的集成，以确保配置安全。
断路器——Circuit breakers：提供了三种流行的选项：Resilience4J、Sentinel 或 Hystrix。这些组件可以帮助缓解分布式系统中可能出现的故障，并提供后备选项来实现容错功能。
追踪——Sleuth：提供了一种检测应用程序的方式，并与 Zipkin 结合使用时，就可以将可能遇到的任何延迟问题归零。

13.5

微服务架构是一种软件开发模式，它将一个复杂的应用程序分解为多个小型的、独立的、松耦合的服务，每个服务负责一个单一的业务功能，可以使用不同的编程语言、技术栈和数据存储技术开发和部署。微服务架构的核心思想是通过服务的拆分和组合，实现业务的快速迭代和交付，提高系统的可扩展性、可维护性和可靠性。

微服务架构有以下九大特性：

通过服务实现组件化，使得服务可以独立替换和升级。
围绕业务能力组织开发团队，提高团队的协作效率和自主性。
针对产品而不是项目，让团队负责软件的全生命周期。
智能端点和哑管道，使用简单的通信机制，让服务之间尽可能地解耦和内聚。
去中心化治理，允许团队采用适合自己的技术选择，避免过度标准化。
分散化的数据管理，让每个服务管理自己的数据，避免分布式事务的复杂性。
基础设施自动化，利用云计算和容器技术实现快速部署和运行。
为失败设计，使用断路器、隔离器等机制提高系统的容错能力。
进化设计，利用微服务的灵活性实现业务功能的快速变更和优化。

Spring Cloud 是一个基于 Spring Boot 的微服务开发框架，它提供了一系列与微服务相关的组件和工具，帮助开发者快速构建分布式系统。Spring Cloud 的技术体系主要包括以下部分：

服务发现：使用 Eureka、Consul、Zookeeper 等注册中心实现服务的注册和发现。
API 网关：使用 Spring Cloud Gateway 实现请求的路由、过滤、限流等功能。
云配置：使用 Spring Cloud Config 实现配置文件的集中管理和动态刷新。
断路器：使用 Resilience4J、Sentinel 或 Hystrix 实现服务调用的熔断和降级。

section 1 服务计算的概念、发展和应用

服务计算是Web新时代的计算模式，是基于网络的软件服务的集成和交互。
Web开发技术经历了从静态内容到动态内容，从瘦客户端到富客户端，从PC端到移动端的变化。
Web服务是一种支持机器到机器互操作的软件系统，遵循一系列的标准和协议，如SOAP、WSDL、UDDI等。
面向服务架构SOA是一种支持服务导向的IT架构风格，将业务功能分解为可复用的服务，并通过标准接口进行组合和协调。
服务科学是一门跨学科的研究领域，旨在探索服务创新和服务价值的规律和方法。
从ASP到SaaS，软件模式发生了变革，软件从产品向服务转变，用户更关注服务的质量和效果。
微服务架构是一种将应用分解为多个离散的服务的架构概念，提高了系统的灵活性和可扩展性。
中台是一种将企业核心能力封装为标准化的服务，并提供给前台业务使用的架构思想，实现了前后台的解耦和协同。
API经济是一种基于API提供和使用服务的经济现象，推动了数字化转型和生态系统建设。
服务计算有很多典型场景和应用案例，如数据开放、能力开放、平台开放、分析即服务、容器服务、人工智能服务等。

section 2 从RPC到REST

web技术基本架构的基础概念

Web的技术架构是指Web系统的组成和交互方式，一般包括客户端、服务器端、中间件、数据库等层次。Web的技术架构需要考虑可用性、可扩展性、安全性、性能等因素
网络协议是指在网络中传输数据的规则和标准，常见的网络协议有TCP/IP、HTTP、HTTPS、FTP等。网络协议定义了数据的格式、编码、传输方式、错误处理等细节
资源是指Web系统中可以被访问或操作的实体，如文档、图片、视频等。资源可以通过统一资源标识符（URI）来唯一标识和定位
URI是一种字符串，用来表示资源的名称或地址，可以分为统一资源定位符（URL）和统一资源名称（URN）。URL指定了资源的位置和访问方式

RPC和ROA

RPC和ROA是两种不同的Web服务架构风格，它们分别代表了远程过程调用（Remote Procedure Call）和表述性状态转移（Representational State Transfer）。它们的主要区别在于：

RPC是一种面向操作的架构风格，它把Web服务看作是远程的函数或方法，可以通过传递参数和返回值来调用。RPC通常使用SOAP协议来封装和传输XML格式的数据，需要定义复杂的WSDL文档来描述服务接口。RPC关注的是如何实现某个功能，而不是如何表示某个资源。
ROA是一种面向资源的架构风格，它把Web服务看作是网络上的资源，可以通过URI来定位和标识。ROA通常使用HTTP协议来操作资源，利用GET、POST、PUT、DELETE等方法来实现查询、创建、更新、删除等操作。ROA关注的是如何表示某个资源，而不是如何实现某个功能。

RPC和ROA的优缺点各有不同，具体取决于应用场景和需求。一般来说，RPC更适合于需要提供复杂功能、高安全性、跨平台的Web服务，而ROA更适合于需要提供简单功能、高效率、易扩展的Web服务

RESTful服务的优势

使用统一的接口操作资源：RESTful服务把所有Web系统的服务能力抽象为资源，而资源可以通过标准的HTTP方法（GET/PUT/POST/DELETE）来进行增删改查操作，这样可以为Web API定义一致性的操作方式，提高了可用性和可维护性。
接口更易于使用：RESTful服务利用URI来定位资源，利用超媒体（如HTML、XML、JSON等）来表述资源状态，这样可以让客户端和服务器之间的通信更加简单和直观，也更加贴近Web本身的工作方式。
无状态性：RESTful服务遵循HTTP协议的无状态性，即每个请求之间是相互隔离的，不依赖于任何上下文信息。这样可以降低服务器端的复杂度，提高了可伸缩性和可靠性，也方便了客户端的缓存和重试机制。
安全操作与幂等性：RESTful服务区分了安全操作（GET/HEAD）和不安全操作（PUT/POST/DELETE），安全操作不会对服务器端资源造成任何改变，而不安全操作具有幂等性，即多次执行同一个操作与执行一次操作具有相同的效果。这样可以保证数据的一致性和完整性，也避免了重复提交或者丢失提交的问题。
更容易实现缓存：RESTful服务充分利用了HTTP协议对缓存支持的能力，通过使用条件GET请求和响应头域（如Last-Modified、ETag等）来实现客户端和服务器端之间的缓存协商。这样可以节省网络传输带来的开销，提高了响应速度和用户体验。
更适合开放API场景：RESTful服务是一种针对网络应用的开发方式，它的真正价值在于通过接口访问程序，而不是通过浏览器操作程序。使用开放API可以降低开发的复杂性，提高系统的可伸缩性。RESTful服务也更适合像Youtube这样的资源导向的网站，或者像Google、豆瓣、新浪微博等提供公开服务的网站。