我正在寻找与REST-ify行为/概念的最佳方法相关的建议和经验，这些行为/概念并非“通常持久” - 换句话说，资源转化为变形或副作用行为。
首先，让我说我知道没有完整的REST测试测试 - 实际上我并不关心。我发现REST的CRUD-over-the-Web概念非常直观，它可以很好地处理我提供访问的大多数数据。与此同时，我并不担心从任何人的圣经中妄为如何完美地发挥作用。我正在寻找实用和REST直观之间的最佳折衷方案，以适应那些不适合的情况。显然，一致性是主要目标，但直观性有助于确保这一点。
鉴于此，让我深入了解我所追求的细节。
由于REST本质上是面向资源的，因此很容易对通常持久存在的事物进行建模 - 不太清楚的是如何对通常不存在的行为/概念进行建模，特别是那些具有副作用或纯粹是转换的行为/概念。
例如，请访问stackoverflow.com问题。它可以是创建，更新，读取和删除。每个人都可以与之相关，而这一切在REST下都是有意义的。
但现在考虑像翻译一样 - 例如，我想为我的服务构建一个REST API，将英语句子翻译成西班牙语。
至少有两种方法可以解决翻译方案。我可以：
将翻译调用视为“翻译实例”的创建（它不会被持久化，但可能会被保留），在这种情况下，POST /翻译（即创建）实际上是很有意义。如果翻译服务需要要翻译的内容的URL（因为该URL的内容可能随时间变化），情况尤其如此。
将翻译视为查询已知答案的较大字典的行为，在这种情况下，GET /翻译（即读取）可能更合适。如果翻译服务仅需要翻译句子的文本，这尤其诱人。没有人会期望静态句子的翻译随着时间的推移而改变。你也可以争辩说它可以缓存，GET可以将其用于。
同样的困境可能会出现主要有副作用的其他行为（例如，发送短信或电子邮件），而且与数据的持久性相关性较低。
到目前为止，我的方法基本上是“订购” - 通知这些案件，就是在查看所有事情，就像在下订单一样。更一般地说，我认为这只是将动词（翻译）转换为名词（翻译顺序），这似乎是REST-ifying这类事情的一种方式。
任何人都可以分享一种更好，更直观的方法来处理通常不被认为是持久存在的行为/行为的建模吗？
答案 0 :(得分：2)
“不止一次这样做会不会受伤？” - 或许可以测试一下吗？
在您的示例中 - 如果要求您翻译同一文本两次，会发生什么？不是很多。发送短信两次可能是一件坏事。
答案 1 :(得分：1)
您描述的两个选项是有效选项，并且您已经突出显示了一个比另一个更好的方案。我建议的唯一其他选项是使用带有“处理资源”的POST。 e.g。
POST /translator?from=en&to=fr
Content-Type: text/plain
Body: The sentence to be translated
=>
200 OK
La phrase à traduire
关于“处理资源”的一个好处是它们可能会或可能不会产生持续的副作用。显然缺点是中介不能缓存响应。