尽管有很多与此问题相关的主题，但我仍然找不到解决该问题的方法。
我有一个非常具体的GET API REST调用，例如：
/ v1 / books？id = 40,41,42,43,44,45,46,47 ...
但是，有时由于id列表很长而收到414 Request-URI太长的错误。
我已经阅读了与该问题相关的每个主题，当有许多参数时（我们不能尝试更改apache中的最大限制，我同意这不是一个好的解决方案），我们必须使用POST而不是GET < / p>
但是我正在尝试获取书籍，而不是创建书籍！ REST API非常明确，POST是用于创建新条目的。 并且由于我使用的是Slim Framework，因此如果我调用POST来获取图书，那么将会期望使用不同的参数来创建一本新图书。 Slim无法指定两个不同的POST / v1 / books，因为无论您发送的参数如何，Slim都将始终使用找到的第一个POST / v1 / books（我将在获取或创建书本时，永远不会同时使用两者） ）
那么，我的问题是否有解决方案？ 我有点惊讶，还没有REST解决方案... 看起来好辛苦，找不到任何东西...
谢谢！
PS：我正在使用cURL / PHP使用此GET API，那里没有JS / AJAX。
答案 0 :(得分：1)
但是我正在尝试获取书籍，而不是创建书籍！ REST API非常明确，POST是用于创建新条目的。
否，POST适用于各种情况。请参见Roy T Fielding的It is Okay to Use POST。
当信息对应于潜在资源时，使用POST进行信息检索并不是REST的，因为这种用法会阻止安全的可重用性以及拥有URI的网络效应。
414 URI Too Long表示请求的起始行中的target-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，则需要考虑要支持的用例，这些用例的极端数据长度，并选择一个满足它们的域应用程序协议（取决于您的其他应用程序）约束。