RESTful编程指南

是GRPC真的快于REST？让我们同时开发基于gRPC和REST的微服务，并进行gRPC与REST  性能比较。我们这里的主要目标是提出一个应用程序–具有2种不同的实现（REST和gRPC），以实现完全相同的功能。正如我们已经讨论过的那样，gRPC非常适合涉及更多聊天性的微服务之间的

您知道HTTP请求可以接收多个响应状态代码吗？服务器可以在最终状态（200、404或任何可能的状态）之前发送不限数量的1XX码。这些充当临时响应，并且都可以包含自己的独立标头。有几种不同的1XX代码可用：100、101、102和103。它们并未得到广泛使用，但是在某些利基用例中，它们

并发控制可能是REST API的重要组成部分，尤其是当您期望对同一资源的并发更新请求时。在本文中，我们将介绍If-Unmodified-Since和If-Match标头不同的选项，从而避免通过HTTP丢失更新。让我们从一个示例请求流开始，以了解问题：

类似Postman的用于测试API轻量级Rest Client：thunderclient 轻量级API客户端 简单，干净且易于使用的用户

我认为GraphQL将改变世界。将来，您可以使用GraphQL查询世界上的任何系统。我正在建立这个未来。那么，为什么我反对使用GraphQL？我个人的烦恼是，当前社区采取GraphQL的理由实际上与GraphQL无关。如果我们想推动采用，我们应该诚实并脱掉玫瑰色的眼镜。这篇文章是对K

幂等性是一个积极的 API 特性。它有助于使 API 更具容错性，因为客户端可以在出现连接问题时安全地重试请求。HTTP 规范将 GET、HEAD、OPTIONS、TRACE、PUT 和 DELETE 方法定义为幂等的。这些方法中的 GET、PUT 和 DELETE 是 REST A

在本教程中，向您展示NATS消息传递与基于REST的微服务的性能。NATS是高性能云本机消息传递服务器。NATS可以帮助现代分布式系统体系结构中的服务发现，负载平衡，微服务间通信等。我们这里的主要目标是提出一个应用程序-具有2种不同的实现方式（REST和NATS）以实现完全相

批量（或批处理）操作用于在单个请求中对多个资源执行操作。这可以帮助减少网络开销。为了提高网络性能，通常最好发出更少的请求，而不是发出更少的数据的更多请求。但是，在添加对批量操作的支持之前，如果确实需要此功能，则应三思而后行。通常，网络性能并不是限制请求吞吐量的因素。您还应该考虑使用<

在开始之前，让我们快速检查一下为什么部分更新有用的原因： 简单性-如果客户端只想更新一个字段，则部分更新请求可能更易于实现。 带宽-如果您的资源表示量很大，则部分更新可以减少所需的带宽量。 更新丢失-使用PUT替换资源可能会导致更新丢失问题。尽管部分更新不能解

Java中的Json Patch和

如果要进行复杂的数据检索，发送大量数据但不更改服务器状态怎么办？现在，您有两个主要选择： 使用GET，然后将所需的所有参数压缩到URL或标头中 使用POST，并将请求视为不安全且不可缓存 这些都不是一个好的选择。

Spring是用于开发企业级应用程序的流行框架。经过多年的发展，SpringBoot登上了舞台。Spring是使用@RestController编写RESTful Web服务。编写RESTful Web服务的方法有很多，Jersey是JAX-RS的开源框架实现，它是RESTful W

Spring Data REST 是Spring Data 项目的一部分，可以轻松地在 Spring Data 存储库之上构建超媒体驱动的 REST Web 服务。依赖项：Spring Boot DevTools、Spring Data JPA、Spring Data Rest、My

REST，GraphQL和gRPC是客户端-服务器和服务器到服务器通信的3种流行形式。选择可能很困难，因此本简要指南可以提供帮助。在每个部分中，将提供一个示例来说明检索用户。 REST 描述数据的HTTP路径，例如/ user

来自alexkrupp的这篇文章虽然是基于Django/Python编写，但是实践原则是通用的。大多数现有的软件架构建议都是为 100 亿美元以上的公司编写的，因此往往侧重于最大化性能、可扩展性、可用性、可靠性等。这实际上造成了一个巨大的问题。问题是，由于在大学学习计算机科学

REST 模式的最大失败是无法批量跟踪“链接”。它总是会导致 N+1 问题，从而无法大规模扩充 API。OpenAPI 在这方面失败了。GraphQL+dataloader 是一个有效的复杂解决方案。 众说纷纭：在 REST 中实现超媒体格式总是很困难。执行合同也很困