毫无疑问，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 为可能的唯一用途创建/转换数据时，这似乎很不方便。当你有十几个参数接受不同的值时，这似乎很痛苦。
然而，在我看来，肥皂和XML-RPC标准是相当丑陋的......
那么，当看起来更明智时，将 RESTlike 或 AsRESTas相关设计与 json 参数/响应相关联是不是不好？
在我的情况下，有什么标准建议吗？
干杯
文森特
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.