因此，假设我们有一些似乎不能最好地表示为资源的东西(我们想要暂停的进程状态、我们想要在服务器上执行的无状态计算等)。
如果在 API 设计中我们使用 process/123/pause 或 calculations/fibonacci ——这从根本上与 REST 不兼容吗？到目前为止，从我读到的来看，似乎并没有，只要这些 URL 可以使用 HATEOAS 发现并且媒体类型是标准化的。
或者我应该更愿意在回复的消息中添加操作 here ？
注1:
我确实明白可以用名词来重新表述我的一些例子。然而，我觉得对于特定情况来说，名词的作用不如动词。所以我试图了解使用这些动词是否会立即变得不安。如果是，那么为什么这个建议如此严格，以及在这些情况下如果不遵循它，我可能会错过什么好处。
注2:
回答“REST 对此没有任何限制”将是一个有效的答案(这意味着这种方法是 RESTful)。回答“这取决于你问的是谁”或“这是最佳实践”并不能真正回答问题。该问题假设 REST 概念作为一个定义明确的通用术语存在，两个人可以用来指代同一组约束。如果假设本身不正确并且对 REST 的正式讨论毫无意义，请务必指出。
最佳答案
这篇文章有一些很好的提示:http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
引用文章:
What about actions that don't fit into the world of CRUD operations?
This is where things can get fuzzy. There are a number of approaches:
Restructure the action to appear like a field of a resource. This works if the action doesn't take parameters. For example an activate action could be mapped to a boolean activated field and updated via a PATCH to the resource.
Treat it like a sub-resource with RESTful principles. For example, GitHub's API lets you star a gist with PUT /gists/:id/star and unstar with DELETE /gists/:id/star.
Sometimes you really have no way to map the action to a sensible RESTful structure. For example, a multi-resource search doesn't really make sense to be applied to a specific resource's endpoint. In this case, /search would make the most sense even though it isn't a noun. This is OK - just do what's right from the perspective of the API consumer and make sure it's documented clearly to avoid confusion.
我个人喜欢建议#2。如果你需要暂停某件事，你要暂停什么？如果它是一个有名称的进程，请尝试以下操作:
/process/{processName}/pause
关于rest - 在 URL 中使用动词是否与 REST 根本不兼容？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19646989/