Rest API 与 GraphQL - 幂等 [英] Rest API vs GraphQL - Idempotent
问题描述
来自另一个用户的这个问题/答案对于幂等的含义非常有用:
This question/answer from another user was very informative as to what idempotent means:
当涉及到 Rest API 时，如果用户想要获取一些 examples:/users/:id 或 /posts/:id，他们可以根据需要执行多次，并且不应该改变任何数据.
When it comes to Rest API, since caching for GET requests can quickly be enabled if not already, if a user is wanting to fetch some examples: /users/:id or /posts/:id, they can do so as many times as they'd like and it shouldn't mutate any data.
如果我理解正确，在这种情况下 GET 请求是幂等的.
If I'm understanding correctly, a GET request is idempotent in this case.
问题
我相信 Relay 和 Dataloader 可以在缓存方面帮助 GraphQL 查询，但不能解决浏览器/移动缓存问题.
I believe Relay and Dataloader can help with GraphQL queries as far as caching, but doesn't address browser/mobile caching.
- 如果我们只讨论 GraphQL 的 GET 请求部分，它是单个端点的一部分，我可以使用什么技术/功能或其他方式来解决常规 http 请求提供的缓存方面的好处. 莉>
推荐答案
幂等性 vs 缓存
首先，缓存和幂等是不同的东西，不一定相互关联.缓存可能会也可能不会用于实现幂等操作 - 这当然不是必需的.
Idempotence vs Caching
First of all, caching and idempotence are different things and do not necessarily relate to one another. Caching may or may not be used to implement idempotent operations - it is certainly not a requirement.
其次，当谈到 HTTP 请求时，幂等本质上关注的是服务器的状态而不是它的响应.如果执行多次，幂等操作将使服务器处于完全相同的状态.这并不意味着幂等操作返回的响应将是相同的(尽管它们通常可能是相同的).
Secondly, when speaking of HTTP requests, idempotence essentially concerns the state of the server rather than its responses. An idempotent operation will have leave the server in the exact same state if performed multiple times. It does not mean that the responses returned by an idempotent operation will be the same (although they often might be).
REST 中的 GET 请求预期是合约幂等的 - 即 GET 操作不能对服务器产生任何状态改变的副作用(从技术上讲，这可能并不总是正确的，但对于为了解释，我们假设它是).这并不不是意味着如果您多次获取相同的资源，您将始终获得相同的数据.实际上，这是没有意义的，因为资源会随着时间的推移而变化，也可能会被删除，对吗?因此缓存 GET 响应有助于提高性能，但与幂等性无关.
GET requests in REST are expected to be idempotent by contract - i.e. a GET operation must not have any state-altering side-effects on the server (technically this may not always be true, but for the sake of the explanation let's assume it is). This does not mean that if you GET the same resource multiple times, you'll always get the same data back. Actually, that wouldn't make sense since resources change over time and may be deleted as well right? So caching GET responses can help with performance but has nothing to do with idempotence.
另一种看待它的方式是查询资源而不是任意数据.GET 请求是幂等的，因为您将始终获得相同的资源，并且您不会以任何方式修改系统的状态.
Another way to look at it is that you are querying for a resource rather than arbitrary data. A GET request is idempotent in that you'll always get the same resource and you won't modify the state of the system in any way.
最后，在服务器端一个糟糕的(奇怪的?)开发的 GET 操作可能会产生副作用，这会违反 REST 契约并使操作非幂等.在这种情况下，简单的响应缓存无济于事.
Finally, a poorly (oddly?) developed GET operation on the server side might have side-effects, which would violate the REST contract and make the operation non idempotent. Simple response caching would not help in such a case.
我喜欢将 GraphQL 查询 视为等同于 REST 中的 GET.这意味着如果您在 GraphQL 中查询数据，解析器必须不执行任何副作用.这将确保多次执行相同的查询将使服务器保持不变的状态.
I like to see GraphQL queries as equivalent to GETs in REST. This means that if you query for data in GraphQL, the resolvers must not perform any side-effects. This would ensure that performing the same query multiple times will leave the server in an unchanged state.
就像在简单的 GET 中查询特定的资源一样，尽管与 GET 不同，GraphQL 允许您一次查询多种不同类型资源的多个实例.再说一次，这并不意味着相同的响应，首先是因为资源可能会随着时间的推移而发生变化.
Just like in a simple GET you'd be querying for specific resources, although unlike in GET, GraphQL allows you to query for many instances of many different types of resources at once. Once again, that does not mean identical responses, first and foremost because the resources may change over time.
如果你的一些查询有副作用(即它们改变了服务器上资源的状态)，它们就不是幂等的！您可能应该使用突变而不是查询来实现这些副作用.使用变异会让客户/消费者清楚该操作不是幂等的，应该进行相应的处理(变异输入可以接受幂等键以确保类似 Stripe 的幂等性，但这是一个单独的主题).
If some of your queries have side-effects (i.e. they alter the state of the resources on the server), they are not idempotent! You should probably use mutations instead of queries to achieve these side-effects. Using mutations would make it clear to the client/consumer that the operation is not idempotent and should be treated accordingly (mutation inputs may accept idempotence keys to ensure Stripe-like idempotency, but that's a separate topic).
我希望现在很清楚缓存不需要确保/不是决定 GraphQL 查询幂等性的因素.它仅用于提高性能.
I hope that by now it's clear that caching is not required to ensure / is not what determines the idempotency of GraphQL queries. It's only used to improve performance.
如果您仍然对 GraphQL 的服务器端缓存选项感兴趣，这里有很多资源.您可以先阅读 Apollo Server 文档 必须说的内容话题.不要忘记您还可以缓存数据库/服务/等.回应.我不打算提供任何具体建议，因为从您的问题来看，其他地方有更多的混乱.
If you are still interested in server-side caching options for GraphQL, there are plenty of resources. You could start by reading what Apollo Server documentation has to say on the topic. Don't forget that you can also cache database/service/etc. responses. I am not going provide any specific suggestions since, judging by your question, there's much grater confusion elsewhere.
这篇关于Rest API 与 GraphQL - 幂等的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
