GraphQL查询操作对URL长度的限制

我已经开始在一个新项目中使用GraphQL，并且关心发送查询时生成的URL的长度。我的意思是，在发出GraphQL查询时，我们最终不会达到url长度的限制吗。有解决方法吗？

GraphQL请求通常以POST请求的形式发送，请求的内容类型为application/json。请求的主体是一个JSON对象，它由三个属性组成—query、variables和operationName。在这里，查询是从客户机发送到服务器的整个GraphQL，而不管实际的操作类型如何。因此，您的请求可能类似于：

如上所述，GraphQL服务器实现通常还支持GET请求，以及包含application/GraphQL类型的POST请求。其他两种方法的灵活性都不如前者，但：

GET请求不仅可能面临URL长度限制问题，而且还可能面临一些最严重的问题？服务器实现将这些请求限制为仅查询操作——换句话说，通常是查询操作。 使用application/graphql内容类型的POST请求将整个请求正文视为文档，这意味着它们不提供发送变量的方法，也不指定应该在文档中运行哪个操作。

---

您可能应该将POST请求与application/json内容类型一起使用，除非您有一些独特的客户端限制阻止您这样做。

是的，在某些情况下肯定会发生这种情况，这里有一个相关的问题：在POST中发送GET请求根本不会导致其他问题。例如，自动重新发送GET请求。肯定有更好的解决办法吗？我不知道你在帖子中发送GET请求是什么意思。您可以将其作为GET请求或POST发送。答案的要点是，您应该避免在GraphQL中使用GET请求，而坚持使用POST。抱歉，如果这还不够清楚的话。是的，我知道你应该在POST中发送graphql查询，但我基本上想得到的是，这是一个get请求，请求数据和POST通常用于更新，这不会导致其他问题。否。GraphQL使得使用不同的请求方法（如修补、删除、获取等）变得不必要。所有请求都是POST请求。您可以通过在请求体中传递的文档来区分获取和变异数据，具体来说是操作类型查询和变异。实际上，我指的是周围的库，而不是graphql本身。例如，如果第一个请求失败，一些http库往往会多次触发GET请求，而不一定是POST请求，因为它可能会修改数据两次。