Question

我是否通过返回application / octet-stream作为我的回复来破坏REST圣经中的任何法律？ REST端点接收5个图像URL。

{ "image1": "http://ww.o.com/1.gif",
  "image2": "http://www.foo.be/2.gif" }

它将下载这些并将它们作为application / octet-stream返回。

CLARIFICATION ：调用此REST接口的客户端是一个移动应用程序。每增加一个网络连接，电池寿命就会减少几毫安。我被迫使用REST，因为它是公司标准。如果没有，我将自己做二进制协议。

Answer 1

它不太好，因为客户端不知道如何处理这些二进制数据，除了将这些字节存储在某处或将它们进一步发送到其他进程（如果这是您需要处理的数据，那么很好）。

您可以查看multipart内容类型。 IMO，包含多个image/gif部分的多部分消息将是更好的选择。

Answer 2

从这听起来，这听起来更像是一个RPC调用。具体来说，“这是一个URL列表，给我发回档案”。

该进程并不特别REST，因为REST不是基于RPC的系统。

您需要做的是将档案视为资源，以及创建和提供档案的方式。

例如你可以：

POST /archives
Content-Type: application/json

{ "image1": "http://ww.o.com/1.gif",
  "image2": "http://www.foo.be/2.gif" }

结果，你会得到

HTTP/1.1 201 Created
Location: http://example.com/archives/1234
Content-Type: application/json

然后，您可以向http://example.com提出请求：

GET /archives/1234
Accept: multipart/mixed

在这里，您将在单个请求中获得实际存档（如您所愿），只有它是多部分格式化结果。（multipart / x-zip也可以，这是一个zip文件）

如果你这样做了：

GET /archives/1234
Accept: application/json

您将获得最初发送的JSON（因此您可以编辑和更新存档，您可能不希望支持发送二进制图像）。

要更改它，您只需回发更新：

PUT /archives/1234
Content-Type: application/json

{ "image1": "http://ww.o.com/1.gif",
  "image2": "http://www.foo.be/2.gif",
  "image3": "http://www.foo2.foo/4.gif" }

资源是/ archives / 1234，这就是它的名字。

在这种情况下，它有两个表示形式：JSON版本和实际的二进制存档。您的服务使用Accept标头中指定的内容类型区分两者。那个标题是客户告诉你它想要什么。

完成存档后，只需删除

即可

DELETE /archives/1234

或者您可以让服务器稍后过期。

Answer 3

为什么不进行五次单独的REST调用？

似乎更清洁，更逻辑地划分。它还将并行运行下载，一次2个或更多，具体取决于您使用的浏览器。

Answer 4

他们被称为REST原则，而不是法律，但不，你不是“打破”他们，IMO。 REST是关于可通过URL寻址的资源，并且（在适当的情况下）可以多种格式提供。它没有说明格式应该是什么。简单描述了REST的含义in this article。

然而，正如@Andrey所说，有更好的方法来处理发送多个数据对象，而不是发明自己的adhoc格式。 Multipart mimeType / format是另一种选择，另一种是将打包的对象作为tar，zip或类似的归档文件格式发送。

IMO。使用“application / octet-stream”的真正问题在于它没有告诉任何人有关数据实际格式化的信息。而是您的客户“知道”它的格式，并相应地解释它。发明自己的格式的问题是互操作性，并且（可能）必须设计，实现和维护库以支持它，可能需要一段时间。

可以从REST接口返回application / octet-stream吗？

4 个答案: