HATEOAS 是否会增加对服务器的调用次数？
Does HATEOAS increase the number of calls to server?
我从来没有将 HATEOAS 与 RESTAPI 一起使用，据我所知，HATEOAS 不需要存储 URI，服务器在响应中发送 URI，可用于获取其他资源或相关资源。
但是有了 HATEOAS，我们不是在增加调用次数吗？
如果我想获取客户订单信息，如果我先获取客户信息并动态获取其订单的 URI，这不是额外调用吗？
松散耦合可以理解，但我不明白REST这个Maturity level的具体用途
为什么 HATEOAS 应该增加所需请求的数量？如果没有服务 returning URI，客户端可以用来执行状态转换（收集更多信息，调用一些任务，...），客户端必须对如何构建 URI 本身有一些了解（因此它是与服务紧密耦合），尽管客户端仍然需要调用服务器端的端点。所以 HATEOAS 只是将如何生成 URI 的知识从客户端转移到服务器。
通常发送到服务器的进一步请求并不是真正的问题，因为无论如何每个调用都应该是无状态的。如果您有一个负载平衡的服务器结构，那么额外的请求实际上不会对服务器产生明显的性能影响。
如果您确实关心客户端向服务器发出的请求数（无论出于何种原因），您可能会看看 HAL JSON 可以在其中嵌入子资源的内容，不过在客户订单的情况下，这也可能会对性能产生重大影响，因为如果用户可能存储了大量已发出的订单，响应可能会非常庞大，客户端必须管理所有数据，即使它可能不使用它。通常，服务不会在响应中嵌入大量列表项，而是将客户端指向一个 URI，客户端可以在其中了解如何在需要时检索这些信息。通常这种 URI 提供数据的可分页视图（如客户下的订单）。
虽然可分页请求肯定会增加服务处理的请求数量，但总体性能会提高，因为服务不必 return 将整个订单数据发送给客户端，因此减少了在支持数据库上加载并缩小实际响应内容长度。
总结一下我的 post，HATEOAS 旨在将创建 URI 的逻辑从客户端调用到服务器，从而进一步将客户端与服务分离。客户必须发出的实际请求数量与 HATEOAS 无关，但与整体 API 设计和客户要求有关。
我从来没有将 HATEOAS 与 RESTAPI 一起使用，据我所知，HATEOAS 不需要存储 URI，服务器在响应中发送 URI，可用于获取其他资源或相关资源。
但是有了 HATEOAS，我们不是在增加调用次数吗？ 如果我想获取客户订单信息，如果我先获取客户信息并动态获取其订单的 URI，这不是额外调用吗？
松散耦合可以理解，但我不明白REST这个Maturity level的具体用途
为什么 HATEOAS 应该增加所需请求的数量？如果没有服务 returning URI，客户端可以用来执行状态转换（收集更多信息，调用一些任务，...），客户端必须对如何构建 URI 本身有一些了解（因此它是与服务紧密耦合），尽管客户端仍然需要调用服务器端的端点。所以 HATEOAS 只是将如何生成 URI 的知识从客户端转移到服务器。
通常发送到服务器的进一步请求并不是真正的问题，因为无论如何每个调用都应该是无状态的。如果您有一个负载平衡的服务器结构，那么额外的请求实际上不会对服务器产生明显的性能影响。
如果您确实关心客户端向服务器发出的请求数（无论出于何种原因），您可能会看看 HAL JSON 可以在其中嵌入子资源的内容，不过在客户订单的情况下，这也可能会对性能产生重大影响，因为如果用户可能存储了大量已发出的订单，响应可能会非常庞大，客户端必须管理所有数据，即使它可能不使用它。通常，服务不会在响应中嵌入大量列表项，而是将客户端指向一个 URI，客户端可以在其中了解如何在需要时检索这些信息。通常这种 URI 提供数据的可分页视图（如客户下的订单）。
虽然可分页请求肯定会增加服务处理的请求数量，但总体性能会提高，因为服务不必 return 将整个订单数据发送给客户端，因此减少了在支持数据库上加载并缩小实际响应内容长度。
总结一下我的 post，HATEOAS 旨在将创建 URI 的逻辑从客户端调用到服务器，从而进一步将客户端与服务分离。客户必须发出的实际请求数量与 HATEOAS 无关，但与整体 API 设计和客户要求有关。