Rest API与GraphQL-幂等 [英] Rest API vs GraphQL - Idempotent
问题描述
另一个用户的这个问题/答案对幂等的含义很有帮助:
This question/answer from another user was very informative as to what idempotent means:
关于 Rest API ，由于可以快速启用GET请求的缓存(如果尚未启用)，因此如果用户希望获取一些示例:/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请求在缓存方面提供的好处.
推荐答案
幂等与缓存
首先，缓存和幂等是不同的东西，不一定彼此相关.缓存可以或不可以用于实现幂等运算-这当然不是必需条件.
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).
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请求是幂等的，因为您将始终获得相同的 resource ，并且不会以任何方式修改系统状态.
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服务器文档话题.不要忘记，您也可以缓存数据库/服务/等.回应.我不会提供任何具体建议，因为从您的问题来看，其他地方存在很多混乱.
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屋！
