将目标RESTful设计用于公共Web服务/ API是否总是与之相关？ [关闭]

Question

毫无疑问，RESTful是流行语，在许多情况下，它似乎是一个砍刀设计模式。

努力将其应用到我自己的Web API（现有的和即将发布的）上，我终于想知道它是否与我的工作有关（如果我们忘记了它存在于某些RFC中的事实，我们会尝试做出响应；）。

首先，我主要处理的是至少确定3个参数（最多可能是10个）的动态数据。

例如，考虑执行声音效果和格式转换（均衡，回声，音量，速度等）的Web API。 您需要向其发送凭据，一组未确定的效果名称和设置以及要均衡的声音。

网址可能类似于effectMaker / echo / 10pct / equalizer / 20kHz / -10pct / output-rate / 192kbps /

• http标头中的一些参数（例如响应格式）

• 体内的声音。

因此，函数是通过http方法+ url根定义的，参数位于正文，url尾部和标头中。 似乎对我和开发人员来说，发现我的API都不太方便。

除此之外，由于我的大多数用户请求都是唯一的，因此缓存功能没有任何意义。

因此，我要问您是否错误，认为我应该尝试将REST中的“感觉”（无状态，可发现...）中的感觉整合起来，以供使用，但请删除其中的一部分没有意义（可缓存）还是使API变得奇怪？ 例如，当您在正文中推送一些数据并期望获得转换后的数据作为响应时，我真的应该坚持使用HTTP动词吗？

对我来说，当您管理/使用可通过相当简单的路径访问的在线数据库项目时，RESTFull设计似乎很有意义。 当您的API为可能的唯一用法创建/转换数据时，似乎很不方便。 当您有十二个接受各种值的参数时，这似乎很痛苦。

但是，我认为soap和XML-RPC标准很难看。

因此，在看起来更明智的情况下，使RESTlike或AsRESTasRelevant设计与json参数/响应相关联是否不好？

在我的情况下有什么标准建议可以遵循吗？

干杯，

文森特

Answer 1

REST不是一种哲学。 这是一种建筑风格-一种设计系统以满足特定目标的方式 。 如果这些目标不是您的目标，那么REST是一个坏主意。 如果是这样，那么REST是一个好主意。 我们不知道您的目标是什么，因此我们不知道REST是否适合您。

接下来的部分实际上与REST无关，它是更通用的Web API设计，

不要使用URL包含处理指令。 就像您说的那样，对于非平凡的系统来说这完全是不方便的。 支持多部分请求，其中一部分包含处理指令，另一部分包含音频文件，或者将文件上载和处理指令视为两个单独的请求。 您甚至都可以支持。

只是吐口水，如果我试图将其设计为RESTish API，我可能会开始

POST /audio-files

request:
Content-type: audio/midi
<audio file>

response:
201 Created
Location: http://example.com/audio-files/12

-

POST /audio-files

request:
Content-type: multipart/mixed; boundary="simple boundary"
--simple boundary
Content-type: application/json; charset=us-ascii
{
   "echo": "true",
   ...
}
--simple boundary
Content-type: audio/midi; charset=us-ascii
<audio file>
--simple boundary--

response:
200 Ok
Link: <http://example.com/audio-files/12>; rel="audio-file"
<altered-audio-file>

-

POST /altered-audio-files

request:
Content-type: application/json; charset=us-ascii
{
    "audio-file": "http://example.com/audio-files/12"
    "echo": "true",
    ...
}

response:
200 Ok
<altered-audio-file>

这会将音频文件和更改后的音频文件视为资源。 这样，当有人要在同一文件上运行八次转换时，您可以通过保留上载的音频文件来节省在线时间，并且如果您以后选择这样做，则可以选择保留更改后的音频文件。 如果要跟踪请求，则可以通过添加第三个端点（可能是/audio-requests轻松地做到这一点。