【发布时间】：2011-09-25 19:23:41
【问题描述】：
在我的 RESTful API 中说我有一张用户可以通过 PUT 请求更新的图片。
假设这些图片中的每一个都有一个用户可以为其指定的自定义名称，以便他们可以轻松浏览它们。
我想做的是发送一个包含更新的文件和图片的新名称的放置请求，但我不确定如何让 PHP 在从 php 读取时将更新的文件与新名称分开//输入
有人知道怎么做吗？
【问题讨论】：
【发布时间】：2011-09-25 19:23:41
【问题描述】：
将标量参数（即旧名称、新名称）放入查询字符串中。
【讨论】：
-
我正在考虑这样做，但是如果您的图像可以说... 20 个选项也发生了变化（例如，地点、所用时间等...），该怎么办？查询字符串不会变得很长吗？使用查询字符串是标准吗？
-
如果您坚持以 PUT 形式发送文件（而不是使用 multipart/form-data 的 POST），那么您可以使用的东西不多。您可以使用带有
X-前缀的自定义标头，但这会扩展协议。 -
这是非常糟糕的做法 - URI 是请求的目标。当您围绕 URI 部分的特殊含义定义带外知识时，您会引入一种非常糟糕的耦合。
-
最后我想我会走的路线：发布/放置一个json文档到服务器，当他们需要更新图像和名称时，做一些类似 PUT /images /update?name=name 就像 Bit.ly 一样：code.google.com/p/bitly-api/wiki/ApiDocumentation
看看 AtomPub (https://www.rfc-editor.org/rfc/rfc5023)，尤其是编辑媒体链接。它并不能完全满足您的需求，但也许您可以调整它。
将多部分文档放入原子条目在语义上应该没问题，其中多部分的第一部分是原子条目 XML 以更新标题。该条目的内容元素可以使用 cid: URI (https://www.rfc-editor.org/rfc/rfc2392) 指向第二个多部分（图像数据）
Slug 标头（也在 RFC 5023 中）也可能是调查的开始。
您可能会搜索 Content-Disposition: 和 Title: 周围的一些较旧的标题。
另一种选择是提出一个具有适当语义的新资源，然后 POST 或 PATCH 一个多部分或结构化文档。
一月
【讨论】：
为什么不使用 url 作为文件名？
PUT /images/new_image.jpg
【讨论】：
如果您想在同一个请求正文中包含多种内容类型，正确的格式是使用 multipart mime 将它们全部包装到同一个请求正文中。不过，在这种情况下，支持像 multipart mime 这样复杂的东西可能有点难以证明。
【讨论】：
-
这将违反PUT的含义，即使用请求正文更新资源。
-
@Jan：代码就是代码的作用。除了实现逻辑没有任何意义。
-
我们一定在谈论不同的事情。我说的是 HTTP 的语义以及如果你在服务器上错误地实现它们的语义会发生什么。例如。获取 /account/?action=delete。还记得谷歌加速器吗？ 37signals.com/svn/archives2/… HTTP 是一个应用层接口 - 把它当作一个。
-
@JanAlgermissen：我同意 - 但问题是关于如何以可通过 php://input 读取的方式表示数据 - 事实上，您不应该在正文中表示此类数据当您使用 PUT 时，图像资源的分配是完全不同的事情。 php://input 包含请求正文，multipart mime 是在同一请求正文中混合图像资源和非图像资源的最正确方法。
-
嗯 - 那么我建议发送一个与 Atom 条目相关的 multipart/related 作为根部分，它的内容元素引用（通过 cid: ）第二部分。 （在我的回答中描述）。这对于 AtomPubs 对编辑-媒体链接关系的定义应该不会太远。
经过考虑，我认为您需要的是带有multipart/form-data 的 POST 请求。这允许文件和一些标量数据项，而不会对文件数据产生 Base64 或 URLEncode 的开销。
【讨论】：
使用 SLUG 标头来执行此操作：
换句话说，Slug 标头为客户端提供了一种为新创建的资源建议 URI 的方法。
URI 只能使用有限的字符集，如果 Slug 使用合法 URI 字符集之外的字符，则服务器必须转义这些字符。
两个或多个客户端可能同时尝试使用相同的 Slug 创建资源，服务器必须给每个资源一个唯一的 URI，因此服务器可能会选择用额外的字符装饰 slug 以确保每个资源都是唯一的命名。
参考文献
【讨论】：