虽然有许多与此问题相关的主题，但我仍然找不到解决此问题的方法。
我有一个非常具体的GET API REST调用，例如：
/ v1 / books？id = 40,41,42,43,44,45,46,47 ...
但是，有时由于id列表很长，所以我收到414 Request-URI太长的错误。
我已经阅读了与该问题有关的每个主题，当有许多参数时，我们必须使用POST而不是GET（而不是尝试更改apache中的最大限制，我同意这不是一个好的解决方案）
但是我试图获取书籍，而不是创建书籍！ REST API非常明确，POST是用于创建新条目的。而且由于我使用的是Slim Framework，因此如果我调用POST来获取图书，那么将会期望使用不同的参数来创建新图书。 Slim无法指定两个不同的POST / v1 / books，因为无论您发送的参数如何，Slim都将始终使用找到的第一个POST / v1 / books（我将在获取或创建书本时，永远不会同时使用两者）
因此，我的问题是否有解决方案？我有点惊讶，还没有REST解决方案...看起来好辛苦，找不到任何东西...
提前感谢！
PS：我正在使用cURL / PHP使用此GET API，其中没有JS / AJAX。
但是我试图获取书籍，而不是创建书籍！ REST API非常特定，POST用于创建新条目。
不，POST适用于各种情况。参见Roy T Fielding的It is Okay to Use POST。
[当信息与潜在资源相对应时，使用POST进行信息检索并不是RESTful，因为这种用法会阻止安全重用性以及拥有URI的网络效应。
414 URI Too Long指示请求的起始行中的目标uri已超出服务器的任意长度限制。由于服务器是其自身资源的授权者，因此它可以自行做出这种决定。
习惯上正确的答案是创建新资源；也就是说，您将信息发布到服务器，服务器将创建一个新资源和一个匹配的标识符。例如，服务器可以将帖子的内容保存为随机文件名，然后使用编码该文件名的标识符将所需信息发送回给您，以便以后可以获取任何更新。
POST /v1/books
id=40,41,42,43,44,45,46,47...
201 Created
Location: /v1/book-lists/9d133345-ded1-47ab-a954-a81c1d6d487f
Content-Location: /v1/book-lists/9d133345-ded1-47ab-a954-a81c1d6d487f
-- current representation of /v1/book-lists/9d133345-ded1-47ab-a954-a81c1d6d487f here --
随后查看表示是否已更改的请求可以发送到书单URI。
当然不是免费的。有人必须决定在他们的域应用程序协议中希望这样做，设计资源，实现查询有效负载的服务器端缓存等等。
[另外，请注意，这实际上并不能解决问题，因为不应期望服务器支持任意长（也就是无限长）的请求。实际上，它仅在服务器认为对目标uri来说太长的长度与服务器认为对有效载荷（413 Payload to Large）来说太长的长度之间提供了喘息的空间。
因此，如果您正在设计API，则需要考虑要支持的用例，这些用例的极端数据长度，并在满足其他约束的情况下选择满足它们的域应用程序协议。