读书笔记《building-restful-web-services-with-spring-5-second-edition》以下是一些基本知识
随着世界进入大数据时代，仅收集和处理数据已成为我们大多数 Web 应用程序的主要部分，Web 服务也是如此，因为 Web 服务只处理数据，而不是用户的其他部分体验、外观和感觉。尽管用户体验对所有 Web 应用程序都非常重要，但 Web 服务通过从客户端消费服务在处理数据方面发挥着重要作用。
在 Web 服务的早期，简单对象访问协议（SOAP ) 是所有处理 web servicechoice ="id288558266" class="indexterm"> 消费。 SOAP主要用于HTTP和简单邮件传输协议（SMTP) 用于跨相同或不同平台的消息传输。当没有 JavaScript Object Notation (JSON) 格式可用时对于 Web 服务，XML 曾经是only SOAP 可用于 Web 服务消费的可用格式。
然而，在 JSON 时代，Representational State Transfer（REST ) 开始主导基于 Web 服务的应用程序，因为它支持多种格式，包括 JSON、XML 和其他格式。 REST 比 SOAP 简单，REST 标准易于实施 和使用。此外，与 SOAP 相比，REST 是轻量级的。
在本章中，我们将介绍以下主题：
- REST—a basic understanding
- Reactive programming and its basics, including the benefits of Reactive programming
- Spring 5 basics with Reactive programming
- A sample RESTful web service that will be used as a base for the rest of the book
与流行的看法相反，REST 不是一种协议，而是一种用于管理状态信息的架构原则。它主要用于Web应用程序。 REST 由 Roy Fielding 引入以克服 SOAP 中的实现困难。 Roy 的博士论文为检索数据提供了一种简单的方法，无论使用何种平台。您将在 以下 部分中看到 RESTful Web 服务的所有组件。
在 REST 原则中，所有 资源 都由 统一资源标识符 （URI）。
HTTP REST 资源在某些媒体类型（例如 XML、JSON 和 RDF）中表示。此外，RESTful 资源是自描述的，这意味着提供了足够的信息来描述如何处理请求。
在另一个 REST 原则中，客户端通过超媒体与服务器交互，超媒体由服务器动态提供。除了端点，客户端不需要知道如何与 RESTful 服务交互。这一原则被称为超媒体作为应用程序状态的引擎（HATEOAS< /跨度>）。
通过分离客户端和服务器等 REST 实体，我们可以降低 REST 原则的复杂性，这将显示出清晰的界限服务器和客户端。这种解耦将帮助开发人员独立地专注于客户端和服务器。此外，它将有助于管理客户端和服务器的不同角色。
在 REST 原则中，server 不会在服务器端保留任何有关客户端会话的状态；因此，它是无国籍的。如果从单个客户端对服务器进行两次调用，服务器将无法识别这两个调用是否来自同一个客户端。据服务器所知，每个请求都是独立且新的。根据 URL、HTTP 标头和请求正文（包括参数），可能会在服务器端更改操作。
使用 RESTful Web 服务，客户端可以缓存来自服务器的任何响应。 server 可以提及它如何缓存响应以及缓存多长时间。使用缓存选项，客户端可以使用响应而不是再次联系服务器。此外，缓存将通过始终避免客户端-服务器交互来提高可伸缩性和性能。
Note
该原则对于可扩展性具有显着优势。缓存技术将在 第 8 章，性能。
由于 REST 通常利用 HTTP，因此它继承了 HTTP 提供的所有缓存属性。
通过提供分层系统，server 可以隐藏其身份。通过这样做，客户端将不知道他们正在处理哪个服务器。该策略通过提供中间服务器来提供更多的安全控制，并且还支持负载平衡功能。此外，中间服务器可以通过负载平衡和共享缓存来提高可扩展性和性能。
按需编码 (COD) 被视为可选原则。服务器可以通过传输可执行代码来扩展客户端的功能。例如，可以向基于 Web 的客户端提供 以自定义功能。由于按需代码会降低客户端的可见性，因此此约束是可选的。此外，并非所有 API 都需要此功能。
在 Web 应用程序中，REST 通常在 HTTP 上使用。 REST 不需要绑定到任何特定协议。在HTTP REST中，我们主要使用GET、POST、PUT、和 DELETE 方法来改变我们访问的资源的状态。其他 HTTP 方法，例如 OPTIONS、HEAD、CONNECT 和 < code class="literal">TRACE，可用于更高级的操作，例如，用于缓存和调试目的。出于安全和简单的原因，大多数服务器都禁用了高级方法；但是，您可以通过调整服务器配置文件来启用它们。由于 JSON 被用作主要应用程序的主要媒体类型，因此我们也仅将 JSON 媒体类型用于我们的 Web 服务调用。
让我们看一下命令式programming比较 "> 和反应式编程：x = y + z.
在前面的表达式中，假设 y = 10 和 z = 15。在这种情况下，x 值将是 25。 x 的值将在表达式 x = y + z 。 x 的值在这个表达式之后永远不会改变。
这在传统的编程世界中完全没问题。但是，我们可能需要一个场景，当我们更改 < 的值时，我们应该能够跟进 x em>y 或 z。
我们基于场景的新价值观是：
- When y = 20 and z = 15, then x = 35
- When y = 20 and z = 25, then x = 45
上述场景在我们日常编程中经常使用的命令式编程中是不可能的。但在某些情况下，我们可能需要更新 x 的值，对应于 y 或 z。反应式编程是这种场景的完美解决方案。在反应式编程中，x 的值会自动更新，对应于 y< /em> 或 z。
电子表格参考单元格是反应式编程的最佳示例。如果单元格值发生变化，引用的单元格值将自动更新。另一个例子可以在 Model-View-Controller 架构中找到，Reactive 编程可以自动更新附加到 Model 的 View。
反应式编程遵循观察者模式来操作和转换数据流，其中发布者（可观察）根据订阅者的需要发出项目。当 Publisher 发出项目时，Subscriber 会使用那些从 Publisher 发出的项目。与拉取项目的迭代器不同，在这里，发布者将项目推送到订阅者。
由于 Reactive 是非阻塞架构的一部分，因此在我们扩展应用程序时会很有用。此外，在非阻塞架构中，一切都被视为事件流。
我们将在本章后面讨论更多关于 Java 和 Spring 中的 Reactive。
反应式流都是关于处理异步 数据项流，应用程序在收到数据项时对其做出反应。此模型更节省内存，因为它不依赖任何内存数据。
Reactive Streams 有四个主要组件：
- Publisher.
- Subscriber.
- Subscription.
- Processor.
发布者发布数据流，订阅者异步订阅该数据流。处理器无需更改发布者或订阅者即可转换数据流。处理器（或多个处理器）位于发布者和订阅者之间，用于将一个数据流转换为另一个数据流。
Netflix、Pivotal、Twitter、Oracle 和 TypeSafe 的工程师支持 Reactive 流方法。特别是，TypeSafe 对 Reactive Streams 的贡献更大。甚至 Netflix 的工程师也用他们自己的话说：
“使用 RxJava 的响应式编程使 Netflix 开发人员能够利用服务器端并发，而无需担心典型的线程安全和同步问题。”
以下是反应式编程的好处：
- Focuses on business logic
- Stream processing causes memory efficiency
- Overcomes low-level threading, synchronization, and concurrency issues
反应式原则用于实时数据库查询、大数据、实时分析、HTTP/2 等实时案例。
RxJava 由 Netflix 工程师引入，以支持 Java 8 中的 Reactive 模型，并作为 Reactive Streams 的桥梁。但是，Java 开始使用 Java 9 支持 Reactive 模型，并且 Reactive Streams 已作为 java.util.concurrent.Flow。
此外，Pivotal 引入了 Reactor 框架，该框架直接构建在 Reactive 流上，避免了到 Reactive< 的外部桥梁/span> 流。 Reactor 被视为 4th 代 库。
最后，Spring Framework 5.0 添加了 Reactive 特性，包括用于 HTTP 服务器和客户端的工具。 Spring 用户在处理 HTTP 请求时发现注释和控制器很方便，尤其是向框架分派 Reactive 请求和背压问题。
Reactive 模型在资源利用方面似乎很有效，因为它可以用更少的线程处理更高的负载。但是，反应式模型可能不是所有问题的正确解决方案。在某些情况下，如果我们在错误的部分使用 Reactor，可能会使事情变得更糟。
由于我们假设我们的读者 熟悉Spring Framework，我们将直接关注我们将要构建的示例服务.
在本书中，我们将构建一个票务管理系统。为了清楚地了解 Ticket 管理系统及其使用方式，我们将提出一个方案。
假设我们有一个由我们的客户 Peter 和 Kevin 使用的银行 Web 应用程序，并且我们有 Sammy，我们的管理员和 Chloe，客户服务代表 (CSR)，以帮助解决任何银行应用程序问题。
如果 Kevin/Peter 在 Web 应用程序中遇到问题，他们可以在我们的工单管理系统中创建工单。此工单将由管理员处理并发送给处理工单的 CSR。
CSR 从用户那里获取更多信息并将信息转发给技术团队。一旦 CSR 解决了问题，他们就可以关闭问题。
门票 |
|
用户 |
|
在这个票务管理系统中，我们将重点关注：
- Creating a ticket by the user.
- Updating the ticket by the user.
- Updating the ticket status by the admin.
- Updating the ticket status by the CSR.
- Deleting the ticket by the user and admin.
在最初的章节中，我们将讨论用户管理，以在处理 AOP、Spring Security 和 WebFlux 等主题时保持业务逻辑简单。但是，我们将在 第 13 章< /a>，票务管理 - 高级 CRUD 并实现我们之前提到的所有业务需求。在第13章中，票务管理 - 高级 CRUD 您将使用其他章节中使用的所有高级技术来完成我们的业务需求。