我处在一种情况下，我想通过使用我对那些对象了解的参数之一对它们进行寻址，从而仅获取所需的对象。
例如，我想获取系统中ID为111、222、333的所有用户。
并且列表可能更大，所以我认为不是将URL附加所需内容的最佳方法，而是将有效负载与json一起使用。
但是我对在GET请求中使用JSON有效负载表示怀疑。
请在REST世界中提出更好的做法。
答案 0 :(得分：2)
我对在GET请求中使用JSON有效负载表示怀疑。
您的怀疑是有根据的；这是HTTP规范对GET
的评价GET请求消息中的有效负载没有定义的语义
试图利用未定义的行为是一个坏主意。
请在REST世界中提出更好的做法。
要认识的重要一点是URI是标识符；我们有时使用人类可读的标识符（也称为hackable URI）是一种方便，而不是必需。
因此，除了系统ID列表之外，URI也可以轻松地作为系统ID列表的哈希摘要（可能将是唯一的）。
所以您的客户要求可能是
GET /ea3279f1d71ee1e99249c555f3f8a8a8f50cd2b724bb7c1d04733d43d734755b
当然，哈希是不可逆的-如果尚未就URI的含义达成一致，那么我们就陷入了困境。因此，在协议中的某处，我们将需要向包含列表的服务器发出请求，以便服务器可以存储它。 “存储”是一个很大的暗示，表明我们将需要一种不安全的方法。我希望在这里看到的两个候选人是POST或PUT。
一种思考方式是，您拥有一个具有两种不同表示形式的资源-“查询”表示形式和“响应”表示形式。使用PUT和POST，您可以将查询表示形式传递到服务器，使用GET可以获取响应表示形式（对于模拟形式，请考虑HTML表单-我们将application / x-www-form-urlencoded表示形式发布到服务器，但是我们获取的表示形式通常更友好）。
允许客户端自行计算URI并向其发送消息有点像RPC。您通常在REST API中所做的工作是记录具有已知起始位置（又称书签）和要遵循的链接序列的协议。
（注意：很多东西都标有“ REST API”，但实际上不是。如果感觉像不是人类使用浏览器浏览网站，则可能不是“ REST”。）是 fine ；不是所有的都必须。）
但是我相信POST或PUT是针对某些修改数据的请求。与它们一起使用查询请求是一个好主意吗？
不是，不是...但是它们非常适合创建新资源。然后，您可以进行安全的GET调用以获取资源的当前表示形式。
REST（当然还有HTTP）针对Web的常见情况进行了优化：大颗粒超媒体，缓存以及所有这些好东西。为此，会遇到各种用例，其中一种是具有安全语义和有效负载的临时消息。
TL; DR：如果您没有HTTP设计的用例之一，请使用POST-并确定您没有真正利用HTTP的全部功能。或使用其他应用程序-如果不合适，您没有使用HTTP。