title: Is using a verb in URL fundamentally incompatible with REST?
body: <p>So let's say we have something that does not seem best represented as a resource (status of process that we want to pause, stateless calculation we want to perform on the server, etc).</p>
  
  <p>If in API design we use either <code>process/123/pause</code> or <code>calculations/fibonacci</code> -- is that fundamentally incompatible with REST? So far from what I read it does not seem to, as long as these URLs are discoverable using HATEOAS and media types are standardized.</p>
  
  <p>Or should I prefer to put action in the message as answered <a href="https://stackoverflow.com/a/2687947/39068">here</a>?</p>
  
  <p><strong>Note 1:</strong><br>
  I do understand that it is possible to rephrase some of my examples in terms of nouns. However I feel that for <em>specific cases</em> nouns do not work as well as verbs do. So I am trying to understand if having those verbs would be immediately unRESTful. And if it is, then why the recommendation is so strict and what benefits I may miss by not following it in those cases.</p>
  
  <p><strong>Note 2:</strong><br>
  Answer <em>"REST does not have any constraints on that"</em> would be a valid answer (which would mean that this approach is RESTful). Answers <em>"it depends on who you ask"</em> or <em>"it is a best practice"</em> is not really answering the question. The question assumes concept of REST exist as a well-defined common term two people can use to refer to the same set of constraints. If the assumption itself is incorrect and formal discussion of REST is meaningless, please do say so.</p>