title: API routes naming convention
body: <p>I'm working on an API (along with an SPA) for a private project and I can't decide between two route naming conventions.</p>
  
  <p>Suppose I have three tables in my database : <code>Users</code>, <code>Products</code> and <code>Orders</code>. If I want users to be able <strong>to order products</strong>, which one of the following conventions should I follow?</p>
  
  <ol>
  <li><code>POST /orders</code> with body <code>{ "product": 1 }</code></li>
  <li><code>POST /products/{id}/order</code></li>
  </ol>
  
  <p><em>Note</em> : In both case the <code>user</code> would be inferred based on the access token provided.</p>
  
  <p>To me, the main difference between the two solutions above resides in the type of interface to expose to the front-end developer : <strong>do I expose routes to <em>resources</em> (solution 1) or to <em>actions</em> to be performed (solution 2)?</strong></p>
  
  <p>Are there actual (dis)avantages to use one method over the other or is it just a matter of personal taste?</p>
  
  <p>Correct me if I'm wrong, but from my understanding solution 1 is REST ("create this resource") while solution 2 isn't ("perform this action").</p>
  
  <p>Also, with solution 1 each route would directly map to a table in my database and some people say it's a bad idea cause external developers can then infer the database's schema based on the API routes but honestly I don't see how it's a problem.</p>