问HTTP的最佳实践是什么?只获取我需要的对象列表

EN

我对在GET请求中使用JSON有效负载表示怀疑。

您的怀疑是有道理的；以下是HTTP规范对到达的看法

GET请求消息中的有效负载没有定义的语义。

试图利用未定义的行为是个坏主意。

请建议在其他世界进行更好的练习。

重要的是要认识到URI是标识符；我们有时使用人类可读标识符(又称可hackable URI)这一事实是一种方便，而不是一种要求。

因此，URI可以很容易地成为系统is列表的散列摘要(很可能是唯一的)，而不是系统is的列表。

所以你的客户要求也许是

GET /ea3279f1d71ee1e99249c555f3f8a8a8f50cd2b724bb7c1d04733d43d734755b

当然，散列是不可逆的--如果还没有就URI的含义达成一致，那么我们就陷入困境了。因此，在协议的某个地方，我们需要向包含列表的服务器发出请求，以便服务器可以存储它。“商店”是一个很大的暗示，我们将需要一个不安全的方法。我希望在这里看到的两位候选人是帖子或放。

思考正在发生的事情的一种方法是，您有一个具有两种不同表示的资源--“查询”表示和“响应”表示。使用PUT和POST，您将查询表示交付给服务器，使用GET检索响应表示(对于模拟，考虑HTML表单-我们向服务器发布应用程序/www-表单-urlencoded表示，但我们得到的表示通常更友好)。

允许客户机自己计算URI并向其发送消息有点RPC-ish。您通常在REST API中所做的是记录具有已知起始位置的协议(也称为书签)和一系列要遵循的链接。

(注意:很多东西都被贴上了"REST“的标签，但事实并非如此。如果它不像一个人用浏览器浏览网站，那么它可能不是"REST”。这很好，不是每件事都必须如此。)

但我认为POST或PUT是一些修改数据的请求。对它们使用查询请求是个好主意吗？

不，这不是..。但它们是创造新资源的完美选择。然后，您可以进行安全的GET调用，以获得资源的当前表示。

REST (当然还有HTTP)是针对web的常见情况进行优化的:大型谷物超媒体、缓存等等。各种用例都会因此而受到影响，其中之一是具有安全语义和有效负载的瞬态消息。

TL;DR:如果您没有HTTP设计的一个用例，那么使用POST --并接受这样一个事实:您并没有真正利用HTTP的全部功能。或者使用不同的应用程序--如果不合适，就不必使用HTTP。