直到现在，我以前一直认为GET和POST之间的唯一区别是数据传输的格式。在其他示例中，我看到在REST Api中，发送信息的唯一命令是POST，而获取信息的命令是GET ...
但是如果我也想使用GET来发送信息怎么办？我必须发送许多要处理的数据集名称（通常是一个短数字...）...我不明白为什么GET不适合此操作。还是仅仅是“语义”上的原因？
编辑：我不希望回答GET或POST之间的一般区别...我需要知道GET是否不应该在所有情况下用于更新服务器的信息，特别是关于我的具体情况，或者有一些例外。
我不明白为什么GET不适合该操作。还是仅仅是“语义”上的原因？
是，但是语义才是重点。
REST architectural style的重要约束之一是uniform interface的约束；所有组件以相同方式理解消息的想法。使用通用组件可以使我们完成有用的工作。
在HTTP（在这种样式的约束内构建的应用程序）中，这意味着我们可以使用浏览器，缓存，反向代理和服务器工具包等，在进行时进行混合和匹配。这一切都奏效，因为所有这些组件都了解应按RFC 7230中所述解释请求，并且request method token是“请求语义的主要来源”，依此类推。
GET的语义已定义，我们都共享该定义。该定义的措词从最早的规范开始已有所发展，但是基本语义一直是不变的：GET实际上是只读的，并且消息正文没有语义上的意义。
如果您要使用HTTP方法，其中消息主体在语义上很重要，那么您需要放宽GET的某些约束（例如，使用POST），请选择一种更适合您的用例的标准化方法（请参阅IANA HTTP Method Registry），或通过定义（可能还有standardizing）您自己的HTTP方法。
[尝试为GET定义有效负载的核心问题-尽管您的定制客户端可能知道该怎么做，而您的定制资源可能知道该怎么做，但通用中间体很可能会做错误（例如在不捕获请求正文中的信息的情况下缓存响应，或者将其不必要地丢弃）。
请注意，将编码为target-uri]的信息正常工作；可以使用使用GET方法和URI模板的其他变体的HTML表单从服务器可以解释的本地信息中构造目标uri（当然，目标uri长度的实际限制比有效负载的实际限制要短得多）大小；这不是通用解决方案）。